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:52 |
---|---|---|
Sebo | anyone here? | 12:53 |
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:54 |
sveinse | Any activity here now? | 15:34 |
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:38 |
sveinse | Hmm. Nope. The script triggers whenever a runlevel changes | 15:39 |
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:30 |
sveinse | jhunt: The cookbook has really been a great guide to go by so thanks, and keep it up! | 18:32 |
jhunt | sveinse: no problem - glad it's been useful. | 18:33 |
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:35 |
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:36 |
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:38 |
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:39 |
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... | 18:41 |
dcorbin_work | I just added "/sbin/initctl emit get-updates-complete" to my rc.local. It never completes, and I cannot fathom why. Suggestions? | 19:55 |
dcorbin_work | When I run that command by hand, it does finish quite quickly. This is an ubuntu 10.4 system. | 20:05 |
ryoohki | with chkconfig i can do "chkconfig service off" and the service won't start( presumably); how does upstart do that from the cli? | 21:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!