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