[14:19] <jackqu7> Hello
[14:20] <jackqu7> I've got a job stuck on 'start/killed', and trying to start or stop it just hangs
[14:20] <jackqu7> I was changing the conf for it, but even after reverting to a known good version the same thing is happening
[14:20] <jackqu7> I was wondering if anyone had any suggestions?
[14:22] <ion> The main process most likely has different forking behavior than claimed in the ‘expect’ stanza, confusing Upstart’s preliminary fork-following code. Either be 100 % sure of the forking behavior or make it not fork and drop the ‘expect’. A future release of Upstart will have more intelligent code to follow forks.
[14:54] <jackqu7> ion: I've tried setting it to both fork and daemon, no luck
[14:54] <ion> “Trying” to set it to seomthing indicates you don’t actually know the precise forking behavior of the main process. It might be best just to make it not fork at all.
[14:55] <jackqu7> The process has a switch to either fork or not
[14:56] <jackqu7> What happened was I set that switch, but didn't add "expect fork" the first time
[14:56] <jackqu7> And now even after adding that, or removing the switch from the process it still hangs
[14:57] <jackqu7> As if it's still tracking the process initiated from the bad configuration
[14:57] <ion> Yes, Upstart is still in a confused state. Can you reboot?
[14:57] <jackqu7> I would really rather not
[14:57] <jackqu7> I'm foolishly making changes on a production box
[14:58] <jackqu7> Is there any other way to flush it?
[14:58] <ion> http://heh.fi/tmp/workaround-upstart-snafu
[14:58] <ion> ./workaround-upstart-snafu 12345 where 12345 is the pid reported by ‘status jobname’.
[15:02] <jackqu7> Thanks! That worked
[15:02] <jackqu7> Cheers for your help
[15:04] <jackqu7> Out of interest, what does that script actually do?
[15:06] <ion> When in the confused state, Upstart’s fork-following code is waiting to reap a parentless child by the tracked pid which never appears. The workaround creates new child processes until one with the right pid appears, then kills its parent and lets the child die afterwards. Ugly, but effective.
[15:16] <JanC> sort of a benign fork bomb?  ;)
[15:18] <ion> Not a fork bomb, since it has no more than two child processes running at any given time.
[15:21] <JanC> ion: but it would work much faster as a fork bomb!  :P
[15:21] <ion> heh
[15:22] <JanC> j/k