From owner-freebsd-arch@FreeBSD.ORG Sat Aug 10 15:12:53 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9006319A for ; Sat, 10 Aug 2013 15:12:53 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 238F9217C for ; Sat, 10 Aug 2013 15:12:52 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id e11so1705285bkh.11 for ; Sat, 10 Aug 2013 08:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MlBZnj+yPDDJooDI3gfdxo/NttGXrkRgWlLtpiW289M=; b=RglV5LXe6bB5rakLzi2SuzDU+tMgyVBbtmKFAQokbDdMfHquGh5JAxCmtdroL+qMLp UzPL0HhSOVxRLu3h9kKl6Uq0yz/eg1E/QynWHDmvdWt9s1tLKw5yjPsXLBds9S4d1Ie9 DqVW1A3apPVMSJuVz6act1mDEyp9q6mU+IQfI33jZxje54vfxdfCg853Flg1vZ1KBvd8 CwDKiF3qmtqQWdTZ/A06IpqWgiP2Auc2vjb1hkThvb98KJ8SJSrIfjGFYt55tpioSVT7 a/vluFwobpMQ6NGZCJIJ1MDi5dlC8T1G567fvswpJjP/5DOc2qWyYBYT0XPKlgtQ9k9/ p3kA== X-Received: by 10.204.176.75 with SMTP id bd11mr2745714bkb.62.1376147570473; Sat, 10 Aug 2013 08:12:50 -0700 (PDT) Received: from [192.168.1.4] (addq65.neoplus.adsl.tpnet.pl. [79.184.68.65]) by mx.google.com with ESMTPSA id ct12sm4110268bkb.12.2013.08.10.08.12.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 08:12:50 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reliable process tracking From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20130810103036.GA40636@stack.nl> Date: Sat, 10 Aug 2013 17:12:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130804134658.GC35080@stack.nl> <20130807201934.GA4918@stack.nl> <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org> <20130810103036.GA40636@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1508) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 15:12:53 -0000 Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu 10 = sie 2013, o godz. 12:30: > On Fri, Aug 09, 2013 at 10:42:09AM +0200, Edward Tomasz Napiera=B3a = wrote: >> Wiadomo=B6=E6 napisana przez Jilles Tjoelker 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 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. >=20 >> Indeed. I'll try to figure out something. >=20 >> FWIW, I've just committed a patch that adds "-c" flag to pkill. >=20 > 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: >=20 > Index: sbin/init/init.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sbin/init/init.c (revision 253911) > +++ sbin/init/init.c (working copy) > @@ -1729,7 +1729,8 @@ > login_cap_t *lc; > if ((lc =3D login_getclassbyname(cname, NULL)) !=3D NULL) { > setusercontext(lc, (struct passwd*)NULL, 0, > - LOGIN_SETPRIORITY | LOGIN_SETRESOURCES); > + LOGIN_SETPRIORITY | LOGIN_SETRESOURCES | > + LOGIN_SETLOGINCLASS); > login_close(lc); > } > } >=20 > Should I commit this? I think so. You also might want to add LOGIN_SETCPUMASK there.