[00:32] Hi, is there anyone here? [00:46] Can you tell me how to make /etc/init/*.conf auto respawning job not to respawn if the main process ended while pre-stop is running? [06:51] marrusl: thanks! [08:44] Hi, is there anyone here? [08:49] hi [08:56] Can you tell me how to make /etc/init/*.conf auto respawning job not to respawn if the main process ended while pre-stop is running? [08:57] you could call "stop" from pre-stop which will override the respawn stanza. [08:58] (you don't need to specify the name of the job - just call "stop". [08:58] ) [09:10] I think I did it but it does not help [09:11] I created /var/run/job.pid file at the beggining of the pre-stop [09:12] and in the beggining of the pre-start I just check if there is this file and if the process with the pid given in it is running [09:14] and if it is I do # kill -0 `cat /var/run/job.pid` && { stop; exit 0;} [09:16] I'm rather confused by what you're trying to do here. [09:17] I am trying to write a job for running VBox VM as a daemon. [09:18] Therefore I created the script that exec vboxheadless -s TheVM [09:22] so why do you need to cancel the respawn handling? If you stop that job via the command-line, it won't respawn and it should be stopped at system shutdown too? [09:23] Since the VM should be stopped by calling vboxmanage controlvm TheVM acpipowerbutton ...and that command causes the VM to poweroff the virtual system and after that the main process exits I made pre-stop script to call this command. And what I found out that such configuration makes stopping the job imposible. cause the main is respawned after it finishes at pre-stop [09:27] the problem is that you're asking Upstart to manage that pid of the server and they you are trying to take control back by invoking vboxmanage. [09:32] I'd like to ask upstart to manage the vboxheadless process i.e to restart it if it for some reason went down. Hovever I would like it to stop the process not by sending the term signal but by calling vboxmanage controlvm TheVM acpipowerbutton [09:35] And whats more I would suppose that if the main process went unexpectedly down the upstart will call pre-start before the respawn. [09:39] I understand what you're trying to do now. Try running "vboxheadless" on the command line and then seeing what the exit code is when it is stopped by "vboxmanage controlvm". You should then be able to specify "normal exit ..." which will tell Upstart not to respawn it if it detects that exit code. (see "man 5 init" for details). [09:44] It might be a good way :)and simple [09:46] you just have to hope that the exit code when vboxheadless exits via "vboxmanage" is different to if vboxheadless does actually crash for some reason. If vboxmanage is cleanly shutting the VM down, you would *expect* the vboxheadless process to "exit 0", but from what you've described, that isn't happening so that could be a bug with VBox. [09:48] Yep but I can make main script that'll check if the pre-stop is running and if so it could return some 'normal exit' code defined by myself [09:53] And I read at the upstart wiki that calling # stop JOB changes the JOB goal. How can i check inside the job scripts what the actual goal is? [09:54] "status job" shows the goal [09:55] More on that in the cookbook: http://upstart.ubuntu.com/cookbook/#job-states [09:57] J was just thinking of checking if the goal is 'stop' at the beggining of main and pre-start and if so just quit. [13:05] hmmm [13:05] I'd like to restart rsyslog after a certain point [13:05] is there a clean way to do this, except creating a new upstart job which does the restart [13:08] why do you want to restart rsyslog and what point are you referring to? [13:10] just an event [13:11] it's a special setup [13:11] not a normal hosts, it's ramdisk which determines it's hostname by reverse dns lookup [13:11] so initially it's hostname is just localhost [13:11] a job called nethostname set the proper hostname [13:11] but rsyslog is already running then [13:12] so I need to restart it after nethostname has run [13:13] for the time being a job called 'restart rsyslog' seems to way to go [13:14] if you don't want to delay the start of rsyslog (probably not), your proposal should work fine. [13:19] I though about that, but delaying rsyslog would probably mean losing messages, or possibly other hard to predict issues [13:19] restarting at a later point seems the safer choice [13:19] our rsyslog server already uses %FROMHOST% instead of %HOSTNAME% to make sure the localhost messages go into their proper files [13:19] using DynaFile [13:21] agreed