[Xorp-hackers] PATCH: Remove some dead code, unlink pid-file on exit.

[Bruce Simpson]

Ben,

A few comments about this patch:
 * Do you have a specific distribution which relies on the behaviour of 
removing the pid file after the daemon terminates?
    For the BSD distributions at least, when running XORP from an 
rc.subr init script, this shouldn't be an issue; the file is just 
ignored, and overwritten on the next run.
    It's good filesystem hygeine to remove it, though.

Ben Greear wrote:
> This is mostly just a cleanup patch.  It removes some dead code and
> changes around the pidfile logic a bit.  It also allows unlinking the
> pid-file on exit using the atexit call.  Tested on Linux.

 * atexit() is better specified now, though, although a check for a C99 
compliant implementation would be useful (for folk trying to link 
against it on embedded platforms):
    http://www.opengroup.org/onlinepubs/009695399/functions/atexit.html

 * handle_atexit() should be renamed to reflect what it's doing through 
the atexit() mechanism. We are indeed daemonizing the whole process, not 
Rtrmgr, so it certainly belongs at the C top level scope.

 * Please don't use cout. C stdio is used elsewhere in this file, so no 
point in pulling in iostreams; C stdio should still be accessible. In 
practice this isn't an issue if libc is shared, however, it does pull in 
parts of the C++ runtime we don't immediately need.

 * The reason the pid gets written out from the parent is because on 
most distributions, we are writing to an absolute path under /var 
(usually /var/run/<procname>.pid). If the child is chrooted it may not 
have access to this absolute path, which breaks POLA.

JT indicated that he wasn't 100% happy with some POLA elements of how 
XORP daemonizes. For example, it won't chdir() to /. This potentially 
breaks chroot()-ed operation, or at least means that the rtrmgr still 
holds a vnode lock on the place it was started from.

So hopefully he will chime in on this.

cheers,
BMS