[12:52] <Sebo> Hi, I need to set up /etc/init/*.conf file for the job and I am thinking of proper *start on* and *stop on* stanzas. The job which I am defining will be responsible for running vboxheadless VM machine which I am going to assign one of the tty* terminals to (I am going to modify the /etc/init/tty4.conf so it will ssh to that VM). Could you direct me how to prepare that stanzas to make the VBox job starting and stopping at right order?
[12:53] <Sebo> anyone here?
[12:54] <Sebo> Hi, I need to set up /etc/init/*.conf file for the job and I am thinking of proper *start on* and *stop on* stanzas. The job which I am defining will be responsible for running vboxheadless VM machine which I am going to assign one of the tty* terminals to (I am going to modify the /etc/init/tty4.conf so it will ssh to that VM). Could you direct me how to prepare that stanzas to make the VBox job starting and stopping at right order?
[15:34] <sveinse> Any activity here now?
[15:38] <sveinse> Does the stanza "start on runlevel [5] or runlevel [!5]" make any sense on a task? It seems to start whenever entering or leaving runlevel 5 (which I want)
[15:39] <sveinse> Hmm. Nope. The script triggers whenever a runlevel changes
[18:30] <jhunt> sveinse: "start on runlevel RUNLEVEL=5 or runlevel PREVLEVEL=5". I'll add this to the cookbook tomorrow. Rather intrigued to know what sort of job this is though.
[18:32] <sveinse> jhunt: The cookbook has really been a great guide to go by so thanks, and keep it up!
[18:33] <jhunt> sveinse: no problem - glad it's been useful.
[18:35] <sveinse> jhunt: The job is for a task that shall run whenever entering or leaving a runmode. We're building an embedded product and we're using runlevels to set different working states. Runlevel 3=appmode, 4=connected to PC, 5=upgrade and so on. The job I'm writing is thus a small task to update the display with "Upgrading device" and so on
[18:36] <sveinse> jhunt: I have had a question which I think should be mentioned in the cookbook: If an event arrives, and there are two task which are affected by it; one stop and one start task. Does upstart then guarantee to stop one for the other is started?
[18:38] <sveinse> I understand start jobs are started out of order, and so does stop jobs I presume. But are there any guarantees for stop _then_ start jobs?
[18:39] <ryoohki> with chkconfig i can do "chkconfig service off" and the service won't start, presumably
[18:39] <ryoohki> how do i do that from the cli with upstart?
[18:41] <jhunt> sveinse: interesting. feel free to post questions to the upstart-devel mailing list if nobody is in the channel. yes, stop ons are handled first. I'll add that too :) gotta go...
[19:55] <dcorbin_work> I just added "/sbin/initctl emit get-updates-complete" to my rc.local.  It never completes, and I cannot fathom why.  Suggestions?
[20:05] <dcorbin_work> When I run that command by hand, it does finish quite quickly.  This is an ubuntu 10.4 system.
[21:17] <ryoohki> with chkconfig i can do "chkconfig service off" and the service won't start( presumably); how does upstart do that from the cli?