Date: Sat, 10 Aug 2013 12:30:36 +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: <20130810103036.GA40636@stack.nl> In-Reply-To: <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org> References: <20130804134658.GC35080@stack.nl> <CDFF8851-0883-4D27-851A-36A9585499E6@FreeBSD.org> <20130807201934.GA4918@stack.nl> <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 09, 2013 at 10:42:09AM +0200, Edward Tomasz Napierała wrote:
> Wiadomość napisana przez Jilles Tjoelker <jilles@stack.nl> w dniu 7 sie 2013, o godz. 22:19:
> > 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.
> Indeed. I'll try to figure out something.
> FWIW, I've just committed a patch that adds "-c" flag to pkill.
On another note, init(8) does not set the kernel login class for /etc/rc
to daemon as might be expected from the /etc/login.conf entry used. I
use this patch:
Index: sbin/init/init.c
===================================================================
--- sbin/init/init.c (revision 253911)
+++ sbin/init/init.c (working copy)
@@ -1729,7 +1729,8 @@
login_cap_t *lc;
if ((lc = login_getclassbyname(cname, NULL)) != NULL) {
setusercontext(lc, (struct passwd*)NULL, 0,
- LOGIN_SETPRIORITY | LOGIN_SETRESOURCES);
+ LOGIN_SETPRIORITY | LOGIN_SETRESOURCES |
+ LOGIN_SETLOGINCLASS);
login_close(lc);
}
}
Should I commit this?
--
Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130810103036.GA40636>