Reliable process tracking

Edward Tomasz Napierała trasz at FreeBSD.org
Mon Aug 5 11:13:15 UTC 2013


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.  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.

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?



More information about the freebsd-arch mailing list