Date: Mon, 6 Feb 2012 09:27:06 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Mikolaj Golub <trociny@freebsd.org> Cc: svn-src-head@FreeBSD.org, Guy Helmer <ghelmer@palisadesystems.com>, svn-src-all@FreeBSD.org, Andrey Zonov <andrey@zonov.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r230869 - head/usr.sbin/daemon Message-ID: <20120206082706.GA1324@garage.freebsd.pl> In-Reply-To: <86sjiov29o.fsf@in138.ua3> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120206082706.GA1324>