Off-Topic: how do I trace a PID over double-forks?
This is more a Unix API question than a Linux question.
I hope the issue is interesting enough to be of interest to some of you.
Basically, I am writing an init which features process watching capabilities. My init has a management channel with which you can tell it "the PID of the ssh process is really 123 instead of 12".
When init forks a getty and that getty exits, it is restarted. So far so good. But I want my init to be able to restart uncooperative processes like sendmail that fork in the background. sendmail may be a bad example because the sources are available, but please imagine you didn't have the sources to sendmail or didn't want to touch them.
Now, the back channel for my init has a function that allows to set the PID of a process. The idea is that the init does not start sendmail but a wrapper. The wrapper forks, runs sendmail, does some magic trickery to find the real PID of the daemonized sendmail and tells init this PID so init will know it has to restart sendmail when it exits and won't restart the wrapper when that exits.
Follow me this far? Great! The real problem at hand is: what kind of trickery can I employ in that wrapper. I was hoping for something that is not Linux specific, but I haven't found anything yet. I was also hoping that I could find a method that does not rely on /proc being there or on any filesystem being mounted read-write (yes, my back channel works if the filesystem is mounted read-only). So, using /proc and relying on something like /var/run/sendmail.pid are out.
Someone suggested using fcntl to create a lock and then use fcntl again to see who holds the lock. That sounded good at first, but fork() does not seem to inherit locks. Does anyone have another idea?
In case I made you wonder: http://www.fefe.de/minit/
Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Felix von Leitner
Now, the back channel for my init has a function that allows to set the PID of a process. The idea is that the init does not start sendmail but a wrapper. The wrapper forks, runs sendmail, does some magic trickery to find the real PID of the daemonized sendmail and tells init this PID so init will know it has to restart sendmail when it exits and won't restart the wrapper when that exits.
Someone suggested using fcntl to create a lock and then use fcntl again to see who holds the lock. That sounded good at first, but
fork()does not seem to inherit locks. Does anyone have another idea?
Take a look at fghack (http://cr.yp.to/daemontools/fghack.html). It opens a pipe, gives the write end to the daemon (but the daemon is not aware of that) and monitors the read end. When the daemon process exits, the read end of the pipe gets EOF.
If the daemon closes all filehandles, you're out of luck.
Eric
Signature · 7 lines
Eric Lammerts <[email protected]> | The best way to accelerate a computer http://www.lammerts.org | running Windows is at 9.8 m/s^2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/