Date: Fri, 09 Aug 2013 04:05:44 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Message-ID: <5203FA18.20403@freebsd.org> In-Reply-To: <20130807201934.GA4918@stack.nl> References: <20130804134658.GC35080@stack.nl> <CDFF8851-0883-4D27-851A-36A9585499E6@FreeBSD.org> <20130807201934.GA4918@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/8/13 4:19 AM, Jilles Tjoelker wrote: > 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. I've been pondering the possibility of appending a universe (jail) number to the UIDS, PIDS and various other things. (classes maybe?). It wouldn't have to be everywhere, but ther eare a number of places where comparisons would DTRT if they were comparing "my_jail+my_uid" with "his_jail+his_uid", instead of just the UIDs. It would also help with the "multiple roots" problem, and might simplify some of the current code. Unfortunately we already extend PIDS to make thread IDs but we could still grab a bunch of bits way up the top end to express jail-IDs. > > * 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5203FA18.20403>