Comments on: How to (and why) supervise forking processes http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ Just another WordPress weblog Mon, 08 Sep 2008 08:08:53 +0000 http://wordpress.org/?v=2.6.1 By: Dafydd http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-566 Dafydd Mon, 10 Dec 2007 20:06:52 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-566 Eww: - It's fairly common for ptrace to be disabled for security purposes on server systems. - Service forked != service ready. - Eww. How does upstart decide whether to wait for one or two forks? For services that connect to the system bus, why not just tell upstart what their D-Bus name is? When launching network manager, you know it's ready when org.freedesktop.NetworkManager appears. No upstream changes necessary. Similarly, for services that listen on sockets, why not just tell upstart which port they listen on? The downside being that (as far as I know) you have to poll for this information. Also: since daemon processes become children of init when the process group is orphaned, can't upstart just monitor what its children are and infer readiness from that? Eww:

- It’s fairly common for ptrace to be disabled for security purposes on server systems.
- Service forked != service ready.
- Eww.

How does upstart decide whether to wait for one or two forks?

For services that connect to the system bus, why not just tell upstart what their D-Bus name is? When launching network manager, you know it’s ready when org.freedesktop.NetworkManager appears. No upstream changes necessary.

Similarly, for services that listen on sockets, why not just tell upstart which port they listen on? The downside being that (as far as I know) you have to poll for this information.

Also: since daemon processes become children of init when the process group is orphaned, can’t upstart just monitor what its children are and infer readiness from that?

]]> By: The Evil Blog » Blog Archive » Evilbuntu? http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-555 The Evil Blog » Blog Archive » Evilbuntu? Sun, 09 Dec 2007 13:19:01 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-555 [...] a prominent Ubuntu developer: all daemons are our [...] [...] a prominent Ubuntu developer: all daemons are our [...]

]]> By: Mildred http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-553 Mildred Sun, 09 Dec 2007 08:15:43 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-553 Maybe it could be possible to keep watching the process in all its forks and just stop watching any of them when they do exec ... We could imagine for example a daemon that would fork for example when a request is made to it, and then it's the parent that would handle the request and dies letting the chile waiting for others requests. Well it seems a little bit odd but I think it could be useful in some cases. Also because when we write the upstart script we don't know if the daemon forks once or twice. Maybe it could be possible to keep watching the process in all its forks and just stop watching any of them when they do exec …

We could imagine for example a daemon that would fork for example when a request is made to it, and then it’s the parent that would handle the request and dies letting the chile waiting for others requests.
Well it seems a little bit odd but I think it could be useful in some cases. Also because when we write the upstart script we don’t know if the daemon forks once or twice.

]]> By: Scott James Remnant http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-544 Scott James Remnant Sat, 08 Dec 2007 14:48:30 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-544 Note that the trace is removed as soon as we've seen the two (or one) forks, so it's only there for a very short amount of time. As soon as Upstart believes the service is actually running, you can attach strace or gdb to it as normal. (If you run the service under strace or gdb, you don't need the fork following since strace/gdb stay in the foreground and follow the forks of the daemon themselves.) Note that the trace is removed as soon as we’ve seen the two (or one) forks, so it’s only there for a very short amount of time. As soon as Upstart believes the service is actually running, you can attach strace or gdb to it as normal.

(If you run the service under strace or gdb, you don’t need the fork following since strace/gdb stay in the foreground and follow the forks of the daemon themselves.)

]]> By: Anonymous http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-539 Anonymous Fri, 07 Dec 2007 22:48:20 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-539 Could upstart support PID files when a daemon already knows how to write them, and just use ptrace as a fallback for those that don't? Could upstart support PID files when a daemon already knows how to write them, and just use ptrace as a fallback for those that don’t?

]]> By: Jeff Schroeder http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-537 Jeff Schroeder Fri, 07 Dec 2007 20:00:44 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-537 @Joe, one of the biggest limitations of ptrace() is that you can not ptrace an already ptrace'd process... It will all go away once they merge utrace, but that is sometime in the future. http://people.redhat.com/roland/utrace/ @Joe, one of the biggest limitations of ptrace() is that you can not ptrace an already ptrace’d process… It will all go away once they merge utrace, but that is sometime in the future.

http://people.redhat.com/roland/utrace/

]]> By: Joe Shaw http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-533 Joe Shaw Fri, 07 Dec 2007 14:11:16 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-533 Woo hoo! I guessed right. :) Can multiple process ptrace at the same time? Ie, can you still run strace or gdb on those processes? Woo hoo! I guessed right. :)

Can multiple process ptrace at the same time? Ie, can you still run strace or gdb on those processes?

]]> By: Ross Burton http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-530 Ross Burton Fri, 07 Dec 2007 12:10:05 +0000 http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/#comment-530 I can't decide if that is twisted or genius. :) I can’t decide if that is twisted or genius. :)

]]>