Reliable process tracking

[Tom Rhodes]

On Sun, 4 Aug 2013 15:46:58 +0200
Jilles Tjoelker <jilles at stack.nl> 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. 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.
> 
> There is no such facility in POSIX, but there are some FreeBSD-specific
> facilities that come close:
> 
> * Do the tracking in userland using kqueue EVFILT_PROC NOTE_TRACK. I
>   think this does not work because there is no way to deal with
>   NOTE_TRACKERR. NOTE_TRACKERR could perhaps be avoided by making fork()
>   fail instead but that may be rather nasty if the tracking process does
>   not call kevent() while many tracked processes are created and
>   destroyed again.
> 
> * Jails. If there were a way to put a process in jail without affecting
>   its privileges, filesystem root directory and network interfaces, this
>   would be usable. Processes cannot escape from a jail and there are
>   ways to signal all processes in a jail or to terminate forcibly all
>   processes in a jail.
> 
> * setloginclass(2). The login class attribute cannot be changed by a
>   normal user, although login(1) and su(1) will change it to the
>   target user's class. The rctl system is also available to limit
>   resources based on login class; this can also be useful to kill all
>   processes with some login class without racing with fork().
> 
> * setlogin(2). Everything except setuid login(1) knows to be careful
>   with this, but breaking getlogin(2) seems unwise. Therefore, this is
>   only useful for daemons with one passwd line per instance.
> 
> Similar facilities in other operating systems: Linux cgroups, Solaris
> process contracts.

There is fscd - it does a lot of what you ask for.  In fact, I had
talked to a few people about bringing it into base but have not
really figured out how I want to integrate it into rc.

--
Tom Rhodes