Re: Received mail timestamp is off by 7 hours
On Wed, Mar 02, 2005 at 03:11:19AM -0800, Ted Mittelstaedt wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Loren M. Lang Sent: Wednesday, March 02, 2005 2:29 AM To: Ian Smith Cc: Loren M. Lang; Pat Maddox; freebsd-questions@freebsd.org Subject: Re: Received mail timestamp is off by 7 hours little bit less reliable using local to UTC unless you are not affected by any daylight savings changes like Arizona in the US or, I'm sure, many other places around the world. There's no excuse for a mailserver to not be synced to a NTP source. I agree, I run ntp on every single computer I own, but I was talking in general. But for a server, I'd expect them to use UTC anyways. The only advantage I see to local time is support for other oses or reading the time in the bios, neither of which will probably be a big deal on a server. And for desktop users, they may not bother running ntp or even be on a network. Ted -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
On Wed, Mar 02, 2005 at 01:00:15PM -0800, Luke wrote: There's no excuse for a mailserver to not be synced to a NTP source. I'd extend that to apply to any server. Practically all the things a server does are dependent in some way on the correct time. I have three excuses: 1) NTP is difficult to configure. I've done it, but it wasn't trivial. ntpdate once at boot. 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. http://www.nist.gov/ 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. Same as 1) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 pgp3yOu0GrZHj.pgp Description: PGP signature
RE: Received mail timestamp is off by 7 hours
All Windows 2000, and above operating systems support NTP Logged in as administrator, at the command line net time /setsntp:XX.XX.XX.XX XX.XX.XX.XX = the IP address of a NTP server Then go in to Start Settings Control Panel Administrative Tools, Services, Windows Time and set startup to automatic. Microsoft also released and NTP service for NT4 in the MS resource kit. Even Windows supports NTP. As I said, no excuse. Ted -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anthony Atkielski Sent: Wednesday, March 02, 2005 10:32 AM To: freebsd-questions@freebsd.org Subject: Re: Received mail timestamp is off by 7 hours Ted Mittelstaedt writes: There's no excuse for a mailserver to not be synced to a NTP source. I'd extend that to apply to any server. Practically all the things a server does are dependent in some way on the correct time. This is also increasingly true of desktops. Gone are the days when you could just set the clock forward or back temporarily for some specific purpose. Today if you do that on a lot of desktops, you'll mess things up terribly (imagine having every birthday for the next five years trigger simultaneously when you open Outlook, or having half your file system marked for immediate deletion--not a pretty picture). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Received mail timestamp is off by 7 hours
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Loren M. Lang Sent: Thursday, March 03, 2005 12:58 PM To: Luke Cc: freebsd-questions@freebsd.org Subject: Re: Received mail timestamp is off by 7 hours On Wed, Mar 02, 2005 at 01:00:15PM -0800, Luke wrote: There's no excuse for a mailserver to not be synced to a NTP source. I'd extend that to apply to any server. Practically all the things a server does are dependent in some way on the correct time. I have three excuses: 1) NTP is difficult to configure. I've done it, but it wasn't trivial. ntpdate once at boot. To configure NTP add the following into /etc/rc.conf xntpd_enable=YES ntpdate_enable=YES ntpdate_flags=XX.XX.XX.XX NOTE: the ntpdate stuff is MANDATORY what that does is on boot, BEFORE ntpd is started, ntpdate forces the system clock to the exact time. Then ntpd starts up and merely MAINTAINS the correct time, it doesen't have to start stepping it forward or backward. create the file /etc/ntp.conf containing the single line: server XX.XX.XX.XX prefer XX.XX.XX.XX = IP address of time server. 2) Finding an NTP server willing to accept traffic from the public isn't easy either. Every ISP worth it's salt runs NTP on ALL of their routers. It is a requirement for tracking breakin attempts, unexpected router reboots, etc. Many of them configure their routers to allow syncing from customers. Point your NTP client to your ISP's default gateway and most likely it will work. If not, e-mail the support desk of the ISP. They will supply you with an IP number of a time server they run, or the time server their upstream feed provides to them. Most major backbones run NTP servers for the use of their customers. If your ISP is too retarded to help you, e-mail their upstream feed. I can tell you if I ever got a mail from a customer of one of our customers, complaining that our customer wasn't providing time services, I would tell that ISP that they had 1 minute to turn on NTP on their router or they were going to be disconnected from the Internet. 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. From the manpage of ntpd: ...However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway. Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities ... As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used... So, even if you don't use ntpdate correctly, it still covers you ass. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
On Tue, Mar 01, 2005 at 02:22:40AM +1100, Ian Smith wrote: On Mon, 28 Feb 2005 03:36:41 -0800 Loren M. Lang wrote: On Mon, Feb 28, 2005 at 12:58:17AM +1100, Ian Smith wrote: On Sun, 27 Feb 2005 03:10:12 -0700 Pat Maddox [EMAIL PROTECTED] wrote: Alright, I got it all working now. Not sure how to change the time zone with config files, so I just used sysinstall to change it to MST (time zone is arbitrary, but since this is the zone I live in, it's convenient for me). Then I used ntpdate to sync it, and it's working well now. Thanks for pointing that out to me. I just thought that CET was central time :) Yes sysinstall's as good a way as any, it'll set your timezone and also let you choose between running with a UTC or local time CMOS clock. Or you can manually tun tzsetup(8) and create (or not) /etc/wall_cmos_clock .. see adjkerntz(8) Take little notice of people opining that you must or even should run CMOS UTC time; that's entirely up to you. I've always preferred local time CMOS clocks personally; sysinstall creates /etc/wall_cmos_clock and cron runs 'adjkerntz -a' halfhourly at times when daylight savings time might come or go in your zone, and that's always worked fine here. The reason using UTC for the cmos clock is that it never changes like US daylight savings does. Now if your timezone doesn't ever need to be pushed forward or backwards then it won't be a problem, but otherwise evertime the system boots up, it has to determine if the cmos time is correct or needs to be adjusted. A UTC time will always be correct and can be turned exactly into the correct time at the moment. I think that if FreeBSD crashed just after it booted up and adjusted the hour forward, then on the next reboot, it would adjust it another hour forward. In general, it is just harder to manage. Even worse would be my Quad boot system with Gentoo Linux, FreeBSD, OpenBSD, NetBSD. If I used local time for my cmos clock then every daylight savings change, each os would adjust the clock independently and I'd be 3 hours off. I don't believe that's correct Loren, at least, not for FreeBSD anyway. Well, I haven't looked into all the details of how FreeBSD does this, but I gaurentee that there is a point where FreeBSD can crash and the clock could be knocked off an hour which wouldn't happen if it's running UTC. Though this window could just be a matter of seconds, I'm not sure. Also multi-booting multiple OS's with it set to local time will always be a problem unless you set only one os to update the clock, and even then, while running the other oses, the update will never happen until you boot into the os which does it. But, in general, it is just a little bit less reliable using local to UTC unless you are not affected by any daylight savings changes like Arizona in the US or, I'm sure, many other places around the world. snip -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Received mail timestamp is off by 7 hours
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Loren M. Lang Sent: Wednesday, March 02, 2005 2:29 AM To: Ian Smith Cc: Loren M. Lang; Pat Maddox; freebsd-questions@freebsd.org Subject: Re: Received mail timestamp is off by 7 hours little bit less reliable using local to UTC unless you are not affected by any daylight savings changes like Arizona in the US or, I'm sure, many other places around the world. There's no excuse for a mailserver to not be synced to a NTP source. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Received mail timestamp is off by 7 hours
On Wed, 2 Mar 2005 03:11:19 -0800, Ted Mittelstaedt wrote: Loren wrote: little bit less reliable using local to UTC unless you are not affected by any daylight savings changes like Arizona in the US or, I'm sure, many other places around the world. For a desktop or test machine, booting multiple OS at various times like you said, I'd as likely run UTC CMOS too. Enough to confuse already .. I've just some fun browsing again through bits of code from /usr/src like sbin/adjkerntz/adjkerntz.c, sys/i386/isa/clock.c, sys/isa/rtc.h, sys/i386/include/clock.h, just to scratch the surface. Great stuff. I'm yet to be convinced there's an even potential technical problem in running local time RTC on a server that runs FreeBSD all the time. I won't labour personal preferences further, but don't feel vulnerable. Yes, we do DST changes; I'd guess well under a millisecond twice a year. Hey, you can lose your bootsector if the sky falls at the wrong instant! Ted writes: There's no excuse for a mailserver to not be synced to a NTP source. Absolutely, or indeed most anyserver. Or even a multiboot workstation! Ian out. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Loren M. Lang writes: Well, I haven't looked into all the details of how FreeBSD does this, but I gaurentee that there is a point where FreeBSD can crash and the clock could be knocked off an hour which wouldn't happen if it's running UTC. Traditionally, UNIX sets the real-time clock to UTC. There's no good reason to set it to anything else, unless you are running multiple boots with other operating systems that don't expect UTC in the RTC. Even then, you have to be careful. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Ted Mittelstaedt writes: There's no excuse for a mailserver to not be synced to a NTP source. I'd extend that to apply to any server. Practically all the things a server does are dependent in some way on the correct time. This is also increasingly true of desktops. Gone are the days when you could just set the clock forward or back temporarily for some specific purpose. Today if you do that on a lot of desktops, you'll mess things up terribly (imagine having every birthday for the next five years trigger simultaneously when you open Outlook, or having half your file system marked for immediate deletion--not a pretty picture). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
There's no excuse for a mailserver to not be synced to a NTP source. I'd extend that to apply to any server. Practically all the things a server does are dependent in some way on the correct time. I have three excuses: 1) NTP is difficult to configure. I've done it, but it wasn't trivial. 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Luke wrote: 1) NTP is difficult to configure. I've done it, but it wasn't trivial. It's always seemed rather straightforward to me, what in particular gave you trouble, perhaps we could help? 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. time.nist.gov is public, and has it's own atomic clock. A google search for public ntp servers also found this: http://www.pool.ntp.org/ 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. That suggests larger problems on your system, to me, but I dunno. Tom ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Luke writes: 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. The overwhelming majority of ISPs I have used or inquired about had (at least) one customers-accessible NTP server. It is my understanding many universities will also ignore off campus requests that do not affect their own operations. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
In the last episode (Mar 02), Luke said: There's no excuse for a mailserver to not be synced to a NTP source. I'd extend that to apply to any server. Practically all the things a server does are dependent in some way on the correct time. I have three excuses: 1) NTP is difficult to configure. I've done it, but it wasn't trivial. 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. You may not know about pool.ntp.org, then. As of Sep 2004, there were 200 public servers in the pool. See http://www.pool.ntp.org/ for instructions, including a nice 4-line ntp.conf file. 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. Two options: You can tell ntp to never step the clock by adding the -x flag, or you can increase the slew rate by fiddling with /sys/kern/kern_ntptime.c . You may need to do both. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
1) NTP is difficult to configure. I've done it, but it wasn't trivial. It's always seemed rather straightforward to me, what in particular gave you trouble, perhaps we could help? Well, there seemed to be two different services. One was something that would run only on boot. The other was a daemon. The daemon seemed more useful, especially for a system that shouldn't be rebooted often, but it had a wide variety of configuration options. The NTP server that I found to connect to insisted that I not connect to it more frequently than X, and X was a longer time interval than was defined in the default setup, so I had to mess around with it. It's been almost a year since I tried to set this up, so I don't remember anything more specific than that. If the NTP server I was using had been a bit more permissive, I probably could've used the default configuration without changes. 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. time.nist.gov is public, and has it's own atomic clock. A google search for public ntp servers also found this: http://www.pool.ntp.org/ Thanks for the tip! I remember seeing www.pool.ntp.org before, but I misunderstood what it was for. 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. That suggests larger problems on your system, to me, but I dunno. You're right. This machine did have serious problems. The clock was wild. Using the NTP daemon to try to correct it just aggravated the situation because calibration was just about impossible. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Luke wrote: That suggests larger problems on your system, to me, but I dunno. 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. You're right. This machine did have serious problems. The clock was wild. Using the NTP daemon to try to correct it just aggravated the situation because calibration was just about impossible. This occurs on some machines (older ones in my experience) because FreeBSD (I guess) selects the wrong type of hardware timecounter for the CPU it's on. Now, it's likely that it's really the hardware's fault, but changing the sysctl kern.timecounter.hardware to another value (`sysctl kern.timecounter.choice` will give you options) has worked for me on at least two different occasions when we faced this problem. IIRC, one was an old AMD K6-2/475 on an Asus P5-A mobo; the other was an original Pentium, but I don't know the mobo model off the top of my head. HTH, Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Luke writes: 1) NTP is difficult to configure. I dunno. I configured it in a few minutes on my test box. 2) Finding an NTP server willing to accept traffic from the public isn't easy either. For me it involved a scavenger hunt through out-of-date websites and a lot of failed attempts. There must be thousands of such sites. Heck, Windows ships with an NTP client that it uses to synchronize automatically--although by default it only queries the server once a week, instead of once ever few minutes as it should (PC clocks are so notoriously bad in keeping time that there's no way a clock would stay correct for an entire week). 3) If your clock tends to run noticably fast or slow, constant NTP corrections tend to do more harm than good, at least in my experience. It got to where I couldn't even run a buildworld because NTP kept tinkering with the clock in the middle of the process. I haven't noticed any problem at all. FreeBSD is especially adept at tinkering in a discreet way that doesn't harm anything. It gradually slews the clock instead of stepping it, and nothing on the machine is affected by the slight changes. My LAN is synchronized with some pretty extraordinary accuracy thanks to NTP, which runs on the main server. The other two machines synchronize from this main server. I have about a dozen servers in the config that the machine polls periodically (not very often now, since the daemon has a pretty good idea of the drift on my system clock). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Tom Trelvik writes: That suggests larger problems on your system, to me, but I dunno. If NTP is configured to step instead of slew, it can cause the clock to jump a bit for a while. Slewing is smooth and avoids this, but it takes a lot longer for NTP to initially get the time right. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
On Mon, Feb 28, 2005 at 12:58:17AM +1100, Ian Smith wrote: On Sun, 27 Feb 2005 03:10:12 -0700 Pat Maddox [EMAIL PROTECTED] wrote: Alright, I got it all working now. Not sure how to change the time zone with config files, so I just used sysinstall to change it to MST (time zone is arbitrary, but since this is the zone I live in, it's convenient for me). Then I used ntpdate to sync it, and it's working well now. Thanks for pointing that out to me. I just thought that CET was central time :) Yes sysinstall's as good a way as any, it'll set your timezone and also let you choose between running with a UTC or local time CMOS clock. Or you can manually tun tzsetup(8) and create (or not) /etc/wall_cmos_clock .. see adjkerntz(8) Take little notice of people opining that you must or even should run CMOS UTC time; that's entirely up to you. I've always preferred local time CMOS clocks personally; sysinstall creates /etc/wall_cmos_clock and cron runs 'adjkerntz -a' halfhourly at times when daylight savings time might come or go in your zone, and that's always worked fine here. The reason using UTC for the cmos clock is that it never changes like US daylight savings does. Now if your timezone doesn't ever need to be pushed forward or backwards then it won't be a problem, but otherwise evertime the system boots up, it has to determine if the cmos time is correct or needs to be adjusted. A UTC time will always be correct and can be turned exactly into the correct time at the moment. I think that if FreeBSD crashed just after it booted up and adjusted the hour forward, then on the next reboot, it would adjust it another hour forward. In general, it is just harder to manage. Even worse would be my Quad boot system with Gentoo Linux, FreeBSD, OpenBSD, NetBSD. If I used local time for my cmos clock then every daylight savings change, each os would adjust the clock independently and I'd be 3 hours off. The only thing to watch running wall_cmos_clock is that if you boot to single user mode, before /etc/rc has run 'adjkerntz -i' the system will assume CMOS is UTC, so any files then modified show timestamps in UTC (discovered the hard way in Jan 2000 on a box with a broken y2k BIOS :) Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
On Mon, 28 Feb 2005 03:36:41 -0800 Loren M. Lang wrote: On Mon, Feb 28, 2005 at 12:58:17AM +1100, Ian Smith wrote: On Sun, 27 Feb 2005 03:10:12 -0700 Pat Maddox [EMAIL PROTECTED] wrote: Alright, I got it all working now. Not sure how to change the time zone with config files, so I just used sysinstall to change it to MST (time zone is arbitrary, but since this is the zone I live in, it's convenient for me). Then I used ntpdate to sync it, and it's working well now. Thanks for pointing that out to me. I just thought that CET was central time :) Yes sysinstall's as good a way as any, it'll set your timezone and also let you choose between running with a UTC or local time CMOS clock. Or you can manually tun tzsetup(8) and create (or not) /etc/wall_cmos_clock .. see adjkerntz(8) Take little notice of people opining that you must or even should run CMOS UTC time; that's entirely up to you. I've always preferred local time CMOS clocks personally; sysinstall creates /etc/wall_cmos_clock and cron runs 'adjkerntz -a' halfhourly at times when daylight savings time might come or go in your zone, and that's always worked fine here. The reason using UTC for the cmos clock is that it never changes like US daylight savings does. Now if your timezone doesn't ever need to be pushed forward or backwards then it won't be a problem, but otherwise evertime the system boots up, it has to determine if the cmos time is correct or needs to be adjusted. A UTC time will always be correct and can be turned exactly into the correct time at the moment. I think that if FreeBSD crashed just after it booted up and adjusted the hour forward, then on the next reboot, it would adjust it another hour forward. In general, it is just harder to manage. Even worse would be my Quad boot system with Gentoo Linux, FreeBSD, OpenBSD, NetBSD. If I used local time for my cmos clock then every daylight savings change, each os would adjust the clock independently and I'd be 3 hours off. I don't believe that's correct Loren, at least, not for FreeBSD anyway. adjkerntz -i when run on entering multi-user mode does not set the CMOS clock, it just reads from it to update the kernel clock if need be. If /etc/wall_cmos_clock exists, it knows to add the timezone offset to move the kernel clock to UTC; otherwise it takes CMOS clock time as UTC. Only adjkerntz -a (run from cron) makes adjustments on daylight savings time boundaries, and that's the only time it will update the CMOS clock. If running local time CMOS (/etc/wall_cmos_clock exists) then adjkerntz -i continues running in background the whole time. Only on a (proper) shutdown does init send a SIGTERM to adjkerntz, which then updates the local CMOS clock (if necessary) from the then kernel clock. If the system crashes without proper shutdown (eg power + UPS failure) then any changes made to the kernel clock during uptime aren't updated back to the CMOS clock which is otherwise free-running, that's all. At least, that's my reading of adjkerntz(8) and experience over 7 years. I did read much of the relevant code back in 2000 on a 2.2.6 system, but admittedly haven't checked since then to see if any of that's changed, and since it's a full-time server, haven't had to consider multi-boot. I also run local time on my 4.5-R laptop, _very_ rarely booting Windows, and haven't struck any problems with CMOS time changes in three years. Disclaimer remains: The only thing to watch running wall_cmos_clock is that if you boot to single user mode, before /etc/rc has run 'adjkerntz -i' the system will assume CMOS is UTC, so any files then modified show timestamps in UTC (discovered the hard way in Jan 2000 on a box with a broken y2k BIOS :) I should mention that Jean-Marc Zucconi gave me lots of good pointers in 2000 re fixing our system to handle that crook y2k BIOS. He suggested C patches, but I wimped out by adding some date commands to /etc/rc :) Sorry if this is getting a bit long .. it really comes down to personal choice; I sure wouldn't want to dissuade anyone from running Zulu CMOS! Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
It doesn't only happen when I receive mail from my gmail account - it's with all email that passes through this server. On Sun, 27 Feb 2005 17:54:56 +1000, Timothy Smith [EMAIL PROTECTED] wrote: check your gmail account it's set to the wrong time zone or something. if date gives the correct time then thats what your server is using. Pat Maddox wrote: I forgot to give a bit of info. My local machine has the correct time of 10:05PM, and the server has the correct time of 11:05PM. If I send an email from a mail account on the server to gmail, it has the correct time. If I send an email from gmail back to the server, that's when it has the weird time offset. On Sat, 26 Feb 2005 21:00:49 -0800, Kent Stewart [EMAIL PROTECTED] wrote: On Saturday 26 February 2005 08:38 pm, Pat Maddox wrote: I've been having a weird problem lately...when I download an email from my mailserver, the time is off by 7 hours. For example, if I receive an email at 9:30pm, it lists the time as 2:30pm in my mail client. I've determined that it's just a problem on received messages, because if I use my client with a different mail server, the time is fine, and if I send mail to another server, the time is fine. It's annoying to me because messages will show up somewhere in the middle of my 300+ message inbox, and users have been complaining about it. What's going on, and how do I fix it? I'm using postfix and courier-imap. For starters, it looks like you are running PDT. You have a -0700 offset and it should be -800. It could be on gmail.com but you can test your end :). So, I don't have any idea other than type date and see if you have the right date and timezone. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Pat Maddox writes: I forgot to give a bit of info. My local machine has the correct time of 10:05PM, and the server has the correct time of 11:05PM. If I send an email from a mail account on the server to gmail, it has the correct time. If I send an email from gmail back to the server, that's when it has the weird time offset. Can you post the complete headers of one of the messages that has the incorrect time? -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
I've included the headers of messages from both Gmail and Hotmail, to show that it's not on Gmail's end. Also, here's the output from date: %date Sun Feb 27 02:42:21 CET 2005 They should show up in my inbox as being received at 1:40am or so, but they show up as 6:40pm instead. From Gmail: Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by cantona.dnswatchdog.com (Postfix) with ESMTP id 3161733C1B for [EMAIL PROTECTED]; Sun, 27 Feb 2005 02:38:52 +0100 (CET) Received: by wproxy.gmail.com with SMTP id 67so1650347wri for [EMAIL PROTECTED]; Sun, 27 Feb 2005 00:37:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=hjLLSBpqixF9ZtT/yR/J0KR8cULmdWnOLmaYIsYKg99SQKXa7dEdESLtnPeg2N+mOL9Pf9PWdu6tQMDHpg97lKTqEJuoBNNeYb6oqh55yJglvxbCSHCKf+pJ6uKBdDlBXbK70uk9AKXugjD2VXjpYJN9jXploX3xgtWtU06wgVE= Received: by 10.54.57.1 with SMTP id f1mr19787wra; Sun, 27 Feb 2005 00:37:53 -0800 (PST) Received: by 10.54.42.28 with HTTP; Sun, 27 Feb 2005 00:37:53 -0800 (PST) Message-ID: [EMAIL PROTECTED] Date: Sun, 27 Feb 2005 01:37:53 -0700 From: Pat Maddox [EMAIL PROTECTED] Reply-To: Pat Maddox [EMAIL PROTECTED] To: Pat Maddox [EMAIL PROTECTED] Subject: test Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From Hotmail: Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from hotmail.com (bay103-f18.bay103.hotmail.com [65.54.174.28]) by cantona.dnswatchdog.com (Postfix) with ESMTP id A660C33C1B for [EMAIL PROTECTED]; Sun, 27 Feb 2005 02:39:59 +0100 (CET) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 27 Feb 2005 00:39:00 -0800 Message-ID: [EMAIL PROTECTED] Received: from 65.54.174.205 by by103fd.bay103.hotmail.msn.com with HTTP; Sun, 27 Feb 2005 08:38:25 GMT X-Originating-IP: [65.54.174.205] X-Originating-Email: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] From: Patrick Maddox [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: test from hotmail Date: Sun, 27 Feb 2005 08:38:25 + Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 Feb 2005 08:39:00.0233 (UTC) FILETIME=[C8B4B790:01C51CA7] On Sun, 27 Feb 2005 09:34:17 +0100, Anthony Atkielski [EMAIL PROTECTED] wrote: Pat Maddox writes: I forgot to give a bit of info. My local machine has the correct time of 10:05PM, and the server has the correct time of 11:05PM. If I send an email from a mail account on the server to gmail, it has the correct time. If I send an email from gmail back to the server, that's when it has the weird time offset. Can you post the complete headers of one of the messages that has the incorrect time? -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Pat Maddox writes: I've included the headers of messages from both Gmail and Hotmail, to show that it's not on Gmail's end. Also, here's the output from date: %date Sun Feb 27 02:42:21 CET 2005 That can't be right. You sent your message in reply to a message I sent at 9:34 CET. The time on your local machine is incorrect by seven hours. It should be one hour ahead of UTC right now. They should show up in my inbox as being received at 1:40am or so, but they show up as 6:40pm instead. And 1:40 is exactly seven hours later than 18:40. The disparity is visible in the timestamps, too: From Gmail: Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by cantona.dnswatchdog.com (Postfix) with ESMTP id 3161733C1B for [EMAIL PROTECTED]; Sun, 27 Feb 2005 02:38:52 +0100 (CET) Notice that the timestamp on your local e-mail server corresponds to 1:38:52 UTC, but the timestamp on Gmail's server ... Received: by wproxy.gmail.com with SMTP id 67so1650347wri for [EMAIL PROTECTED]; Sun, 27 Feb 2005 00:37:53 -0800 (PST) ... corresponds to 8:37:53 UTC, which is correct. The other timestamps for intermediate servers are also correct, but the timestamp generated by your machine on the original message is not ... Date: Sun, 27 Feb 2005 01:37:53 -0700 -0700 corresponds to MST (Mountain Standard Time in the U.S.), not CET (Central European Time). So the solution is to set the time and time _zone_ correctly on your machine. For a UNIX machine, the CMOS real-time clock should be set to UTC (what many people still call GMT), and then your time zone should be set to whatever is appropriate for your location (CET would correspond to most of Europe outside of the UK--here in France we are on CET). Are you by any chance running a dual-boot configuration? Windows expects the CMOS RTC to be set to local time. UNIX expects it to be set to UTC. If you are running only FreeBSD, you can just reset the CMOS to UTC and fix your time zone to match your location. If you are also running a boot of Windows or something like that, you'll have to leave the CMOS clock set to local time, and make appropriate adjustments. Unfortunately, I'm not sure which variables to change in FreeBSD, as I've always just set the time at installation time (when I'm asked if the local clock is UTC and what time zone I'm in). Maybe someone else can explain what needs to change in your FreeBSD configuration to set it to the correct time. In general, setting the time incorrectly on a local client machine in the SMTP protocol will produce seemingly random errors in the time on received messages, depending on the path they follow on their way to you (this is true even for messages you send to yourself). The local machine is almost always the one with the time set incorrectly (incorrect time on mail servers tends to be noticed by users very quickly, especially if more than one time zone is involved). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Alright, I got it all working now. Not sure how to change the time zone with config files, so I just used sysinstall to change it to MST (time zone is arbitrary, but since this is the zone I live in, it's convenient for me). Then I used ntpdate to sync it, and it's working well now. Thanks for pointing that out to me. I just thought that CET was central time :) On Sun, 27 Feb 2005 10:36:35 +0100, Anthony Atkielski [EMAIL PROTECTED] wrote: Pat Maddox writes: I've included the headers of messages from both Gmail and Hotmail, to show that it's not on Gmail's end. Also, here's the output from date: %date Sun Feb 27 02:42:21 CET 2005 That can't be right. You sent your message in reply to a message I sent at 9:34 CET. The time on your local machine is incorrect by seven hours. It should be one hour ahead of UTC right now. They should show up in my inbox as being received at 1:40am or so, but they show up as 6:40pm instead. And 1:40 is exactly seven hours later than 18:40. The disparity is visible in the timestamps, too: From Gmail: Return-Path: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by cantona.dnswatchdog.com (Postfix) with ESMTP id 3161733C1B for [EMAIL PROTECTED]; Sun, 27 Feb 2005 02:38:52 +0100 (CET) Notice that the timestamp on your local e-mail server corresponds to 1:38:52 UTC, but the timestamp on Gmail's server ... Received: by wproxy.gmail.com with SMTP id 67so1650347wri for [EMAIL PROTECTED]; Sun, 27 Feb 2005 00:37:53 -0800 (PST) ... corresponds to 8:37:53 UTC, which is correct. The other timestamps for intermediate servers are also correct, but the timestamp generated by your machine on the original message is not ... Date: Sun, 27 Feb 2005 01:37:53 -0700 -0700 corresponds to MST (Mountain Standard Time in the U.S.), not CET (Central European Time). So the solution is to set the time and time _zone_ correctly on your machine. For a UNIX machine, the CMOS real-time clock should be set to UTC (what many people still call GMT), and then your time zone should be set to whatever is appropriate for your location (CET would correspond to most of Europe outside of the UK--here in France we are on CET). Are you by any chance running a dual-boot configuration? Windows expects the CMOS RTC to be set to local time. UNIX expects it to be set to UTC. If you are running only FreeBSD, you can just reset the CMOS to UTC and fix your time zone to match your location. If you are also running a boot of Windows or something like that, you'll have to leave the CMOS clock set to local time, and make appropriate adjustments. Unfortunately, I'm not sure which variables to change in FreeBSD, as I've always just set the time at installation time (when I'm asked if the local clock is UTC and what time zone I'm in). Maybe someone else can explain what needs to change in your FreeBSD configuration to set it to the correct time. In general, setting the time incorrectly on a local client machine in the SMTP protocol will produce seemingly random errors in the time on received messages, depending on the path they follow on their way to you (this is true even for messages you send to yourself). The local machine is almost always the one with the time set incorrectly (incorrect time on mail servers tends to be noticed by users very quickly, especially if more than one time zone is involved). -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
Pat Maddox writes: Alright, I got it all working now. Not sure how to change the time zone with config files, so I just used sysinstall to change it to MST (time zone is arbitrary, but since this is the zone I live in, it's convenient for me). Well, no, time zone isn't arbitrary, it needs to be chosen carefully. Normally you set it to the time zone the machine is actually in (though for remote servers one can set it for the time zone the machine actually serves). Time zone can also influence the changeover dates and times for Daylight Saving Time, if that is used (if you're in Arizona, it's not). I'm not sure how this is handled in FreeBSD, but it always seems to magically set itself on my machines at the appropriate time. Even more important, however, is setting the real-time clock to UTC. Thanks for pointing that out to me. I just thought that CET was central time :) I think Central Standard Time is CST. -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
On Sun, 27 Feb 2005 03:10:12 -0700 Pat Maddox [EMAIL PROTECTED] wrote: Alright, I got it all working now. Not sure how to change the time zone with config files, so I just used sysinstall to change it to MST (time zone is arbitrary, but since this is the zone I live in, it's convenient for me). Then I used ntpdate to sync it, and it's working well now. Thanks for pointing that out to me. I just thought that CET was central time :) Yes sysinstall's as good a way as any, it'll set your timezone and also let you choose between running with a UTC or local time CMOS clock. Or you can manually tun tzsetup(8) and create (or not) /etc/wall_cmos_clock .. see adjkerntz(8) Take little notice of people opining that you must or even should run CMOS UTC time; that's entirely up to you. I've always preferred local time CMOS clocks personally; sysinstall creates /etc/wall_cmos_clock and cron runs 'adjkerntz -a' halfhourly at times when daylight savings time might come or go in your zone, and that's always worked fine here. The only thing to watch running wall_cmos_clock is that if you boot to single user mode, before /etc/rc has run 'adjkerntz -i' the system will assume CMOS is UTC, so any files then modified show timestamps in UTC (discovered the hard way in Jan 2000 on a box with a broken y2k BIOS :) Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
On Saturday 26 February 2005 08:38 pm, Pat Maddox wrote: I've been having a weird problem lately...when I download an email from my mailserver, the time is off by 7 hours. For example, if I receive an email at 9:30pm, it lists the time as 2:30pm in my mail client. I've determined that it's just a problem on received messages, because if I use my client with a different mail server, the time is fine, and if I send mail to another server, the time is fine. It's annoying to me because messages will show up somewhere in the middle of my 300+ message inbox, and users have been complaining about it. What's going on, and how do I fix it? I'm using postfix and courier-imap. For starters, it looks like you are running PDT. You have a -0700 offset and it should be -800. It could be on gmail.com but you can test your end :). So, I don't have any idea other than type date and see if you have the right date and timezone. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Received mail timestamp is off by 7 hours
I forgot to give a bit of info. My local machine has the correct time of 10:05PM, and the server has the correct time of 11:05PM. If I send an email from a mail account on the server to gmail, it has the correct time. If I send an email from gmail back to the server, that's when it has the weird time offset. On Sat, 26 Feb 2005 21:00:49 -0800, Kent Stewart [EMAIL PROTECTED] wrote: On Saturday 26 February 2005 08:38 pm, Pat Maddox wrote: I've been having a weird problem lately...when I download an email from my mailserver, the time is off by 7 hours. For example, if I receive an email at 9:30pm, it lists the time as 2:30pm in my mail client. I've determined that it's just a problem on received messages, because if I use my client with a different mail server, the time is fine, and if I send mail to another server, the time is fine. It's annoying to me because messages will show up somewhere in the middle of my 300+ message inbox, and users have been complaining about it. What's going on, and how do I fix it? I'm using postfix and courier-imap. For starters, it looks like you are running PDT. You have a -0700 offset and it should be -800. It could be on gmail.com but you can test your end :). So, I don't have any idea other than type date and see if you have the right date and timezone. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
