Re: Don't do that!
Le Mar 23 avril 2013 19:00, Kelly Clowers a écrit : On Tue, Apr 23, 2013 at 8:52 AM, Hans-J. Ullrich hans.ullr...@loop.de wrote: Today I learnt this: Do NOT use ext4 for the /boot partition, where your kernel resides. I did this on my EEEPC to speed up boot, and today I got at boot the error message: initrd.img corrupt. My EEEPC has got an ssd inside and /usr, /home and /var are encrypted partitions. It took me hours and hours to fix this. First I tried ext2fs, with no success. I could run Trinity Rescue Kit from a sd card, and I created a chroot, but not all was possible to do in the chroot. After lots of tries I got the solution: 1. I backuped all the content of /boot to another drive. 2. Booted with a livefile and formatted /boot to ext2. 3. Restored /boot 4. Edited /etc/fstab, removed the UUID of /boot and removed disacard,noatime 5. Now I could boot again. 6. From the running system started update-initramfs -u 7. Did dpkg-reconfigure linux-base, so I got the UUID in all necessary config files again. 8. For making all sure. did update-grub 9. Finally test, rebooted again, everything was ok. So NEVER, NEVER, NEVER use ext4 for /boot! Don't do it! (If I would have read the manual, I should have known, ext4 and grub is still in experimental state) My /boot is just part of root, and it is ext4. Never had any issue. If I did have a separate /boot partition, I would use ext2 or 3 or 4 with out the journal, since it would eat up a bit of space on a small partition. But that is it. Cheers, Kelly Clowers Agree, I did the same. Just, I've added the noatime on /boot, since there is really no use to write time at each access. To speed up things. Now, I'm using an ext2, since there is no interest into using other features on a partition I only write on when there is a kernel change. Want to have faster stuff? Take one with less features. Note that I use ext4 for all my partitions (except tmp and boot, of course, since an advanced FS for them is useless. I also often set some other flags, since some are only useful on /) since 2 years, and never had any problem. Well, I must also say to be complete that I have never used encrypted stuff until now. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b3b095dd7bb4aea71e6af79d8ab65d42.squir...@www.sud-ouest.org
Re: Don't do that!
On Wed, 2013-04-24 at 09:10 +0200, Morel Bérenger wrote: Just, I've added the noatime on /boot, since there is really no use to write time at each access. To speed up things. *lol* I've got reasons to use noatime for partitions, to speed up access, but it definitive won't speed up anything when accessing /boot ;), the win is far, far below a second. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366789365.699.87.camel@archlinux
Re: Don't do that!
Le Mer 24 avril 2013 9:42, Ralf Mardorf a écrit : On Wed, 2013-04-24 at 09:10 +0200, Morel Bérenger wrote: Just, I've added the noatime on /boot, since there is really no use to write time at each access. To speed up things. *lol* I've got reasons to use noatime for partitions, to speed up access, but it definitive won't speed up anything when accessing /boot ;), the win is far, far below a second. My apologies you are true :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/907548f0ce0cf7b6323063b61064ae99.squir...@www.sud-ouest.org
Don't do that!
Today I learnt this: Do NOT use ext4 for the /boot partition, where your kernel resides. I did this on my EEEPC to speed up boot, and today I got at boot the error message: initrd.img corrupt. My EEEPC has got an ssd inside and /usr, /home and /var are encrypted partitions. It took me hours and hours to fix this. First I tried ext2fs, with no success. I could run Trinity Rescue Kit from a sd card, and I created a chroot, but not all was possible to do in the chroot. After lots of tries I got the solution: 1. I backuped all the content of /boot to another drive. 2. Booted with a livefile and formatted /boot to ext2. 3. Restored /boot 4. Edited /etc/fstab, removed the UUID of /boot and removed disacard,noatime 5. Now I could boot again. 6. From the running system started update-initramfs -u 7. Did dpkg-reconfigure linux-base, so I got the UUID in all necessary config files again. 8. For making all sure. did update-grub 9. Finally test, rebooted again, everything was ok. So NEVER, NEVER, NEVER use ext4 for /boot! Don't do it! (If I would have read the manual, I should have known, ext4 and grub is still in experimental state) Best regards Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304231752.54550.hans.ullr...@loop.de
Re: Don't do that!
On Tue, Apr 23, 2013 at 8:52 AM, Hans-J. Ullrich hans.ullr...@loop.de wrote: Today I learnt this: Do NOT use ext4 for the /boot partition, where your kernel resides. I did this on my EEEPC to speed up boot, and today I got at boot the error message: initrd.img corrupt. My EEEPC has got an ssd inside and /usr, /home and /var are encrypted partitions. It took me hours and hours to fix this. First I tried ext2fs, with no success. I could run Trinity Rescue Kit from a sd card, and I created a chroot, but not all was possible to do in the chroot. After lots of tries I got the solution: 1. I backuped all the content of /boot to another drive. 2. Booted with a livefile and formatted /boot to ext2. 3. Restored /boot 4. Edited /etc/fstab, removed the UUID of /boot and removed disacard,noatime 5. Now I could boot again. 6. From the running system started update-initramfs -u 7. Did dpkg-reconfigure linux-base, so I got the UUID in all necessary config files again. 8. For making all sure. did update-grub 9. Finally test, rebooted again, everything was ok. So NEVER, NEVER, NEVER use ext4 for /boot! Don't do it! (If I would have read the manual, I should have known, ext4 and grub is still in experimental state) My /boot is just part of root, and it is ext4. Never had any issue. If I did have a separate /boot partition, I would use ext2 or 3 or 4 with out the journal, since it would eat up a bit of space on a small partition. But that is it. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFoWM=_jTMpU1Xi=b2iV=QLX3AoyTC-fGoVPSZUh=gogyq4...@mail.gmail.com
Re: Don't do that!
That is interesting. I have a similar setup on my workstation: /dev/sda2 ext4964532 59380856156 7% /boot With the rest of the filesystems in an encrypted LVM container. I built (rebuilt) this machine a couple of years ago, and have never had an issue...To include power failures where the machine did not power down gracefully. Could it have been a problem with your SSD, e.g. a bad spot, or could the initramfs have been corrupted on write? Do you have other kernels installed? (I usually keep, at a minimum, the current one and the last one.) --b On Tue, Apr 23, 2013 at 11:52 AM, Hans-J. Ullrich hans.ullr...@loop.dewrote: Today I learnt this: Do NOT use ext4 for the /boot partition, where your kernel resides. I did this on my EEEPC to speed up boot, and today I got at boot the error message: initrd.img corrupt. My EEEPC has got an ssd inside and /usr, /home and /var are encrypted partitions. It took me hours and hours to fix this. First I tried ext2fs, with no success. I could run Trinity Rescue Kit from a sd card, and I created a chroot, but not all was possible to do in the chroot. After lots of tries I got the solution: 1. I backuped all the content of /boot to another drive. 2. Booted with a livefile and formatted /boot to ext2. 3. Restored /boot 4. Edited /etc/fstab, removed the UUID of /boot and removed disacard,noatime 5. Now I could boot again. 6. From the running system started update-initramfs -u 7. Did dpkg-reconfigure linux-base, so I got the UUID in all necessary config files again. 8. For making all sure. did update-grub 9. Finally test, rebooted again, everything was ok. So NEVER, NEVER, NEVER use ext4 for /boot! Don't do it! (If I would have read the manual, I should have known, ext4 and grub is still in experimental state) Best regards Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304231752.54550.hans.ullr...@loop.de
Re: Don't do that!
Am Dienstag, 23. April 2013 schrieb Brad Alexander: That is interesting. I have a similar setup on my workstation: /dev/sda2 ext4964532 59380856156 7% /boot With the rest of the filesystems in an encrypted LVM container. I built (rebuilt) this machine a couple of years ago, and have never had an issue...To include power failures where the machine did not power down gracefully. Could it have been a problem with your SSD, e.g. a bad spot, or could the initramfs have been corrupted on write? initramfs was corrupted because of the filesystem. Do you have other kernels installed? (I usually keep, at a minimum, the current one and the last one.) Yeah, my fault. I had had two kernels, but some weeks ago I deleted one. However with ext4 everything went fine - until today Happy hacking Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304232038.55747.hans.ullr...@loop.de
Re: Don't do that!
That's really odd. I know that there used to be warnings about ext4 years ago, but I don't recall seeing them as far back as the squeeze release. On Tue, Apr 23, 2013 at 2:38 PM, Hans-J. Ullrich hans.ullr...@loop.dewrote: Am Dienstag, 23. April 2013 schrieb Brad Alexander: That is interesting. I have a similar setup on my workstation: /dev/sda2 ext4964532 59380856156 7% /boot With the rest of the filesystems in an encrypted LVM container. I built (rebuilt) this machine a couple of years ago, and have never had an issue...To include power failures where the machine did not power down gracefully. Could it have been a problem with your SSD, e.g. a bad spot, or could the initramfs have been corrupted on write? initramfs was corrupted because of the filesystem. Do you have other kernels installed? (I usually keep, at a minimum, the current one and the last one.) Yeah, my fault. I had had two kernels, but some weeks ago I deleted one. However with ext4 everything went fine - until today Happy hacking Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304232038.55747.hans.ullr...@loop.de
Re: ntpdate from cron -- DON'T DO THAT!
On Sun, Dec 29, 2002 at 02:18:18AM -0800, alan brown wrote: I may be wrong but I think it's more generic than burning CD's. I've heard it's related to SCSI drives. Just hearsay. Throw it into the mix... On the victim machine I'm using IDE drives with SCSI emulation for the CD writer, no actual SCSI hardware, and cdrecord to do the writing. In the course of writing two CDs with about 300 MB the clock slowed by 97 seconds, as subsequently reset by ntpdate. FWIW. Ken -Original Message- From: Ken Irving On Sat, Dec 21, 2002 at 04:14:32PM -0800, Bill Moseley wrote: ... The other possibility, brought up by someone on this list, is that that machine is used for burning CDs and that may cause the clock to get slow. I have not check this, though. I'll second that warning, as I saw just that behavior on a time-critical system. Yes, it's dumb to be running such processes on a workstation, and I'm currently fixing that, but I'm satisfied that burning CDs can drastically slow the clock. The last time it happened I easily made the connection between the CD burn operation and ntpdate's actions, but the first time I had no idea, panicked, and replaced ntpd with ntpdate. After reading this thread I'll go back to ntpd. -- Ken Irving [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ken Irving [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 04:14:32PM -0800, Bill Moseley wrote: ... The other possibility, brought up by someone on this list, is that that machine is used for burning CDs and that may cause the clock to get slow. I have not check this, though. I'll second that warning, as I saw just that behavior on a time-critical system. Yes, it's dumb to be running such processes on a workstation, and I'm currently fixing that, but I'm satisfied that burning CDs can drastically slow the clock. The last time it happened I easily made the connection between the CD burn operation and ntpdate's actions, but the first time I had no idea, panicked, and replaced ntpd with ntpdate. After reading this thread I'll go back to ntpd. -- Ken Irving [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Michael == Michael D Schleif [EMAIL PROTECTED] writes: Michael imho, all isp's ought to be required to *have* time servers . . . No, anyone who sells disk space should have a time server. I don't care whether my time is exactly in sync with the ISP who provides my internet connection, but I want to have the same time as the webserver provider who serve my webpage, because rsync uses that time. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
John Hasler [EMAIL PROTECTED] [2002-12-23 08:03:45 -0600]: I think you'd stump the frontline staff at any isp with this one, and it's not really important enough to email thier NOC about in the end... Of course I'd stump the frontline staff of my ISP with questions about time servers, and it is impossible for me communicate with anyone else there. AFAIK this is the usual situation. Agreed. However, if you prompt them you can usually get them to agree with anything. Me: Is it okay if I use your DNS servers as my primary NTP servers too? ISP: Uh, NTP? Uh, you are a customer of ours? Then sure. BTW, what is NTP? Generally distribution infrastructure of NTP is similar to DNS and therefore I recommend using the same DNS machines for NTP machines. Bob msg21307/pgp0.pgp Description: PGP signature
Re: ntpdate from cron -- DON'T DO THAT!
On Mon, Dec 23, 2002 at 04:08:34PM +0100, Chris Niekel wrote: But indeed, time is of no critical importance to me, so maybe I should just remove a few of the servers. If you already have them listed, there's no real reason to remove them, as it'll maintain reliability if the timeservers go out. Of course, this won't help if your DSL line goes out, which from my experiance is more often than it's on (I've been with Verizon, Qwest.net, and DSL-Only on Verizon and Qwest, and all of them suck hardcore. Friends don't let friends use DSL.) -- .''`. Baloo [EMAIL PROTECTED] : :' :proud Debian admin and user `. `'` `- Debian - when you have better things to do than to fix a system msg20900/pgp0.pgp Description: PGP signature
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 07:01:41PM -0600, John Hasler wrote: And that higher stratum server should be that of your ISP, if possible. IMHO all ISPs should make time servers available to their customers. The NTP-docs mention that you should not use only one server, but more. I've added a few others as well. Should ISPs offer multiple servers[1], should I just use the one my ISP provides, or should I use the servers from all the ISPs in the country? [1] My provider, xs4all.nl pretends to have ntp.xs4all.nl, and ntp2.xs4all.nl. Unfortunately, these names point to the same server. Greetings, Chris Niekel -- I've been down so long, if I'd cheer up, I'd still be depressed. - Lisa Simpson, Moanin' Lisa Blues. msg20685/pgp0.pgp Description: PGP signature
Re: ntpdate from cron -- DON'T DO THAT!
Paul Johnson writes: [A UBR is] part of a cable network. Then my ISP doesn't have one. I think you'd stump the frontline staff at any isp with this one, and it's not really important enough to email thier NOC about in the end... Of course I'd stump the frontline staff of my ISP with questions about time servers, and it is impossible for me communicate with anyone else there. AFAIK this is the usual situation. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Chris Niekel writes: The NTP-docs mention that you should not use only one server, but more. Is reliable time service of critical importance to you? Most systems can go for days without contacting a timeserver and suffer no harm. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Mon, Dec 23, 2002 at 08:09:41AM -0600, John Hasler wrote: Chris Niekel writes: The NTP-docs mention that you should not use only one server, but more. Is reliable time service of critical importance to you? Most systems can go for days without contacting a timeserver and suffer no harm. Indeed. But the point was that a server gone bad could make your time way off. With multiple servers, if one server gives the wrong time, this is detected, and the server is unused for a while. For the reliability of _access_ to the server, it won't help much, because all servers are on the other end of this meager adsl-line. But indeed, time is of no critical importance to me, so maybe I should just remove a few of the servers. Greetings, Chris Niekel -- I've been down so long, if I'd cheer up, I'd still be depressed. - Lisa Simpson, Moanin' Lisa Blues. msg20708/pgp0.pgp Description: PGP signature
Re: ntpdate from cron -- DON'T DO THAT! - more
Bob writes: How does rdate compare to chrony and nptd? Rdate uses the RFC868 protocol while Chrony and Ntp use the RFC1305 (NTP) protocol. Look here http://www.boulder.nist.gov/timefreq/service/its.htm for a comparison. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On 22 Dec 2002 08:05:55 -0600 John Hasler [EMAIL PROTECTED] wrote: What's a UBR? I'm pretty sure it does with the NTL cable system I'm on. My ISP certainly doesn't, and I doubt that I could contact with anyone there who knows what a time server is. The local router that acts as your gateway. -- Richard Kimber http://www.psr.keele.ac.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
I wrote: What's a UBR? Richard Kimber writes: The local router that acts as your gateway. No ntp service available there. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sun, Dec 22, 2002 at 08:05:55AM -0600, John Hasler wrote: The local UBR should do that shouldn't it? What's a UBR? Back when I was working for @Home, I knew this. It's part of a cable network. My ISP certainly doesn't, and I doubt that I could contact with anyone there who knows what a time server is. I think you'd stump the frontline staff at any isp with this one, and it's not really important enough to email thier NOC about in the end... -- .''`. Baloo [EMAIL PROTECTED] : :' :proud Debian admin and user `. `'` `- Debian - when you have better things to do than to fix a system msg20650/pgp0.pgp Description: PGP signature
Re: ntpdate from cron -- DON'T DO THAT!
On Sun, Dec 22, 2002 at 03:17:50AM +0100, Vincent Lefevre wrote: Shouldn't happen. Have you filed a bug report? I'm not the administrator of the machines at my lab, so I couldn't report any useful information. Try typing bug at a shell prompt. If it works, you should be able to at least get the bug known. Others experiancing similar problems could add to it, later. -- .''`. Baloo [EMAIL PROTECTED] : :' :proud Debian admin and user `. `'` `- Debian - when you have better things to do than to fix a system msg20501/pgp0.pgp Description: PGP signature
Re: ntpdate from cron -- DON'T DO THAT!
On Sun, 2002-12-22 at 01:47, John Hasler wrote: Antoine writes: I was one of the people using ntpdate in a cron job, although it was not because I was lazy, all my servers have ntpd, I only used ntpdate on clients. Then your clients should have been connecting to the ntp daemons on your servers, so there should have been no impact on the public servers. Hum... how do you know there were connecting on the ntp daemons on the public servers... I never said that... and you know what, there were NOT ! All my clients did ntpdate to local servers, and the servers (which were using ntpd) are connecting to public servers. So I don't think there was any impact on the public servers... Voila -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On 21 Dec 2002 19:01:41 -0600 John Hasler [EMAIL PROTECTED] wrote: And that higher stratum server should be that of your ISP, if possible. IMHO all ISPs should make time servers available to their customers. The local UBR should do that shouldn't it? I'm pretty sure it does with the NTL cable system I'm on. -- Richard Kimber http://www.psr.keele.ac.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
I wrote: Then your clients should have been connecting to the ntp daemons on your servers, so there should have been no impact on the public servers. Antoine Jacoutot writes: All my clients did ntpdate to local servers, and the servers (which were using ntpd) are connecting to public servers. I read your original message as implying that you were not using ntpd at all anywhere. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
I wrote: And that higher stratum server should be that of your ISP, if possible. IMHO all ISPs should make time servers available to their customers. Richard Kimber writes: The local UBR should do that shouldn't it? What's a UBR? I'm pretty sure it does with the NTL cable system I'm on. My ISP certainly doesn't, and I doubt that I could contact with anyone there who knows what a time server is. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT! - more
How does rdate compare to chrony and nptd? Regards, Bob -- _ |_) _ |_Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) 1294 S.W. Seagull Way [EMAIL PROTECTED] Palm City, FL 34990 USA GPG Key ID: 390D6559 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ntpdate from cron -- DON'T DO THAT!
* Sonny Kupka [EMAIL PROTECTED] [2002-12-21 10:46:12 -0600]: I have ntpdate installed on woody.. and it's not automagically keeping my system in sync.. Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job. ntpdate works like date(1), but it sets your clock's time to that of an ntp server (or servers) instead of having it specified by you. If you want to keep your clock in sync use ntpd -- that's what it was designed for. It uses many sophisticated algorithms and statistical methods to accomplish this. After some time, it can even figure out how bad your system clock is (i.e. its drift) and compensate for it, even if your network connection goes out. Unfortunately, some people, instead of taking the time to read the ntp documentation and writing a proper ntp.conf file, took the easy route and started running ntpdate from cron. This caused two problems, firstly it did not keep very good time: immediately after you called ntpdate, your clock would begin to drift again. And more importantly, every hour or so, the ntp servers were being affected by a thunderclap effect, the result of everybody putting: 0 * * * * /usr/local/bin/ntpdate or something similar into their crontab files. The ntp daemon does not do this as it randomizes the time it waits between queries. For this reason, Dr. Mills (ntp author) has deprecated ntpdate, and indeed, he will be removing it completely from a future release. hth, thomas -- N. Thomas [EMAIL PROTECTED] Etiamsi occiderit me, in ipso sperabo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
N. Thomas said: * Sonny Kupka [EMAIL PROTECTED] [2002-12-21 10:46:12 -0600]: I have ntpdate installed on woody.. and it's not automagically keeping my system in sync.. Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job. it can, and does I've been using it for ages. I do not like to run ntpd on everything[1]. The less daemons listening on ports the better for me. ntpd is more accurate then ntpdate, but doing a ntpdate timeserver; hwclock --systohc works fine for me. I could configure individual firewall rules on all my machines to block ntp traffic, but it's easier to use ntpdate (I call it from cron on 1 system which SSH's to the others and runs it). And the accuracy is acceptable for me. I have it run hourly and it syncs against a local ntp on my LAN. If ntpd can be configured not to listen for connections on any port then maybe I would use it, I haven't looked into it a whole lot since ntpdate works good enough for me, but I don't recall seeing such an option. nate [1] http://www.kb.cert.org/vuls/id/970472 yes I know it's patched now, but another issue could come up in the future, and ntpd is not vital enough for me to run everywhere. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sun, 2002-12-22 at 00:51, N. Thomas wrote: * Sonny Kupka [EMAIL PROTECTED] [2002-12-21 10:46:12 -0600]: I have ntpdate installed on woody.. and it's not automagically keeping my system in sync.. Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job. ntpdate works like date(1), but it sets your clock's time to that of an ntp server (or servers) instead of having it specified by you. If you want to keep your clock in sync use ntpd -- that's what it was designed for. It uses many sophisticated algorithms and statistical methods to accomplish this. After some time, it can even figure out how bad your system clock is (i.e. its drift) and compensate for it, even if your network connection goes out. Unfortunately, some people, instead of taking the time to read the ntp documentation and writing a proper ntp.conf file, took the easy route and started running ntpdate from cron. This caused two problems, firstly it did not keep very good time: immediately after you called ntpdate, your clock would begin to drift again. And more importantly, every hour or so, the ntp servers were being affected by a thunderclap effect, the result of everybody putting: 0 * * * * /usr/local/bin/ntpdate or something similar into their crontab files. The ntp daemon does not do this as it randomizes the time it waits between queries. For this reason, Dr. Mills (ntp author) has deprecated ntpdate, and indeed, he will be removing it completely from a future release. hth, thomas Thank you very much for this information. I was one of the people using ntpdate in a cron job, although it was not because I was lazy, all my servers have ntpd, I only used ntpdate on clients. From now, I'll only run ntpd on all my clients (and once again, I took the time reading the ntpd documentation) and not ntpdate anymore. Thanks. Antoine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
At 06:51 PM 12/21/02 -0500, N. Thomas wrote: * Sonny Kupka [EMAIL PROTECTED] [2002-12-21 10:46:12 -0600]: I have ntpdate installed on woody.. and it's not automagically keeping my system in sync.. Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job. Ok, I don't want to run ntpdate from cron, but ntpd isn't working for me -- well, at least on one machine installed on a pppoe connection (my other machines on static IPs with the same ntpd config seem to work fine). What happens is I ssh into the machine on the pppoe connection and it's an hour or so slow. I'm not sure of the cause. The logs are saying that it can't reach the hosts I've listed (which are the same as in other machines). So maybe ntpd is giving up and never trying again. If that's the case is there a way to tell it to continue to try? The other possibility, brought up by someone on this list, is that that machine is used for burning CDs and that may cause the clock to get slow. I have not check this, though. Anyway, here's all the logs I have: $ fgrep ntp daemon.log.0 daemon.log | tail -10 daemon.log:Dec 16 02:20:12 burn ntpd[299]: ntpd 4.1.0 Mon Mar 25 23:39:47 UTC 2002 (2) daemon.log:Dec 16 02:20:12 burn ntpd[299]: signal_no_reset: signal 13 had flags 400 daemon.log:Dec 16 02:20:12 burn ntpd[299]: precision = 12 usec daemon.log:Dec 16 02:20:12 burn ntpd[299]: kernel time discipline status 0040 daemon.log:Dec 16 02:20:12 burn ntpd[299]: frequency initialized 13.154 from /var/lib/ntp/ntp.drift daemon.log:Dec 16 02:20:12 burn ntpd[307]: signal_no_reset: signal 17 had flags 400 daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `ntp1.cmc.ec.gc.ca', giving up on it daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `clock.netcetera.dk', giving up on it daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `ntp1.mainecoon.com', giving up on it daemon.log:Dec 21 14:30:29 burn ntpdate[6612]: step time server 63.192.96.2 offset 3203.797781 sec -- Bill Moseley mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT! - more
On Sat, 21 Dec 2002, Bill Moseley wrote: At 06:51 PM 12/21/02 -0500, N. Thomas wrote: ... Anyway, here's all the logs I have: $ fgrep ntp daemon.log.0 daemon.log | tail -10 daemon.log:Dec 16 02:20:12 burn ntpd[299]: ntpd 4.1.0 Mon Mar 25 23:39:47 UTC 2002 (2) daemon.log:Dec 16 02:20:12 burn ntpd[299]: signal_no_reset: signal 13 had flags 400 daemon.log:Dec 16 02:20:12 burn ntpd[299]: precision = 12 usec daemon.log:Dec 16 02:20:12 burn ntpd[299]: kernel time discipline status 0040 daemon.log:Dec 16 02:20:12 burn ntpd[299]: frequency initialized 13.154 from /var/lib/ntp/ntp.drift daemon.log:Dec 16 02:20:12 burn ntpd[307]: signal_no_reset: signal 17 had flags 400 daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `ntp1.cmc.ec.gc.ca', giving up on it daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `clock.netcetera.dk', giving up on it daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `ntp1.mainecoon.com', giving up on it daemon.log:Dec 21 14:30:29 burn ntpdate[6612]: step time server 63.192.96.2 offset 3203.797781 sec sounds like you need to fix your dns ?? ( at least it found one ) ( and/or hardcode it ( the ntpservers in /etc/hosts ) for quickie tests ) iirc, ntpd will not sync if you're more than 1000 seconds off... ntpdate will resync... but you will need to resync your hwclock to the sw clock more ntp docs, testing commands, client's ntp.conf, server's ntp.conf http://www.linux-consulting.com/NTP have fun alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
* nate [EMAIL PROTECTED] [2002-12-21 16:15:35 -0800]: N. Thomas said: Contrary to what you may have heard, ntpdate does not keep your system clock synced. it can, and does I've been using it for ages. I do not like to run ntpd on everything[1]. The less daemons listening on ports the better for me. ntpd is more accurate then ntpdate, but doing a ntpdate timeserver; hwclock --systohc works fine for me. In this case, ntpdate is not doing the syncing, you are doing it manually with your cron job and hwclock call. Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? I haven't looked into it a whole lot since ntpdate works good enough for me, but I don't recall seeing such an option. Yes it works for you, but think about the admin running the time servers that your box connects to. Would this solution be acceptable to them? Can you imagine 100 if people did the same thing? Unless you are paying whoever runs the time server, or you both are part of the same organization, then they are providing you with a public service, and the least you can do is be kind and help reduce the load on their servers. thomas -- N. Thomas [EMAIL PROTECTED] Etiamsi occiderit me, in ipso sperabo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT! - more
At 04:27 PM 12/21/02 -0800, Alvin Oga wrote: daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `ntp1.mainecoon.com', giving up on it daemon.log:Dec 21 14:30:29 burn ntpdate[6612]: step time server 63.192.96.2 offset 3203.797781 sec sounds like you need to fix your dns ?? ( at least it found one ) ( and/or hardcode it ( the ntpservers in /etc/hosts ) for quickie tests ) I think that's not due to wrong server, rather to just plain loss of connection. Still, once it gives up I wonder if it every tries again. Doesn't seem so from the logs. Network connections do go down once in a while. That machine is running DNSmasq which is setup to read /etc/ppp/resolve.conf and detect any changes (I don't think the DNS machines changes, though). The machine emails me with its IP and DNS config every time ppp comes up, which is how I know where to find the machine when its IP changes. iirc, ntpd will not sync if you're more than 1000 seconds off... ntpdate will resync... but you will need to resync your hwclock to the sw clock It would be nice if it logged that event. Still, it's hard to imagine that it would be off line long enough to get that far behind. I wonder if running hwclock --systohc from cron would fix the problem. It may be that the machine is being restarted without a proper shutdown (and hwclock save), so that on restart it's reading a very slow hwclock. Thanks for the help, -- Bill Moseley mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Nate writes: If ntpd can be configured not to listen for connections on any port then maybe I would use it... Well, chrony certainly can: the default is to allow no access. You can configure it to allow or deny access from just about any combination of hosts, IPs, and subnets. It is simple to set up a chrony server that is a client of a stratum 2 server out on the Net and a server for the machines on your LAN. The machines on the LAN can run client-only chronyds, ntpdate, or whatever. And chrony has never had a security issue. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Antoine writes: I was one of the people using ntpdate in a cron job, although it was not because I was lazy, all my servers have ntpd, I only used ntpdate on clients. Then your clients should have been connecting to the ntp daemons on your servers, so there should have been no impact on the public servers. From now, I'll only run ntpd on all my clients (and once again, I took the time reading the ntpd documentation) and not ntpdate anymore. Hopefully you will still have them connnect to your servers and not to the public ntp servers. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
N. Thomas said: Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? this is infact, what I do[1] :) sorry if I wasn't clear. I run ntpd on 1 machine(sometimes 1 machine per network). This syncs to some external source, and ntpdate runs on all the other machines which sync to this one local system. But I really only run ntpd on this machine so I can sync other machines to it. Yes it works for you, but think about the admin running the time servers that your box connects to. Would this solution be acceptable to them? Can you imagine 100 if people did the same thing? As above, only 1 system sync's to an external server, and it is a .gov server, time.nist.gov or something. Since it's a government server, run possibly by at least a couple fractions of a cent from my tax dollars I think I have a right to sync against it, they can always block me if they want though. I used to sync against other servers, theres a list of them somewhere, but the list seemed to change a lot and even with multiple servers in the list sometimes after 4-6 months all of those servers were down/not responding anymore. I think the .gov one won't go away. nate [1] http://bb.aphroland.org/bb/html/redhat.aphroland.org.ntpd.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
John Hasler said: Nate writes: If ntpd can be configured not to listen for connections on any port then maybe I would use it... Well, chrony certainly can: the default is to allow no access. You can configure it to allow or deny access from just about any combination of hosts, IPs, and subnets. It is simple to set up a chrony server that is a client of a stratum 2 server out on the Net and a server for the machines on your LAN. The machines on the LAN can run client-only chronyds, ntpdate, or whatever. interesting, I had not heard of chrony before, thanks! nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
N. Thomas writes: Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? And that higher stratum server should be that of your ISP, if possible. IMHO all ISPs should make time servers available to their customers. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 07:01:41PM -0600, John Hasler wrote: N. Thomas writes: Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? And that higher stratum server should be that of your ISP, if possible. IMHO all ISPs should make time servers available to their customers. AOL/ A good indicator of clue at your ISP is the answer you get when you ask them the address of their public timeserver. -- Nathan Norman - Incanus Networking mailto:[EMAIL PROTECTED] People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
John Hasler wrote: N. Thomas writes: Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? And that higher stratum server should be that of your ISP, if possible. IMHO all ISPs should make time servers available to their customers. imho, all isp's ought to be required to *have* time servers . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 07:28:20PM -0500, N. Thomas wrote: Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? Won't that still be bad for the machines on the internal network? Their clocks will regularly be reset. -- Lance Simmons [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT! - more
hi ya On Sat, 21 Dec 2002, Bill Moseley wrote: At 04:27 PM 12/21/02 -0800, Alvin Oga wrote: daemon.log:Dec 16 02:20:14 burn ntpd_initres[307]: couldn't resolve `ntp1.mainecoon.com', giving up on it daemon.log:Dec 21 14:30:29 burn ntpdate[6612]: step time server 63.192.96.2 offset 3203.797781 sec sounds like you need to fix your dns ?? ( at least it found one ) ( and/or hardcode it ( the ntpservers in /etc/hosts ) for quickie tests ) I think that's not due to wrong server, rather to just plain loss of connection. Still, once it gives up I wonder if it every tries again. Doesn't seem so from the logs. Network connections do go down once in a while. sometimes dns takes a while... putting it in /etc/hosts saves some time ... but only for testing ... ( unless /etc/hosts is copied to all machines to avoid some machines works and others die ) .. iirc, ntpd will not sync if you're more than 1000 seconds off... ntpdate will resync... but you will need to resync your hwclock to the sw clock It would be nice if it logged that event. Still, it's hard to imagine that it would be off line long enough to get that far behind. ntpdate only changes the sw clock .. not the bios clock ... - you need to update the biosclock ( hwclock ) wehn you shutdown properly... otherwise... the whole 3000sec off resyncing time starts again - i simply go to the bios and fix it... lot easier than reading lots of man pages and which commands to use .. than xntpd can do its magic c ya alvin I wonder if running hwclock --systohc from cron would fix the problem. It may be that the machine is being restarted without a proper shutdown (and hwclock save), so that on restart it's reading a very slow hwclock. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Nate writes: As above, only 1 system sync's to an external server, and it is a .gov server, time.nist.gov or something. I was about to write that you should not use a stratum 1 server, but this page http://www.boulder.nist.gov/timefreq/service/its.htm implies that NIST doesn't mind at all. I had planned to come up with a scheme for chrony to distribute the load over the available stratum 2 servers, and maybe even probe for one at your ISP and detect failure and pick a new server. Looks like I can just point them all at NIST. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 18:51:24 -0500, N. Thomas wrote: If you want to keep your clock in sync use ntpd -- that's what it was designed for. This is what is used on the machines at my lab, but the daemon sometimes dies. So, I wouldn't say that this is a good solution, unless there is a way to restart ntpd automatically (by cron?) when it dies. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
* Lance Simmons [EMAIL PROTECTED] [2002-12-21 19:16:56 -0600]: On Sat, Dec 21, 2002 at 07:28:20PM -0500, N. Thomas wrote: Why don't you just run ntpd on the one machine that talks to the higher stratum servers and use ntpdate for your internal network? Won't that still be bad for the machines on the internal network? Their clocks will regularly be reset. Correct, but in this case, it is a decision made by the admin that affects only the machines on his network and no one else. (For the most part.) Personally, I don't like how he has ntp setup either, but to be fair to Nate, he did mention that he had some port issues with ntp which caused him to go this way. thomas -- N. Thomas [EMAIL PROTECTED] Etiamsi occiderit me, in ipso sperabo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Lance Simmons writes: Won't that still be bad for the machines on the internal network? Their clocks will regularly be reset. If he runs it frequently and the clocks in the clients aren't too bad the changes will be less than a second and therefor unlikely to damage anything. He'd be better off running chrony or ntp, though. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Vincent writes: This is what is used on the machines at my lab, but the daemon sometimes dies. Shouldn't happen. Have you filed a bug report? So, I wouldn't say that this is a good solution, unless there is a way to restart ntpd automatically (by cron?) when it dies. man inittab Or try chrony :) -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This is incorrect advice (Re: ntpdate from cron -- DON'T DO THAT!)
On Sat, 2002-12-21 at 17:51, N. Thomas wrote: Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job. ntpdate works like date(1), but it sets your clock's time to that of an ntp server (or servers) instead of having it specified by you. I think you haven't looked at ntpdate in a while. From the ntpdate(1) man page: Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday(2) routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime(2) routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron(8) every hour or two. In fact, you can *force* ntpdate to slew the clock rate to achieve accuracy rather than stepping it; see the '-B' option. Having said that, I'd still recommend ntpd of ntpdate for syncing system clocks, particularly on important machines. Still, ntpdate isn't nearly as naive as you make it out to be. -- Kirk Strauser [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 19:50:39 -0600, John Hasler wrote: Vincent writes: This is what is used on the machines at my lab, but the daemon sometimes dies. Shouldn't happen. Have you filed a bug report? I'm not the administrator of the machines at my lab, so I couldn't report any useful information. Moreover, ntpd doesn't seem to set the hardware clock, as when the machine is rebooted while the NTP servers are down, it is one hour late (or something like that). Or perhaps the version was too old (my machine at my lab was reinstalled a few days ago). So, I wouldn't say that this is a good solution, unless there is a way to restart ntpd automatically (by cron?) when it dies. man inittab OK. Or try chrony :) Does it set the hardware clock? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
Vincent writes: Does [chrony] set the hardware clock? It can, using the 'trimrtc' directive (this is not properly documented: a bug). -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: This is incorrect advice (Re: ntpdate from cron -- DON'T DO THAT!)
* Kirk Strauser [EMAIL PROTECTED] [2002-12-21 19:56:20 -0600]: Contrary to what you may have heard, ntpdate does not keep your system clock synced. In fact, you can *force* ntpdate to slew the clock rate to achieve accuracy rather than stepping it; see the '-B' option. Yes, but this only happens once. Regardless of whether ntpdate slews or steps the clock, it does not synchronize it. You can only sync with ntpdate by running it regularly, i.e. putting it in cron. Of course, running ntpdate -B in cron is recommended over just plain ntpdate, but as in my original posting, and as you mentioned in the second half of your email, ntp is superior to both. thomas -- N. Thomas [EMAIL PROTECTED] Etiamsi occiderit me, in ipso sperabo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: This is incorrect advice (Re: ntpdate from cron -- DON'T DO THAT!)
N. Thomas wrote: * Kirk Strauser [EMAIL PROTECTED] [2002-12-21 19:56:20 -0600]: Contrary to what you may have heard, ntpdate does not keep your system clock synced. In fact, you can *force* ntpdate to slew the clock rate to achieve accuracy rather than stepping it; see the '-B' option. Yes, but this only happens once. Regardless of whether ntpdate slews or steps the clock, it does not synchronize it. You can only sync with ntpdate by running it regularly, i.e. putting it in cron. Of course, running ntpdate -B in cron is recommended over just plain ntpdate, but as in my original posting, and as you mentioned in the second half of your email, ntp is superior to both. imho, this is the _best_ ntpdate: http://doolittle.faludi.com/ntpclient/ unfortunately, ntpd is grossly oversize for embedded applications, for which this tiny ntpdate is designed. granted, wherever feasible, ntpd is technically the best . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: This is incorrect advice (Re: ntpdate from cron -- DON'T DO THAT!)
Michael D. Schleif writes: granted, wherever feasible, ntpd is technically the best . . . Do you know of some benchmarks comparing ntp and chrony? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: This is incorrect advice (Re: ntpdate from cron -- DON'T DO THAT!)
On Sat, Dec 21, 2002 at 10:12:56PM -0600, John Hasler wrote: Michael D. Schleif writes: granted, wherever feasible, ntpd is technically the best . . . Do you know of some benchmarks comparing ntp and chrony? I thought chronyd did not implement all of the time protocol RFC and had fewer device interfaces for time sources. So, maybe in that sense ntpd is technically the best? -- ...the plural of anecdote is [not?] data. - attrib. to George Stigler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate from cron -- DON'T DO THAT!
On Sat, Dec 21, 2002 at 04:15:35PM -0800, nate wrote: it can, and does I've been using it for ages. I do not like to run ntpd on everything[1]. The less daemons listening on ports the better for me. ntpd is more accurate then ntpdate, but doing a ntpdate timeserver; hwclock --systohc works fine for me. So run ntp-simple or use iptables to block the port. Use the tools you have, don't run away. [1] http://www.kb.cert.org/vuls/id/970472 yes I know it's patched now, but another issue could come up in the future, and ntpd is not vital enough for me to run everywhere. The only thing to fear is fear itself. Any software could develop security holes, this isn't a good excuse to thunderclap the server. -- .''`. Baloo [EMAIL PROTECTED] : :' :proud Debian admin and user `. `'` `- Debian - when you have better things to do than to fix a system msg20498/pgp0.pgp Description: PGP signature
