3 ms·

Yep, I've run into the problems with "expect fork"/"expect daemon" in Upstart first hand. Forking is a terrible readiness protocol, and Upstart is terrible at k

by lambda 11y ago

Yep, I've run into the problems with "expect fork"/"expect daemon" in Upstart first hand. Forking is a terrible readiness protocol, and Upstart is terrible at keeping track of a process that doesn't do exactly what it expects. In fact, if you choose the wrong one, you wind up with Upstart not even noticing the a process has gone away, and not being able to do anything to reset Upstart's knowledge of the world without spawning programs in a loop until the PID namespace wraps around and you get back to the original PID that it's expecting to track, so that Upstart can finally notice it die and properly clean up after it. This is seriously the only recommended workaround for a bug that went unfixed for years: https://bugs.launchpad.net/upstart/+bug/406397 https://bugs.launchpad.net/upstart/+bug/406397 I'm glad that Debian and Ubuntu have finally decided to go with an actually maintained init system, that properly track processes even after arbitrarily many forks and support a reasonable readiness protocol.

bonobo3000 11y ago
I have also had a little mismatch with upstart for a particular application - the app itself spawns new processes in response to user input, but upstart can only track the main app not the children. I am curious - precisely knowing when an app is running and when its not seems inherently dependent on the app and your definition of "running" for that app. Tracking apps from the system level in terms of processes etc. can only go so far. How do the init systems you mentioned tackle this?
- Shish2k 11y ago
  > precisely knowing when an app is running and when its not seems inherently dependent on the app [...] How do the init systems you mentioned tackle this? In systemd's case, it provides an API so that the app can explicitly say "I am now ready to receive requests", among other things. http://www.freedesktop.org/software/systemd/man/sd_notify.html http://www.freedesktop.org/software/systemd/man/sd_notify.ht... (I've also found the related watchdog functionality very useful -- once you tell the init system that your daemon is ready to serve requests, then you can also tell it every time a request is completed; then if you go for say 10 seconds without serving a request, init will assume that your service has hung and kill/restart it. I've seen a small number of daemons do this for themselves, but that number is nowhere near 100%, and even those who do implement it don't do it as well as systemd does.)

by lambda 11y ago

bonobo3000 11y ago

I have also had a little mismatch with upstart for a particular application - the app itself spawns new processes in response to user input, but upstart can only track the main app not the children. I am curious - precisely knowing when an app is running and when its not seems inherently dependent on the app and your definition of "running" for that app. Tracking apps from the system level in terms of processes etc. can only go so far. How do the init systems you mentioned tackle this?

Shish2k 11y ago
> precisely knowing when an app is running and when its not seems inherently dependent on the app [...] How do the init systems you mentioned tackle this? In systemd's case, it provides an API so that the app can explicitly say "I am now ready to receive requests", among other things. http://www.freedesktop.org/software/systemd/man/sd_notify.html http://www.freedesktop.org/software/systemd/man/sd_notify.ht... (I've also found the related watchdog functionality very useful -- once you tell the init system that your daemon is ready to serve requests, then you can also tell it every time a request is completed; then if you go for say 10 seconds without serving a request, init will assume that your service has hung and kill/restart it. I've seen a small number of daemons do this for themselves, but that number is nowhere near 100%, and even those who do implement it don't do it as well as systemd does.)