El 2003-07-09 a las 13:37, C Hamel escribió:
(You forgot to post to the list)
I am afraid I don't even know how to ask a question, at this point, but I'll make an attempt: Exactly where should this ntp thing be called to set the clock ...or(/and) by what process?
It is a very proper question :-)
Well, it depends. There are two ways. If your computer is up all the time, and has a permanent network connection, you can use the ntpd daemon, which polls a set of servers about once a minute, and _very_ slowly adjusts the system clock; it can even note the systematic error or drift, and take that in to account to discipline the system clock.
There are many options available for the daemon: see full doc in: http://localhost/usr/share/doc/packages/xntp-doc/html/index.htm
Or, you may have a temporary network connection, like I do; I will explain this in some detail.
We can adjust the clock to "internet" time, once, sometime after we connect to internet. This, apparently, can be done with the daemon, using some option I don't fully understand. Or we can use ntpdate - a program which is to disappear some time in the future, but that I use, and SuSE uses as well in its own script.
For this, we can simply call "/etc/init.d/xntpd ntptimeset" - and assume that when "ntpdate" finally disappears SuSE will adjust the script appropriately ;-)
Of course, /etc/ntp.conf has to be configured; at least, it must have a list of servers:
server IP_address server name_address
This is sufficient for "xntpd ntptimeset" to work; just leave the rest of the config at the default values. If you want to use the daemon, then I'm not the person to ask :-)
Ok, so when is the appropriate time to make this time adjust? Well, ideally, during system boot-up, after network connection is established. This is done properly by the service xntpd, if enabled. The SuSE script "/etc/init.d/xntpd start" does first a clock set using ntpdate, if the variable XNTPD_INITIAL_NTPDATE is set to "AUTO". Then, it starts the daemon to keep time synchronized.
And, if our network connection is not permanent? Then, the script "/etc/ppp/poll.tcpip", which is called from "/etc/ppp/ip-up", will adjust the clock first thing: assuming we have some servers configured, it will be done every time we connect to internet with the modem. I do it differently, only once every five times, and I also update the hwclock.
The danger of this method is that the clock might suddenly go forward or backward a bit (seconds or hours, it depends): not very nice on a *nix system, but we can not avoid it.
More details to be aware of: what happens to the hardware or CMOS clock?
Well, the script "/etc/init.d/boot.clock" (read it, it is documented) does this sequence of things (using the command "hwclock") before starting system services:
- Create if it doesn't exist, the file "/etc/adjtime" - Adjust hardware clock (CMOS) for known drift during the time the computer has been off; this depends on the previous file to work. - Copy CMOS clock (hardware) to system time (CPU and OS maintained).
After this, the system goes fully up, and maybe, the clock is adjusted from the internet or by hand (danger!). But (and this is very different than windows) the CPU maintained clock has to be copied back to the CMOS, because the kernel doesn't do it. SuSE does it in the script "/etc/init.d/halt" that copies system time to hardware time just before power off. Me, I prefer to do it just after I adjust to network time, inside "ip-up.local", like this:
/usr/sbin/rcxntpd ntptimeset /sbin/hwclock --systohc
More things to be aware of: a common mistake is manually adjusting the system clock from kde control center (for example), and not updating the hwclock at the same time: the drift adjust algorithm of hwclock thinks that the CMOS clock is fast or slow by the same amount you adjusted the clock, and the next boot it will adjust the time by several hours... The solution is to delete "/etc/adjtime" and call "/sbin/hwclock --systohc" just then (documented on the SuSE sdb).
Well, this has been enough chatter on my part; let's hope I didn't make many mistakes :-)
On Wednesday 09 July 2003 19:31, (A long time ago) Carlos E. R. wrote:
..........<snipped some>..........
Or, you may have a temporary network connection, like I do; I will explain this in some detail.
Please do, I have been fooling with this for months now, off and on, and have yet to make this work successfully.
We can adjust the clock to "internet" time, once, sometime after we connect to internet. This, apparently, can be done with the daemon, using some option I don't fully understand. Or we can use ntpdate - a program which is to disappear some time in the future, but that I use, and SuSE uses as well in its own script.
ntpdate is still with us. I invoke it manually as root every once in awhile to update my time,
For this, we can simply call "/etc/init.d/xntpd ntptimeset" - and assume that when "ntpdate" finally disappears SuSE will adjust the script appropriately ;-)
So far, so good :-)
Of course, /etc/ntp.conf has to be configured; at least, it must have a list of servers:
server IP_address server name_address
This is what I normally invoke manually: ntpdate 216.139.201.6 and then I do a hwclock --systohc
And that would go where? In this line found about half way down the script? ## # server 127.127.8.0 mode 5 prefer
This is sufficient for "xntpd ntptimeset" to work; just leave the rest of the config at the default values.
Ok, so when is the appropriate time to make this time adjust? Well, ideally, during system boot-up, after network connection is established. This is done properly by the service xntpd, if enabled. The SuSE script "/etc/init.d/xntpd start" does first a clock set using ntpdate, if the variable XNTPD_INITIAL_NTPDATE is set to "AUTO". Then, it starts the daemon to keep time synchronized.
OK, it does that but is based on what exists at that time though, right ? and would be updated at the next boot-up for the adjusted time, right ? And that would be accomplished via the dial-up connection as per below.
And, if our network connection is not permanent? Then, the script "/etc/ppp/poll.tcpip", which is called from "/etc/ppp/ip-up", will adjust the clock first thing: assuming we have some servers configured, it will be done every time we connect to internet with the modem. I do it differently, only once every five times, and I also update the hwclock.
As per what you do. I dial up, download my mail or whatever, sign off and then not dial up again until needed. Maybe 5 to 20 minutes at a time. There may be times where I do this 4 or 5 time during one session of several hours. And, how do you update the hwclock, from the same script/command ??
This is what is in the ip-up script.
run_poll_tcpip() { [ "$RUN_POLL_TCPIP" = "no" ] && return
/etc/ppp/poll.tcpip | logger -p security.notice -t poll.tcpip
The danger of this method is that the clock might suddenly go forward or backward a bit (seconds or hours, it depends): not very nice on a *nix system, but we can not avoid it.
Hey, that is the way it is !!
More details to be aware of: what happens to the hardware or CMOS clock?
Well, the script "/etc/init.d/boot.clock" (read it, it is documented) does this sequence of things (using the command "hwclock") before starting system services:
- Create if it doesn't exist, the file "/etc/adjtime"
Have an adjtime
- Adjust hardware clock (CMOS) for known drift during the time the
computer has been off; this depends on the previous file to work.
- Copy CMOS clock (hardware) to system time (CPU and OS
maintained).
????
After this, the system goes fully up, and maybe, the clock is adjusted from the internet or by hand (danger!). But (and this is very different than windows) the CPU maintained clock has to be copied back to the CMOS, because the kernel doesn't do it. SuSE does it in the script "/etc/init.d/halt" that copies system time to hardware time just before power off. Me, I prefer to do it just after I adjust to network time, inside "ip-up.local", like this:
Don't have an ip-up.local file, and ip-up says "don't edit". Does it make a difference ? Either is fine by me unless there is some specific reason.
/usr/sbin/rcxntpd ntptimeset /sbin/hwclock --systohc
More things to be aware of: a common mistake is manually adjusting the system clock from kde control center (for example), and not updating the hwclock at the same time: the drift adjust algorithm of hwclock thinks that the CMOS clock is fast or slow by the same amount you adjusted the clock, and the next boot it will adjust the time by several hours... The solution is to delete "/etc/adjtime" and call "/sbin/hwclock --systohc" just then (documented on the SuSE sdb).
I never adust the time manually. Always call ntpdate and hwclock.
Your explanation was very enlightening re: how the whole time thing works. That is good and adds to our knowledge. However, it is still not clear to me as to the way to adjust the time when I go on-line and keep the system accurate to a reasonable degree.
Would appreciate a step-by-step saying put this line here and that line there.
Bob S.
The Wednesday 2005-02-09 at 21:48 -0500, B. Stia wrote:
On Wednesday 09 July 2003 19:31, (A long time ago) Carlos E. R. wrote:
Uau!
Actually, it was:
Date: Thu, 10 Jul 2003 01:31:55 +0200 (CEST) From: Carlos E. R. Subject: Re: [SLE] Time synch problem X-Message-Number-for-archive: 152757
I have a longish archive :-)
..........<snipped some>..........
Or, you may have a temporary network connection, like I do; I will explain this in some detail.
Please do, I have been fooling with this for months now, off and on, and have yet to make this work successfully.
I wrote a micro-howto, posted at Togan's Unofficial SuSE FAQ, that has about the same info, a bit more organized and expanded.
We can adjust the clock to "internet" time, once, sometime after we connect to internet. This, apparently, can be done with the daemon, using some option I don't fully understand. Or we can use ntpdate - a program which is to disappear some time in the future, but that I use, and SuSE uses as well in its own script.
ntpdate is still with us. I invoke it manually as root every once in awhile to update my time,
I know. But, as I said just below, calling "rcxntpd ntptimeset" is safer and easier.
For this, we can simply call "/etc/init.d/xntpd ntptimeset" - and assume that when "ntpdate" finally disappears SuSE will adjust the script appropriately ;-)
So far, so good :-)
Of course, /etc/ntp.conf has to be configured; at least, it must have a list of servers:
server IP_address server name_address
This is what I normally invoke manually: ntpdate 216.139.201.6 and then I do a hwclock --systohc
And that would go where? In this line found about half way down the script? ## # server 127.127.8.0 mode 5 prefer
Well, simply:
server 216.139.201.6
should work. Right now, I don't know about "mode" and the other options, but I don't think they matter. I'd have to verify.
Notice that calling "rcxntpd ntptimeset" is equivalent to calling "ntpdate x.x.x.x". You can add several servers, and it will contact all of them and use the best time available.
This is sufficient for "xntpd ntptimeset" to work; just leave the rest of the config at the default values.
Ok, so when is the appropriate time to make this time adjust? Well, ideally, during system boot-up, after network connection is established. This is done properly by the service xntpd, if enabled. The SuSE script "/etc/init.d/xntpd start" does first a clock set using ntpdate, if the variable XNTPD_INITIAL_NTPDATE is set to "AUTO". Then, it starts the daemon to keep time synchronized.
OK, it does that but is based on what exists at that time though, right ? and would be updated at the next boot-up for the adjusted time, right ? And that would be accomplished via the dial-up connection as per below.
I don't quite follow. Ok, I'll rephrase. If you have a permanent network connection, then you can define service "xntpd" to run (chkconfig xntpd on) to run during system init. This will set up the clock correctly on every boot, querying a remote server for the date/time.
If you don't, then the other method applies.
In any case, that is different of the automatic drift adjustment based on /etc/adjtime file.
(See the "further reading" at the end of this email)
And, if our network connection is not permanent? Then, the script "/etc/ppp/poll.tcpip", which is called from "/etc/ppp/ip-up", will adjust the clock first thing: assuming we have some servers configured, it will be done every time we connect to internet with the modem. I do it differently, only once every five times, and I also update the hwclock.
As per what you do. I dial up, download my mail or whatever, sign off and then not dial up again until needed. Maybe 5 to 20 minutes at a time. There may be times where I do this 4 or 5 time during one session of several hours. And, how do you update the hwclock, from the same script/command ??
This is what is in the ip-up script.
run_poll_tcpip() { [ "$RUN_POLL_TCPIP" = "no" ] && return
/etc/ppp/poll.tcpip | logger -p security.notice -t poll.tcpip
The danger of this method is that the clock might suddenly go forward or backward a bit (seconds or hours, it depends): not very nice on a *nix system, but we can not avoid it.
Hey, that is the way it is !!
More details to be aware of: what happens to the hardware or CMOS clock?
Well, the script "/etc/init.d/boot.clock" (read it, it is documented) does this sequence of things (using the command "hwclock") before starting system services:
- Create if it doesn't exist, the file "/etc/adjtime"
Have an adjtime
- Adjust hardware clock (CMOS) for known drift during the time the
computer has been off; this depends on the previous file to work.
- Copy CMOS clock (hardware) to system time (CPU and OS
maintained).
????
There are two clocks. Read my howto, I explain it there.
After this, the system goes fully up, and maybe, the clock is adjusted from the internet or by hand (danger!). But (and this is very different than windows) the CPU maintained clock has to be copied back to the CMOS, because the kernel doesn't do it. SuSE does it in the script "/etc/init.d/halt" that copies system time to hardware time just before power off. Me, I prefer to do it just after I adjust to network time, inside "ip-up.local", like this:
Don't have an ip-up.local file, and ip-up says "don't edit". Does it make a difference ? Either is fine by me unless there is some specific reason.
ip-up calls ip-up.local if it exists. Add your things to ip-up.local only.
/usr/sbin/rcxntpd ntptimeset /sbin/hwclock --systohc
More things to be aware of: a common mistake is manually adjusting the system clock from kde control center (for example), and not updating the hwclock at the same time: the drift adjust algorithm of hwclock thinks that the CMOS clock is fast or slow by the same amount you adjusted the clock, and the next boot it will adjust the time by several hours... The solution is to delete "/etc/adjtime" and call "/sbin/hwclock --systohc" just then (documented on the SuSE sdb).
I never adust the time manually. Always call ntpdate and hwclock.
Your explanation was very enlightening re: how the whole time thing works. That is good and adds to our knowledge. However, it is still not clear to me as to the way to adjust the time when I go on-line and keep the system accurate to a reasonable degree.
Would appreciate a step-by-step saying put this line here and that line there.
Ok, there are two automatic ways. If your system runs /etc/ppp/poll.tcpip (ie, you have not disabled it), that will do. It contains the following code:
# # Now set system time if we have some NTP servers # and no running xntp. # while true ; do set -- $(/sbin/runlevel) test -e /etc/init.d/rc${2}.d/S*xntpd && break test -x /usr/sbin/ntpdate || break checkproc /usr/sbin/xntpd &> /dev/null && break /usr/sbin/rcxntpd ntptimeset break done
Else, add something like this to /etc/ppp/ip-up.local
/etc/init.d/xntpd ntptimeset &> $NTPDATEOUT . /etc/sysconfig/clock /sbin/hwclock --systohc $HWCLOCK # If HWCLOCK is for localtime or UTC. If not present, by default it uses whatever was done the last time. # I put it just in case I deleted the /etc/adjtime file, because in that case it would use localtime.
My script does a few extra things, like syncing only once per day. I haven't copied that for simplicity.
... some days later...
[ further reading ;-) ]
The sequence of events is this:
* Boot. Run /etc/init.d/boot.clock Check for existence of '/etc/adjtime', create if not. Get time and date from the CMOS clock, adjusting for drift, with command: /sbin/hwclock --adjust $HWCLOCK Continue with boot, enter runlevel 2, 3 or 5 If service xntpd is enabled (1), run /etc/init.d/boot.clock/xntpd (after $remote_fs $syslog $named are running) Using the network, get correct time and set the clock, right now. Start the xntpd daemon to keep the clock in time. Continue boot.
* System running. One of two things may happen: If enabled, the xntpd daemon keeps the system clock on its toes. If not, then ntpdate or 'rcxntpd ntptimeset' can be called as soon as network goes up to update the time. This is done from '/etc/ppp/poll.tcpip' without user intervention. (2)
* System stopping. ... The xntpd daemon stops. ... Copy system time to cmos clock, calculate drift (3).
Notes:
(1) Running xntp only makes sense if you have a permanent network connection.
(2) The pppd daemon calls '/etc/ppp/ip-up' if present. This script, wrote by SuSE, calls 'poll.tcpip' and 'ip-up.local', if present. This behaviour can be disabled by setting 'RUN_POLL_TCPIP = no' - theoretically in '/etc/sysconfig/network/ifcfg-ppp0' (because it appears to break '/sbin/conf.d/SuSEconfig.hostname')
(3) If at this point the time is incorrect, the CMOS clock will be set incorrectly; and worse, the '/etc/adjtime' file will store the wrong drift. Perhaps it would make sense to disable it.
The Tuesday 2005-02-15 at 21:50 +0100, I wrote:
...
The sequence of events is this:
Boot. Run /etc/init.d/boot.clock Check for existence of '/etc/adjtime', create if not. Get time and date from the CMOS clock, adjusting for drift, with command: /sbin/hwclock --adjust $HWCLOCK Continue with boot, enter runlevel 2, 3 or 5 If service xntpd is enabled (1), run /etc/init.d/boot.clock/xntpd (after $remote_fs $syslog $named are running) Using the network, get correct time and set the clock, right now. Start the xntpd daemon to keep the clock in time. Continue boot.
System running. One of two things may happen: If enabled, the xntpd daemon keeps the system clock on its toes. If not, then ntpdate or 'rcxntpd ntptimeset' can be called as soon as network goes up to update the time. This is done from '/etc/ppp/poll.tcpip' without user intervention. (2)
System stopping. ... The xntpd daemon stops. ... Copy system time to cmos clock, calculate drift (3).
Notes:
(1) Running xntp only makes sense if you have a permanent network connection.
(2) The pppd daemon calls '/etc/ppp/ip-up' if present. This script, wrote by SuSE, calls 'poll.tcpip' and 'ip-up.local', if present. This behaviour can be disabled by setting 'RUN_POLL_TCPIP = no' - theoretically in '/etc/sysconfig/network/ifcfg-ppp0' (because it appears to break '/sbin/conf.d/SuSEconfig.hostname')
(3) If at this point the time is incorrect, the CMOS clock will be set incorrectly; and worse, the '/etc/adjtime' file will store the wrong drift. Perhaps it would make sense to disable it.
Further adjustments for those without a permanent internet connection: tuning the hwclock (cmos).
When the connection goes up, /etc/ppp/poll.tcpip does this:
while true ; do set -- $(/sbin/runlevel) test -e /etc/init.d/rc${2}.d/S*xntpd && break test -x /usr/sbin/ntpdate || break checkproc /usr/sbin/xntpd &> /dev/null && break /usr/sbin/rcxntpd ntptimeset break done
Later, when the system stops, the hardware clock is updated in "/etc/init.d/boot.clock":
stop) if [ "$HOSTTYPE" != "s390" -a "$HOSTTYPE" != "s390x" ] ; then echo -n "Set Hardware Clock to the current System Time" /sbin/hwclock --systohc $HWCLOCK rc_status -v -r fi ;;
I mentioned previously that, if xntpd was not running, the system clock may be off at that instant, and thus, the hardware clock will be set incorrectly, and also '/etc/adjtime' will contain the wrong adjustment. Therefore, I commented out the '/sbin/hwclock' line above. Instead, I use the following script in '/etc/ppp/ip-up.local' (I have 'poll.tcpip' disabled):
. /etc/sysconfig/clock /usr/sbin/rcxntpd ntptimeset &> $FLAG_BOOTED_PPP /sbin/hwclock --systohc $HWCLOCK
However, I noticed that the adjustment did not became better over the days:
Feb 14 19:56:47 nimrodel ntpdate[7151]: adjust time server x.y.z.w offset -0.208596 sec Feb 15 11:52:53 nimrodel ntpdate[7200]: step time server x.y.z.w offset -0.592240 sec Feb 15 19:46:38 nimrodel ntpdate[7218]: step time server x.y.z.w offset -0.523598 sec Feb 16 14:35:21 nimrodel ntpdate[7783]: step time server x.y.z.w offset -0.954435 sec Feb 17 11:18:22 nimrodel ntpdate[7247]: step time server x.y.z.w offset -0.725295 sec Feb 18 13:08:47 nimrodel ntpdate[7238]: step time server x.y.z.w offset -0.657556 sec Feb 18 20:55:15 nimrodel ntpdate[8900]: adjust time server x.y.z.w offset 0.197868 sec Feb 19 21:45:32 nimrodel ntpdate[7189]: adjust time server x.y.z.w offset 0.311187 sec Feb 20 11:40:32 nimrodel ntpdate[9744]: adjust time server x.y.z.w offset -0.121958 sec Feb 20 14:24:58 nimrodel ntpdate[7839]: step time server x.y.z.w offset -0.704849 sec Feb 20 20:38:18 nimrodel ntpdate[7761]: step time server x.y.z.w offset -0.732385 sec Feb 21 13:27:32 nimrodel ntpdate[7804]: adjust time server x.y.z.w offset -0.328831 sec Feb 22 11:49:48 nimrodel ntpdate[7149]: adjust time server x.y.z.w offset -0.467263 sec
Then, it occurred to me that when ntpdate "adjusts" instead of "steps", the clock is not immediately correct, because the system clock is slowly adjusted: it can be adjusted at most .5 seconds over a period of 10 minutes - see how it slowly gets in sync:
Feb 22 11:50:38 nimrodel ntpdate[7252]: adjust time server x.y.z.w offset -0.426417 sec Feb 22 11:51:53 nimrodel ntpdate[7556]: adjust time server x.y.z.w offset -0.350410 sec Feb 22 11:56:06 nimrodel ntpdate[7599]: adjust time server x.y.z.w offset -0.096976 sec Feb 22 11:57:22 nimrodel ntpdate[7619]: adjust time server x.y.z.w offset -0.025964 sec Feb 22 11:57:49 nimrodel ntpdate[7639]: adjust time server x.y.z.w offset 0.007841 sec Feb 22 11:59:55 nimrodel ntpdate[7740]: adjust time server x.y.z.w offset 0.002169 sec
Thus, the call to /sbin/hwclock should be delayed 10 minutes. My setup is, at this moment, is like this:
* During boot, I remove a flag file. * On the first internet connection, I sync time (and only once), and before fetching mail (ie, before the modem becomes "busy").
** /etc/init.d/boot.local:
FLAG_BOOTED_PPP=/etc/ppp/SYSTEM_WAS_SYNCRONIZED if test -f $FLAG_BOOTED_PPP ; then rm $FLAG_BOOTED_PPP fi
** /etc/ppp/ip-up.local
SERVICE_NAME=ip-up.local FLAG_BOOTED_PPP=/etc/ppp/SYSTEM_WAS_SYNCRONIZED
if ! test -f $FLAG_BOOTED_PPP ; then /bin/logger -t $SERVICE_NAME -p user.info " --> Synchronizing time" /usr/bin/play $VOLUMEN /usr/share/sounds/wav/clock.wav &> /dev/null &
/usr/sbin/rcxntpd ntptimeset &> $FLAG_BOOTED_PPP # Time can be "adjusted" or "stepped" by xntpd. In the first case, the # system time is not correct till some time later; assuming that it # only "adjusts" for at most .5S, the clock will be correct before 10 # minutes. Therefore, I delay setting the hardware clock: /usr/bin/at -f /etc/ppp/hwclock now + 10 minutes /bin/logger -t $SERVICE_NAME -p user.info -f $FLAG_BOOTED_PPP fi
** /etc/ppp/hwclock
#!/bin/bash # Serves to be called from "at", called from ip-up.local.doit . /etc/sysconfig/clock /sbin/hwclock --systohc $HWCLOCK
I'll see what happens over several days. Of course, there is room for further improvement: I could sync time not only once after booting, but say, once ever four hours. Also, the system clock could be disciplined, as some poster mentioned here time ago.
P.S: Remember, all this is for people not having a permanent network connection, and not running xntpd.
Hi, Carlos,
It seems you have some time on your hands...
On Tuesday 22 February 2005 05:07, Carlos E. R. wrote:
...
Further adjustments for those without a permanent internet connection: tuning the hwclock (cmos).
When the connection goes up, /etc/ppp/poll.tcpip does this:
while true ; do set -- $(/sbin/runlevel) test -e /etc/init.d/rc${2}.d/S*xntpd && break test -x /usr/sbin/ntpdate || break checkproc /usr/sbin/xntpd &> /dev/null && break /usr/sbin/rcxntpd ntptimeset break done
It seems to me there's nothing to keep this loop from saturating the CPU if none of the conditions that allow it to terminate are met. Perhaps a "sleep" following the invocation of rcxntpd?
This brings up another thing I just learned recently:
SLEEP(1) User Commands SLEEP(1)
NAME sleep - delay for a specified amount of time
SYNOPSIS sleep NUMBER[SUFFIX]... sleep OPTION
DESCRIPTION Pause for NUMBER seconds. SUFFIX may be ‘s' for seconds (the default), ‘m' for minutes, ‘h' for hours or ‘d' for days. Unlike most implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.
Note in particular the last sentence.
...
-- Cheers, Carlos Robinson
Randall Schulz
The Tuesday 2005-02-22 at 07:01 -0800, Randall R Schulz wrote:
Hi, Carlos,
It seems you have some time on your hands...
I had a free hour, and wanted to exercise my neurones :-)
When the connection goes up, /etc/ppp/poll.tcpip does this:
while true ; do set -- $(/sbin/runlevel) test -e /etc/init.d/rc${2}.d/S*xntpd && break test -x /usr/sbin/ntpdate || break checkproc /usr/sbin/xntpd &> /dev/null && break /usr/sbin/rcxntpd ntptimeset break done
It seems to me there's nothing to keep this loop from saturating the CPU if none of the conditions that allow it to terminate are met. Perhaps a "sleep" following the invocation of rcxntpd?
Well, for one, it is written by SuSE, so I shouldn't worry too much ;-) For another, I have it dissabled completely, I use my own ip-up.local instead.
Wouldn't the last line (break) break in any case?
I think it is not really a loop, only a "cute" way of chaining if/then/else sentences.
Let me see... the "set" line I don't understand, but the runlevel comand "prints the previous and current system runlevel on its standard output, separated by a single space. If there is no previous system runlevel, the letter N will be printed instead". Ah, it sets the first parameter to "N" and the second ${2} to "5" in my system.
Then the test line "breaks" out of the loop if there is a symlink in runlevel 5 (from the previous line) to xntpd, meaning that the xntpd daemon is defined to run - in that case, we must not attempt to set the time here.
The next line check to see if exists '/usr/sbin/xntpd' and is executable, and breaks otherwise.
The checkproc line checks if /usr/sbin/xntpd is running, and breaks if it is.
The next line executes "rcxntpd ntptimeset", setting the time.
And the next, breaks out, in any case.
No, the loop executes only once, it is not a loop. Clever... I must save this example for myself ;-)
The poll.tcpip script is complex, it has "trap" sentences, for instance:
trap 'echo' SIGHUP SIGINT SIGQUIT trap 'rm -f /var/run/poll.lock; exit 1' SIGTRAP SIGBUS SIGKILL SIGPIPE SIGTERM trap 'rm -f /var/run/poll.lock; exit 0' EXIT
This brings up another thing I just learned recently:
...
Pause for NUMBER seconds. SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days. Unlike most implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.Note in particular the last sentence.
Yes, I use it fairly often. I didn't remember about the floating point, though. Funny, and interesting :-)
Carlos,
On Tuesday 22 February 2005 12:25, Carlos E. R. wrote:
The Tuesday 2005-02-22 at 07:01 -0800, Randall R Schulz wrote:
Hi, Carlos,
It seems you have some time on your hands...
I had a free hour, and wanted to exercise my neurones :-)
When the connection goes up, /etc/ppp/poll.tcpip does this:
while true ; do set -- $(/sbin/runlevel) test -e /etc/init.d/rc${2}.d/S*xntpd && break test -x /usr/sbin/ntpdate || break checkproc /usr/sbin/xntpd &> /dev/null && break /usr/sbin/rcxntpd ntptimeset break done
It seems to me there's nothing to keep this loop from saturating the CPU if none of the conditions that allow it to terminate are met. Perhaps a "sleep" following the invocation of rcxntpd?
Well, for one, it is written by SuSE, so I shouldn't worry too much ;-) For another, I have it dissabled completely, I use my own ip-up.local instead.
Wouldn't the last line (break) break in any case?
I think it is not really a loop, only a "cute" way of chaining if/then/else sentences.
Yes, you're right, of course. Too cute by half, I'd say, but I suppose that's just because it fooled me.
Let me see... the "set" line I don't understand, but the runlevel comand "prints the previous and current system runlevel on its standard output, separated by a single space. If there is no previous system runlevel, the letter N will be printed instead". Ah, it sets the first parameter to "N" and the second ${2} to "5" in my system.
Set does dual duty. It can change shell options and it can set the positional parameters. It's the latter use being made in this case. The previous and current run levels become $1 and $2, as you note.
...
This brings up another thing I just learned recently:
...
Pause for NUMBER seconds. SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days. Unlike most implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.Note in particular the last sentence.
Yes, I use it fairly often. I didn't remember about the floating point, though. Funny, and interesting :-)
I'm not laughing. But I've found it to be handy.
Carlos Robinson
Randall Schulz
The Tuesday 2005-02-22 at 15:41 -0800, Randall R Schulz wrote:
I think it is not really a loop, only a "cute" way of chaining if/then/else sentences.
Yes, you're right, of course. Too cute by half, I'd say, but I suppose that's just because it fooled me.
Mee to. I had to stop and look at it carefully, after you mentioned it.
Let me see... the "set" line I don't understand, but the runlevel comand "prints the previous and current system runlevel on its standard output, separated by a single space. If there is no previous system runlevel, the letter N will be printed instead". Ah, it sets the first parameter to "N" and the second ${2} to "5" in my system.
Set does dual duty. It can change shell options and it can set the positional parameters. It's the latter use being made in this case. The previous and current run levels become $1 and $2, as you note.
Yes, it is a nice trick to separate words, easier and better than the program "cut" for that purpose, imo. I think you can redefine the word separator with an environment parameter change: there is at least one of the suse init scripts that uses that trick, if my memory serves.
But the double dash still confuses me...
Pause for NUMBER seconds. SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days. Unlike most implementations that require NUMBER be an integer, here NUMBER may be an arbitrary floating point number.Note in particular the last sentence.
Yes, I use it fairly often. I didn't remember about the floating point, though. Funny, and interesting :-)
I'm not laughing. But I've found it to be handy.
I find funny those little differences beetween linux and "unixes". They are nice, but when we get back to another machine, it makes dificulties for us.
-
B. Stia -
Carlos E. R. -
Randall R Schulz