[net/openntpd] pidfile support

[Tomek Wałaszek]

2014-06-02 12:06 GMT+02:00 Tomek Wałaszek <tmwalaszek at gmail.com>:

>
> 2014-06-01 23:30 GMT+02:00 Christian Weisgerber <naddy at mips.inka.de>:
>
> On 2014-05-31, Tomek Wałaszek <tmwalaszek at gmail.com> wrote:
>>
>> > I was missing pid file support in OpenNTPD. I've created a patch that
>> > enables pidfile /var/run/ntpd.pid in OpenNTPD and now I can define in
>> the
>>
>> Well, upstream doesn't support a pid file on purpose.  (General
>> OpenBSD policy.)  The argument is that the pid file construct is
>> inherently unreliable and dangerous: if the daemon dies, the pid
>> file remains and the pid may point to some random other process.
>>
>> > rc script pidfile location. With pidfile location I dont see any more
>> this
>> > annoying message when restarting and stopping:
>> >
>> > [root at vps24009 ~]# /usr/local/etc/rc.d/openntpd stop
>> > Stopping openntpd.
>> > kill: 20188: No such process
>> > kill: 20189: No such process
>>
>> Yes, this is an unfortunate race.  The fix would be to match the
>> process name against "ntpd: [priv]", the same way OpenBSD's native
>> rc script does.  Unfortunately, this seems to be impossible with
>> rc.subr(8): only the first word of the process is matched against
>> procname.
>>
>> I could override check_process; see below.  Not sure how good or
>> bad an idea that is.
>>
>> This is a general issue that should affect other daemons ported
>> from OpenBSD as well, e.g. net/openbgpd.
>>
>> Index: files/openntpd.in
>> ===================================================================
>> --- files/openntpd.in   (revision 356166)
>> +++ files/openntpd.in   (working copy)
>> @@ -15,6 +15,11 @@
>>
>>  . /etc/rc.subr
>>
>> +check_process()
>> +{
>> +        /bin/pgrep -f 'ntpd: \[priv\]'
>> +}
>> +
>>  name=openntpd
>>  rcvar=openntpd_enable
>>
>>
>> --
>> Christian "naddy" Weisgerber                          naddy at mips.inka.de
>> _______________________________________________
>> freebsd-ports at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>
>
> Hello,
> Yes, the fix will work but it will be not a generic solution.
> Maybe for those types of programs we should have a generic solution? For
> example add a variable leader="YES", and if this variable will be set then
> the rc script will kill only the 'master' process?
> I wrote a simple patch for the rc.subr, I dont know whether this solution
> is good but anyway it works for me :P
> Patch is in the attachment :)
>
> Regards,
> Tomasz Walaszek
>



-- 
Pozdrawiam
Tomasz Wałaszek