Date: Wed, 7 Aug 2013 22:19:34 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Message-ID: <20130807201934.GA4918@stack.nl> In-Reply-To: <CDFF8851-0883-4D27-851A-36A9585499E6@FreeBSD.org> References: <20130804134658.GC35080@stack.nl> <CDFF8851-0883-4D27-851A-36A9585499E6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Jilles Tjoelker <jilles@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807201934.GA4918>