=== mbiebl_ is now known as mbiebl [22:36] hiho guys... aehm i'm new to upstart and i'm debian user, just to drop out the most important ;) i added a new .conf script (like i did before) but this script doesnt work... if i do initctl stop of it, it just hangs, and the initctl list says its running on a process id, but that one doesnt exist [22:36] i can exec the command by myself on shell, so that seems ok [22:50] i always need to reboot then its fixed... [22:51] that scares me [22:52] Getty: that sounds like you have a forking process and the current version of upstart can't "follow the forking" [22:52] so basically it's looking at the wrong process [22:53] its something that forks, yes, but the startup process stays (php-cgi spawns for fastcgi) [22:53] expect fork is there [22:53] my problem is actually that initctl "hangs" on a process that doesnt exist [22:53] what he do? [22:54] and what i could do beside reboot to fix that kind of stuff? [22:54] what do you mean by "the startup process stays"? [22:54] the process run from the job stays around? [22:54] it doesnt fork and is gone, it starts and generates forks but still runs [22:55] its even a foreground process [22:55] then don't use "expect fork" [22:55] oh [22:55] i got that out of the example of someone who use it that way [22:55] and i mean it works now... after reboot [22:55] Don’t use ‘expect’ if you’re not 100 % sure of the forking behavior of the main process. That will confuse Upstart. Here’s a nasty kluge to force Upstart back into a good state without rebooting: http://heh.fi/tmp/workaround-upstart-snafu [22:56] ruby code is strange [22:56] I was just going to find my bookmark for ion's "nast kludge" ;) [22:57] Getty: it just creates new processes until the expected PID exists again [22:57] on stop?! [22:57] of a non existing process? [22:57] 8-) [22:57] on start i'm with you, but not on stop [22:57] once it exists again, you can "stop" it ;-) [22:58] ok ok... back to what happened [22:58] i made the .conf script, reload-configuration, started it [22:58] saw that it had a mistake [22:58] stopped it => hang... ctrl-c worked, check ps list, its gone [22:58] A future release of Upstart will have better code to follow forks. The current implementation can be broken easily by telling Upstart to ‘expect’ one thing and having the main process do something else. [22:58] check initctl list, says stop/killed [22:58] doing start => hang, ctrl-c worked, check ps list, nothing there [22:59] initctl says start/running with a process id that doesnt exist [22:59] initctl stop => hang [22:59] ‘workaround-upstart-snafu N’ where N is the pid from initctl status. [22:59] the nonexistent pid [22:59] ah! cool ok [22:59] i can life with workaround if i have some! :) [22:59] upstart is really nice [23:03] Getty: not using expect is a better solution if you don't really need it anyway [23:03] JanC: oh i will check on this anyway, i just wanted that workaround for same situations [23:04] yeah, it's probably more convenient than rebooting ;) [23:04] its a xen so i dont have THAT kind of a feeling to reboot [23:05] also.... i guess as long as no productive site is running on it and i still "learn" with upstart, i guess its good to reboot anyway some more often