| afournier | it happens that when i do a start job or stop job, upstart is waiting for something (it does not give back the shell), the job is in "start/starting" "stop/starting" | 09:30 |
|---|---|---|
| afournier | is there a way to "debug" this behavior ? | 09:30 |
| phroddon | afournier: increase the debug level (initctl -q log-priority debug, if I recall correctly) | 09:32 |
| phroddon | afournier: I like to strace the upstart job also, it can help a lot | 09:32 |
| phroddon | (for example, put a sleep at the very beginning of the job to have the time to strace it ;) | 09:32 |
| afournier | like this "strace --someargs start job" | 09:33 |
| afournier | ? | 09:33 |
| afournier | ha you attach to the pid ? | 09:33 |
| phroddon | yup | 09:33 |
| afournier | k | 09:33 |
| afournier | i found something when "stracing" initctl | 10:43 |
| afournier | after the connect to dbus, and negotiation, it gets a recvmsg(3, 0xbf837c3c, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) | 10:43 |
| afournier | and then it waits forever in poll() | 10:43 |
| afournier | any idea ? | 10:44 |
| afournier | i am starting to think that upstart was not a good choice at all | 12:58 |
| jodh | afournier: http://upstart.ubuntu.com/cookbook/#establish-blocking-job | 13:58 |
| afournier | thanks jodh, i really thought initctl was buggy | 14:05 |
| afournier | a warning would be a good idea, dunno if it's possible | 14:06 |
| afournier | i will try this script right now | 14:06 |
| jodh | afournier: it doesn't make sense to show a warning in this scenario as upstart is working correctly - it's simply blocking waiting for the remaining events in your jobs 'start on' to be emitted. If you don't want initctl to block itself (just the job), use 'initctl -n emit ...' | 14:10 |
| afournier | that's what i was thinking in the first place, but using "start job" and waiting for ever is not natural, because when someone says "start job" it expects the job to start, not to wait for ever | 14:11 |
| xnox | afournier: that depends, currently one is guaranteed that when `start job` exits with 0 you can rely on the service be available & hence start using it immediately. | 14:48 |
| afournier | the problem was on start, not at exit | 14:51 |
| afournier | i was thinking that calling a job with the start command would force it to start, but from what i understood, if the job as something like "start on started other_job" job will wait until other_job has started | 14:53 |
| afournier | to me start was implicit "manual" but it's not | 14:53 |
| afournier | another option would be to print a warning/notice on CTRL+C, to say job was not started because this condition was not met | 14:55 |
| SpamapS | afournier: start on and stop on are not evaluated when you do an explicit start or stop of a job | 15:57 |
| afournier | so it's like having "manual" | 15:57 |
| SpamapS | afournier: what you're blocking on is *other* jobs that 'start on starting yourjob and xxxxx' .. where xxxxx is something that happens only during boot most likely | 15:57 |
| afournier | ah ok | 15:57 |
| SpamapS | afournier: so I would look for other things that mention your job in their start on | 15:57 |
| SpamapS | or stop on | 15:57 |
| SpamapS | afournier: Those other things are most likely "doing it wrong" | 15:58 |
| afournier | i get it | 15:58 |
| afournier | thanks SpamapS | 15:58 |
| SpamapS | afournier: as far as initctl blocking forever.. I am troubled by it too, and have oft thought that if 'initctl --verbose start foo' could say something like 'emitted starting foo\nstarting foo blocked by job bar [start on starting foo and net-device-up]' that would be great | 16:00 |
| SpamapS | afournier: when you have log-priority set to debug, you can see that in syslog.. but.. yeah.. thats a bit disconnected from your terminal | 16:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!