Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Aug 2013 10:42:09 +0200
From:      =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@FreeBSD.org>
To:        Jilles Tjoelker <jilles@stack.nl>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Reliable process tracking
Message-ID:  <87717220-8094-49BE-BF04-010D9788ABD3@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
Wiadomo=B6=E6 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=B3a =
wrote:
>> Wiadomo=B6=E6 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.
>=20
>>> 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.
>=20
>> 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.
>=20
> There are some problems with su -c:
>=20
> * 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.

[..]




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87717220-8094-49BE-BF04-010D9788ABD3>