From owner-svn-src-all@FreeBSD.ORG Mon Feb 6 08:28:21 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36089106564A; Mon, 6 Feb 2012 08:28:21 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC528FC14; Mon, 6 Feb 2012 08:28:20 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id DC39E924; Mon, 6 Feb 2012 09:28:18 +0100 (CET) Date: Mon, 6 Feb 2012 09:27:06 +0100 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20120206082706.GA1324@garage.freebsd.pl> References: <201202011641.q11Gf0j6095461@svn.freebsd.org> <20120204074201.GA1694@garage.freebsd.pl> <4F2CEB1D.10607@zonov.org> <27A0A960-F767-4D2C-BF3E-31F73FBF4E28@palisadesystems.com> <86zkcy5ur9.fsf@kopusha.home.net> <20120205093938.GC30033@garage.freebsd.pl> <86lioh7yz5.fsf@kopusha.home.net> <20120205214647.GI30033@garage.freebsd.pl> <86sjiov29o.fsf@in138.ua3> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <86sjiov29o.fsf@in138.ua3> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, Guy Helmer , svn-src-all@FreeBSD.org, Andrey Zonov , src-committers@FreeBSD.org Subject: Re: svn commit: r230869 - head/usr.sbin/daemon X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 08:28:21 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 06, 2012 at 09:39:47AM +0200, Mikolaj Golub wrote: >=20 > On Sun, 5 Feb 2012 22:46:48 +0100 Pawel Jakub Dawidek wrote: >=20 > PJD> On Sun, Feb 05, 2012 at 11:27:10PM +0200, Mikolaj Golub wrote: > >> Ok, using hastd code as a reference :-) here is my implementation. >=20 > PJD> - I'd not pass selected signals to the child. The parent can still = be > PJD> killed with a whole bunch of different signals that are not passe= d or > PJD> cannot be caught or the child process handle them gracefully. > PJD> Signals should be send to the PID from the pidfile anyway. If som= eone > PJD> is sending signals to the parent he has no right to expect well > PJD> behaviour from the parent. >=20 > Well, sending a whole bunch of different signals to parent we might not e= xpect > right behavior, but why not to provide it for the "standard" ones? E.g. on > shutdown init(8) will send SIGTERM and the daemon will gracefully exit > terminating the child and cleaning up the pidfile. If the the child proce= ss > does not handle SIGTERM gracefully I don't see much difference from having > only this one process alive or two (with its monitoring daemon). >=20 > The pidfile is seen in ps(1) output for the daemon process, which allows = to > identify the monitoring daemon with its child. Or we could change its > proctitle to something like "daemon: cmdname[pid]", similar to what sshd = does. > So people would expect that terminating a daemon will terminate the proce= ss it > monitors. >=20 > PJD> - Now that we handle the pidfile fully in the parent, I'd move drop= ping > PJD> provileges after fork(2) and pidfile_write(3). This way pidfiles = will > PJD> always be created with root privileges and we can forget about al= l the > PJD> mess with pid directories, etc. >=20 > PJD> - With the above you can wait for child to exit with simple wait(2). >=20 > Yes, it looks like much simpler, see the attached patch. But I don't thin= k I > like it much as it still looks like a half measure to me. I like this approach much better, as it is just simpler, but it is your call, Mikolaj. For the patch itself. You don't have to have two separate cases depending on request for pidfile. You can specify NULL pfh to the pidfile functions. Even in example from the manual page when pfh is NULL there is a case where we warn, but continue execution and call pidfile functions. This should simplify the code. If you do that (actually even if you don't), remember to either use warn(3) before pidfile_remove(3) and exit(3) after or preserve errno before calling pidfile_remove(3), as pidfile_remove(3) can modify it if unlink(2) is unsuccessful or pfh is NULL. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --0F1p//8PRICkK4MW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8vjtoACgkQForvXbEpPzRTWwCfUaxD+cpq07A2KXKLwmhUOe0L GaIAoI5fnVF3erG5aeJmPa8ROu46e464 =p6W1 -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW--