Reliable process tracking

[Tom Rhodes]

On Sun, 4 Aug 2013 21:53:16 +0200
Jilles Tjoelker <jilles at stack.nl> wrote:

> On Sun, Aug 04, 2013 at 10:15:47AM -0700, Tim Kientzle wrote:
> > On Aug 4, 2013, at 6:46 AM, Jilles Tjoelker wrote:
> > > When shutting down a service or requesting status, rc.subr currently
> > > uses a combination of pidfiles and process names. This is fairly but not
> > > completely reliable once it is set up correctly (which can take a lot of
> > > work and possibly patching the daemon to use pidfile(3) from our
> > > libutil). It is also incapable of killing multiprocess daemons such as
> > > CGI web servers without cooperation of the daemon.
> 
> > > I think what is needed here is a facility that marks a process and all
> > > of its descendants.
> 
> > It sounds like all you really need is some way to
> > signal a process and all descendants.
> 
> No, it is different in several ways. Firstly, you need a different
> definition of descendants than the one implied by getppid(). The parent
> process ID resets to 1 when the parent exits, which would cause the
> child to lose its relationship with the group.
> 
> Secondly, I want to keep track of the group even if the top level
> process terminates. For example, if apache's or postgres's master
> process crashes, I want to shut down all remaining worker processes
> before attempting to start a new master.
> 
> > Why do you need to actively mark and/or track them?
> 
> Tracking is needed for restarting services when they crash, as done by
> fsc. It can also be useful for providing information to the system
> administrator.
> 
> Also, it can be useful for legacy/simple compatibility. After running
> '/etc/rc.d/foo start' with a mark, the marked process(es) with ppid 1
> can be considered the processes that need to be monitored for service
> foo. Admittedly, this is not fully reliable, but it is better than
> matching by name on the process table (which is otherwise needed if the
> daemon does not write a pid file).

All good points - I actually don't really like the entire rc.d plugin
stuff but wanted to be as "clean" as possible.  It might be a neat
project to work at removing the rc support from it.  I'll be traveling
to Baltimore this week for a convention, if I have some evening time
I might look over this a bit.  Famous last words considering I have
little free time these days.  :(

--
Tom Rhodes