Reliable process tracking

[Jilles Tjoelker]

On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote:
> Wiadomość napisana przez Jilles Tjoelker <jilles at stack.nl> w dniu 4 sie 2013, o godz. 15:46:
> > 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. Removing the mark should be a privileged or at least
> > an unusual operation; no unprivileged function specified by POSIX such
> > as setsid() should do this.

> I've actually thought about that when I added setloginclass(2).  It's
> trivial to modify rc.subr to use su(8) to set login class for each
> service.  It should be trivial to modify pkill(1) and killall(1) to
> add "-c" option to kill all processes in a given login class.

There are some problems with su -c:

* It refuses to set a login class name that is not in /etc/login.conf.
  Given that multiple instances of a service should each have their own
  kernel login class, it may make sense to allow specifying the
  login.conf entry separate from the kernel login class.

* It always inserts an intermediate process to shut down the PAM session.
  This is not needed to start a simple daemon but not that harmful apart
  from performance.

> Two caveats:

> 1. Login classes, just like UIDs, are global, not per jail.  This means when
>    you want to kill all processees in a login class, you should probably use
>    "-j" option to limit it to a given jail, e.g. jail 0.

True.

> 2. I'm not sure if pkill(1) has any special way of handling this, but there is
>    an obvious race condition between iterating over processes in userland
>    in pkill(1) and quickly forking processes to kill.  Perhaps we should have
>    some kind of syscall to do it in a race-free way?

Yes.

-- 
Jilles Tjoelker