Re: CVS commit: src/etc/rc.d
i...@bsdimp.com said: > With ntpd -g, it means that time will be messed up until the time is > first set (which isn't after the first measurement). There are > several polling intervals, about a minute apart, that have to happen > before ntpd believes the time There is some "burst" option which should accelerate that. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: CVS commit: src/etc/rc.d
In message: <87y6px9cr9@snark.cb.piermont.com> "Perry E. Metzger" writes: : : "M. Warner Losh" writes: : > In message: <87ab2dat79@snark.cb.piermont.com> : > "Perry E. Metzger" writes: : > : : > : Frank Kardel writes: : > : > Actually we can retire ntpdate in rc unless we are very tight on : > : > memory. ntpd_flags should add the -g flag. This allows for a big : > : > (time setting) initial (and only one time) step in ntpd. : > : : > : I was made aware of that a few days ago. : > : > How long after startup does ntpd exit in this case? : : It doesn't. -g says that the initial time difference may be large and to : just step the time rather than slewing it on initial start. Then you : don't need ntpdate. (You *can* use ntpd with other flags to behave like : ntpdate but that's not the purpose here.) I think you've missed my point. With ntpdate the time is set when ntpdate is run, and the adjtime/ntpd_adjtime parameters aren't set (which is part of what I meant by 'not going to change', the other part is 'time will pass normally without jumps'). With ntpd -g, it means that time will be messed up until the time is first set (which isn't after the first measurement). There are several polling intervals, about a minute apart, that have to happen before ntpd believes the time (at least historically, I haven't checked the exact version in NetBSD). This means that different things in the system will start up with the wrong time. Eg, the system starts up with Jan 1, 1980 (lovely bios error, pick any other year you want, the example is still valid)... ntpd starts, as does sendmail, cron, sshd, etc. Then, a few minutes later, time jumps forward 29 years. Warner
Re: CVS commit: src/games/robots
On Wed, Aug 05, 2009 at 03:34:09PM -0400, Christos Zoulas wrote: > don't use char values for functions that can return -1; chars are not always > signed. sorry, that was stupid. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc/rc.d
On Thu, Aug 06, 2009 at 10:54:34AM -0400, Perry E. Metzger wrote: > > Frank Kardel writes: > > Actually we can retire ntpdate in rc unless we are very tight on > > memory. ntpd_flags should add the -g flag. This allows for a big > > (time setting) initial (and only one time) step in ntpd. > > I was made aware of that a few days ago. > > If we go that route, however, we will have to move ntpd to start much > earlier (where ntpdate currently runs), because various tools like the > kdc stuff require that the time be properly set before they execute. > > I'm willing to do that for -current but not for 5.0 (the fixes now in > -current are being pulled up.) Huh? The change itself is controversial, so it should NOT be pulled up right now. Bernd
Re: CVS commit: src/etc/rc.d
"M. Warner Losh" writes: > In message: <87ab2dat79@snark.cb.piermont.com> > "Perry E. Metzger" writes: > : > : Frank Kardel writes: > : > Actually we can retire ntpdate in rc unless we are very tight on > : > memory. ntpd_flags should add the -g flag. This allows for a big > : > (time setting) initial (and only one time) step in ntpd. > : > : I was made aware of that a few days ago. > > How long after startup does ntpd exit in this case? It doesn't. -g says that the initial time difference may be large and to just step the time rather than slewing it on initial start. Then you don't need ntpdate. (You *can* use ntpd with other flags to behave like ntpdate but that's not the purpose here.) > Just be careful here about the races here... ntpdate guaranteed the > time was set and wasn't going to change... It guaranteed that the time was set -- not that it would not change. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/etc/rc.d
Marc Balmer writes: >> Frank Kardel writes: >>> Actually we can retire ntpdate in rc unless we are very tight on >>> memory. ntpd_flags should add the -g flag. This allows for a big >>> (time setting) initial (and only one time) step in ntpd. >> >> I was made aware of that a few days ago. >> >> If we go that route, however, we will have to move ntpd to start much >> earlier (where ntpdate currently runs), because various tools like the >> kdc stuff require that the time be properly set before they execute. > > I have a question here: Does that mean that we always have to run > ntpd if we want exact time at startup? Or has ntpd a mode where it > syncs the time one time and then exit? > > If it has not, maybe ntpdate should stay. There is no reason we can't also leave around ntpdate for people who prefer not to run ntpd at all, but yes, one would then either one run or the other early during the startup sequence. A number of tools require that the date be properly set before they are started and so one or the other would need to be started before them. We could presumably provide a pseudo-dependency (TIME or some such) that any such tools would DEPEND on. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/etc/rc.d
Am 06.08.2009 um 17:08 schrieb Marc Balmer: Am 06.08.2009 um 16:54 schrieb Perry E. Metzger: Frank Kardel writes: Actually we can retire ntpdate in rc unless we are very tight on memory. ntpd_flags should add the -g flag. This allows for a big (time setting) initial (and only one time) step in ntpd. I was made aware of that a few days ago. If we go that route, however, we will have to move ntpd to start much earlier (where ntpdate currently runs), because various tools like the kdc stuff require that the time be properly set before they execute. I have a question here: Does that mean that we always have to run ntpd if we want exact time at startup? Or has ntpd a mode where it syncs the time one time and then exit? If it has not, maybe ntpdate should stay. I can answer it myself ;) it can... sorry for the noise... - Marc I'm willing to do that for -current but not for 5.0 (the fixes now in -current are being pulled up.) This is the ntpdate functionality with ntpd normally continuing afterwards. ntpd is fine when the network is up with loopback interfaces only. It will discover interfaces going up/down automatically and re-trigger name resolution when new interfaces come up and unresolved dns-names still exist. That seems like quite a good thing. We should probably do that, moving ntpd much earlier in the system startup and making kdc etc. depend on ntpd instead of ntpdate. Are you willing to do the work? I don't have time for some days. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/etc/rc.d
In message: <87ab2dat79@snark.cb.piermont.com> "Perry E. Metzger" writes: : : Frank Kardel writes: : > Actually we can retire ntpdate in rc unless we are very tight on : > memory. ntpd_flags should add the -g flag. This allows for a big : > (time setting) initial (and only one time) step in ntpd. : : I was made aware of that a few days ago. How long after startup does ntpd exit in this case? How long does it take to make the time measurements? Does it do this in parallel or before it calls daemon? The reason I ask is that I know ntpd used to have issues with this, and you'd get a time jump after it started. Have they been fixed? : If we go that route, however, we will have to move ntpd to start much : earlier (where ntpdate currently runs), because various tools like the : kdc stuff require that the time be properly set before they execute. : : I'm willing to do that for -current but not for 5.0 (the fixes now in : -current are being pulled up.) : : > This is the ntpdate functionality with ntpd normally continuing : > afterwards. ntpd is fine when the network is up with loopback : > interfaces only. It will discover interfaces going up/down : > automatically and re-trigger name resolution when new interfaces come : > up and unresolved dns-names still exist. : : That seems like quite a good thing. We should probably do that, moving : ntpd much earlier in the system startup and making kdc etc. depend on : ntpd instead of ntpdate. Are you willing to do the work? I don't have : time for some days. Just be careful here about the races here... ntpdate guaranteed the time was set and wasn't going to change... Warner
Re: CVS commit: src/etc/rc.d
Am 06.08.2009 um 16:54 schrieb Perry E. Metzger: Frank Kardel writes: Actually we can retire ntpdate in rc unless we are very tight on memory. ntpd_flags should add the -g flag. This allows for a big (time setting) initial (and only one time) step in ntpd. I was made aware of that a few days ago. If we go that route, however, we will have to move ntpd to start much earlier (where ntpdate currently runs), because various tools like the kdc stuff require that the time be properly set before they execute. I have a question here: Does that mean that we always have to run ntpd if we want exact time at startup? Or has ntpd a mode where it syncs the time one time and then exit? If it has not, maybe ntpdate should stay. - Marc I'm willing to do that for -current but not for 5.0 (the fixes now in -current are being pulled up.) This is the ntpdate functionality with ntpd normally continuing afterwards. ntpd is fine when the network is up with loopback interfaces only. It will discover interfaces going up/down automatically and re-trigger name resolution when new interfaces come up and unresolved dns-names still exist. That seems like quite a good thing. We should probably do that, moving ntpd much earlier in the system startup and making kdc etc. depend on ntpd instead of ntpdate. Are you willing to do the work? I don't have time for some days. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/etc/rc.d
Frank Kardel writes: > Actually we can retire ntpdate in rc unless we are very tight on > memory. ntpd_flags should add the -g flag. This allows for a big > (time setting) initial (and only one time) step in ntpd. I was made aware of that a few days ago. If we go that route, however, we will have to move ntpd to start much earlier (where ntpdate currently runs), because various tools like the kdc stuff require that the time be properly set before they execute. I'm willing to do that for -current but not for 5.0 (the fixes now in -current are being pulled up.) > This is the ntpdate functionality with ntpd normally continuing > afterwards. ntpd is fine when the network is up with loopback > interfaces only. It will discover interfaces going up/down > automatically and re-trigger name resolution when new interfaces come > up and unresolved dns-names still exist. That seems like quite a good thing. We should probably do that, moving ntpd much earlier in the system startup and making kdc etc. depend on ntpd instead of ntpdate. Are you willing to do the work? I don't have time for some days. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src (gpio)
Am 04.08.2009 um 09:11 schrieb Geoff Wing: On Saturday 2009-07-25 16:20 +, Marc Balmer output: :Module Name: src :Committed By: mbalmer :Date: Sat Jul 25 16:20:11 UTC 2009 [...] :Added Files: : src/etc: gpio.conf : src/etc/rc.d: gpio : src/share/man/man5: gpio.conf.5 Add postinstall(8) stuff, please. I committed your diff, thanks! Regards, Geoff Index: usr.sbin/postinstall/postinstall === RCS file: /cvsroot/src/usr.sbin/postinstall/postinstall,v retrieving revision 1.100 diff -u -r1.100 postinstall --- usr.sbin/postinstall/postinstall20 Jul 2009 21:03:42 - 1.100 +++ usr.sbin/postinstall/postinstall4 Aug 2009 07:08:19 - @@ -997,6 +997,7 @@ ccd cgd cleartmp cron \ dhclient dhcpcd dhcpd dhcrelay dmesg downinterfaces envsys \ fsck fsck_root ftp_proxy ftpd \ + gpio \ hostapd httpd \ identd ifwatchd inetd ipfilter ipfs ipmon ipnat ipsec \ irdaattach iscsi_target isdnd \
