cvs commit: ports/net/openntpd Makefile pkg-plist ports/net/openntpd/files openntpd.in openntpd.sh

[Doug Barton]

On Mon, 8 Oct 2007, Christian Weisgerber wrote:

> Doug Barton:
>
>>> http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/net/openntpd/files/openntpd.in
>>
>> Thanks for converting this to the new style. Quick questions, why is
>> BEFORE: LOGIN in there?
>
> I think I simply copied this from /etc/rc.d/ntpd.

D'oh! I suppose there is still a lot of cleanup to do. :-/

> The question where to start ntpd in the startup sequence is tricky.
> If people set openntpd's -s flag ("set the time immediately at startup
> if the local clock is off by more than 180 seconds"), then it should
> be started as early as possible, before other daemons and certainly
> before users log in.  If people don't set -s, then openntpd can
> start up late.

Is it possible to do two rc.d scripts for these different features? The 
way it is now, we have ntpdate which is run right after named (i.e., 
pretty early) and ntpd run after DAEMON but before LOGIN. The former is a 
compromise, I would like to run ntpdate (or the [open]ntpd related 
equivalent) much earlier, but there are some who think that requiring 
users to (potentially) have IP addresses in their conf files is not a good 
idea. I think that we run ntpd too late, but no one has ever really 
complained about it, so I'm loathe to change it.

My preference would be that you create two rc.d scripts as suggested 
above, and put the same REQUIRE lines as the ones in the base, and put 
BEFORE ntpdate and ntpd respectively. That should put them in pretty much 
the same order as the ones in the base are now.

If you need help with that, I'd be glad to give it a look.

>> Also you should probably add the shutdown KEYWORD.
>
> What for?  There is no particular shutdown action to be taken, no
> database to sync.

Fair enough. I have a plan to add the shutdown KEYWORD to the existing 
scripts in the base that start persistent services with the idea in mind 
of getting a more "orderly" shutdown process. If you don't feel that there 
is value in this for your application, no worries.

Doug

-- 

     This .signature sanitized for your protection