Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Thank.
On 02/27/2012 05:17 PM, Patrick Dupre wrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â"" 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Thank.
man date
Kevin
On Mon, 27 Feb 2012, Kevin Martin wrote:
On 02/27/2012 05:17 PM, Patrick Dupre wrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service �"" 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
I said SYNCHRONIZE not set time manually
Thank.
man date
Kevin
On 02/27/2012 03:36 PM, Patrick Dupre wrote:
On Mon, 27 Feb 2012, Kevin Martin wrote:
On 02/27/2012 05:17 PM, Patrick Dupre wrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service �"" 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
I said SYNCHRONIZE not set time manually
Make sure you have appropriate "server w.x.y.z" lines in your chrony.conf file (where ever it is, default /etc/chrony.conf) and make sure your firewall allows NTP. I also don't understand why you didn't just stick with ntpd. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent - - process. Prepare to vi." - ----------------------------------------------------------------------
On 02/28/2012 07:40 AM, Rick Stevens wrote:
Make sure you have appropriate "server w.x.y.z" lines in your chrony.conf file (where ever it is, default /etc/chrony.conf) and make sure your firewall allows NTP. I also don't understand why you didn't just stick with ntpd.
Probably because chronyd is the default/replacement for ntpd starting with F16.
On 02/27/2012 05:36 PM, Patrick Dupre wrote:
On Mon, 27 Feb 2012, Kevin Martin wrote:
On 02/27/2012 05:17 PM, Patrick Dupre wrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â"" 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
I said SYNCHRONIZE not set time manually
Thank.
man date
Kevin
I understand that but ntpd (and possibly chrony) had a limit as to how far out of sync your system could get before it would not try to sync with the ntp servers, hence you had to set the date/time manually first to a time within a minute or so and then start the daemon and it would sync up.
Kevin
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.ukwrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.**service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.**service â”” 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Thank.
--
You can use rdate...
install rdate with yum or whatever...
then as root
rdate time.mit.edu
YMMV
Marvin
==============================**==============================**
Patrick DUPRÉ | | Department of Chemistry | | Phone: (44)-(0)-1904-434384 The University of York | | Fax: (44)-(0)-1904-432516 Heslington | | York YO10 5DD United Kingdom | | email: patrick.dupre@york.ac.uk ==============================**==============================** ============== -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Mon, 27 Feb 2012, Rick Stevens wrote:
On 02/27/2012 03:36 PM, Patrick Dupre wrote:
On Mon, 27 Feb 2012, Kevin Martin wrote:
On 02/27/2012 05:17 PM, Patrick Dupre wrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service �"" 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
I said SYNCHRONIZE not set time manually
Make sure you have appropriate "server w.x.y.z" lines in your chrony.conf file (where ever it is, default /etc/chrony.conf) and make sure your firewall allows NTP.
THis is what is inside the chrony.conf file:
server 0.fedora.pool.ntp.org iburst server 1.fedora.pool.ntp.org iburst server 2.fedora.pool.ntp.org iburst server 3.fedora.pool.ntp.org iburst
Firewall configuration does not show any ntpd server. Do I need to add it manually ?
I also don't understand why you
didn't just stick with ntpd.
My understanding was that ntpd was depreciated!
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
-- "Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent -
process. Prepare to vi." -
On Mon, 27 Feb 2012, Kevin Martin wrote:
On 02/27/2012 05:36 PM, Patrick Dupre wrote:
On Mon, 27 Feb 2012, Kevin Martin wrote:
On 02/27/2012 05:17 PM, Patrick Dupre wrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â"" 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
I said SYNCHRONIZE not set time manually
Thank.
man date
Kevin
I understand that but ntpd (and possibly chrony) had a limit as to how far out of sync your system could get before it would not try to sync with the ntp servers, hence you had to set the date/time manually first to a time within a minute or so and then start the daemon and it would sync up.
Originally there was one hour difference. Now there are 1 minute.
On Mon, 27 Feb 2012, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.ukwrote:
Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.**service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.**service â”” 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Thank.
--
You can use rdate...
install rdate with yum or whatever...
then as root
rdate time.mit.edu
rdate: timeout for time.mit.edu rdate: timeout for 0.fedora.pool.ntp.org
On Mon, 2012-02-27 at 19:49 -0600, Kevin Martin wrote:
I understand that but ntpd (and possibly chrony) had a limit as to how far out of sync your system could get before it would not try to sync with the ntp servers, hence you had to set the date/time manually first to a time within a minute or so and then start the daemon and it would sync up.
With NTP, there was the ntpdate command that would automatically do that for you (automatically force in the current time with ntpdate, no matter how far off it was, then use ntp to keep the clock in sync). I'd expect chrony to do something similar, the need would be the same.
I can't recall ever having to do any firewall gymnastics with NTP, it's an outgoing connection, and I didn't restrict outgoing connections. If you'd gone bonkers restricting everything without due care, you may have isolated yourself.
There's every chance that there's some stale addresses being doled out for time servers that don't run anymore. You could look at the pool website, and try other servers: http://www.pool.ntp.org/en/ I know that I've, certainly, come across that problem in the past.
On Tuesday 28 February 2012 10:28:37 Patrick Dupre wrote:
On Mon, 27 Feb 2012, Marvin Kosmal wrote:
install rdate with yum or whatever...
then as root
rdate time.mit.edu
rdate: timeout for time.mit.edu rdate: timeout for 0.fedora.pool.ntp.org
What does
ping time.mit.edu
say?
Also, does "rdate time.mit.edu" work when you disable the firewall temporarily (and I mean TEMPORARILY --- disabling the firewall is a Bad Idea, and makes sense only for firewall testing purposes).
HTH, :-) Marko
Comment: ntpd is not deprecated - fedora decided to use chrony as it is supposed to handle situations like a mobile laptop where you're not permanently connected to the net.
ntpd is still the benchmark time management tool.
However, if you're using a laptop you may prefer chrony.
gene
OK, it is solved.
The University here, (in Germany) closed all the ports and provide a time server.
Thank you to every body who tried to help me.
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Run: system-config-date and in the Time Zone display be sure UTC is checked.
On 2012/02/28 07:38, Aaron Konstam wrote:
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.Run: system-config-date and in the Time Zone display be sure UTC is checked.
Unless somebody broke ntp that last is in no way required. It has never been required. It doesn't even seem to require the motherboard clock to be set to UTC.
{^_^}
On Tue, 2012-02-28 at 14:10 -0800, jdow wrote:
On 2012/02/28 07:38, Aaron Konstam wrote:
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.Run: system-config-date and in the Time Zone display be sure UTC is checked.
Unless somebody broke ntp that last is in no way required. It has never been required. It doesn't even seem to require the motherboard clock to be set to UTC.
{^_^}
Although it is always good to hear from jdow her statement is wrong. Tim Waugh and I spent at least a month trying to debug the fact that on my network printer browsing did not work. After a lot of agony and searching log files we found that the problem was the print client was jumping around in time so the server got confused about the browsing and just gave up. Also ntpd would quit shortly after it was started. The problem was fixed by checking UTC in the system-config-date display.
On 2012/02/29 06:33, Aaron Konstam wrote:
On Tue, 2012-02-28 at 14:10 -0800, jdow wrote:
On 2012/02/28 07:38, Aaron Konstam wrote:
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.Run: system-config-date and in the Time Zone display be sure UTC is checked.
Unless somebody broke ntp that last is in no way required. It has never been required. It doesn't even seem to require the motherboard clock to be set to UTC.
{^_^}
Although it is always good to hear from jdow her statement is wrong. Tim Waugh and I spent at least a month trying to debug the fact that on my network printer browsing did not work. After a lot of agony and searching log files we found that the problem was the print client was jumping around in time so the server got confused about the browsing and just gave up. Also ntpd would quit shortly after it was started. The problem was fixed by checking UTC in the system-config-date display.
I cannot speak to chrony. But I've been running ntp happily since it was xntp.
On my SL6.2 virtual test machines which run in VirtualBox hosted on Win 7 the clocks are all set, properly, to Los Angeles time. ntp locks right up slick as you could ask. I do take back the bit about motherboard running UTC. I notice VirtualBox has the UTC checkbox ticked. So motherboard is UTC. I believe there is a configuration setting for NTP to handle that. But the timezone setting certainly does not have to he UTC.
[jdow@sl6 ~]$ date;date -u Wed Feb 29 15:49:08 PST 2012 Wed Feb 29 23:49:08 UTC 2012
ntpq> peers remote refid st t when poll reach delay offset jitter ============================================================================== +we.love.servers 192.43.244.18 2 u 29 64 377 36.411 -84.322 10.851 +64.73.32.134 192.36.143.150 2 u 1 64 377 85.706 -101.83 11.770 -mirror 204.9.54.119 2 u 46 64 377 83.161 -69.662 21.143 *me2.xxxxxxxxx.x 69.25.96.13 2 u 44 64 377 0.431 -97.046 13.406
On the SL6.2 firewall machine the motherboard clock is set to UTC, the system is set to Los Angeles time. [jdow@me2 ~]$ date;date -u Wed Feb 29 15:49:43 PST 2012 Wed Feb 29 23:49:43 UTC 2012
It setup this way mostly right out of the box. I had OTHER problems porting in my very historically based configuration; but, ntp was no big deal.
(SELinux is a borked pain in the asterisk. I leave it running. But I am less and less enthused by it every day. It, dhcpd, named, and SpamAssassin don't seem to get along well together when dhcpd is supposed to update a useful dhcpd setup. And some how named gets MANY hanging locks that make it impossible to shut it down gracefully.)
This is the important part of the setup. ===8<--- driftfile /var/lib/ntp/drift restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst includefile /etc/ntp/crypto/pw keys /etc/ntp/keys #trustedkey 4 8 42 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
The virtual machines are similar: ===8<--- driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1
server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst
includefile /etc/ntp/crypto/pw keys /etc/ntp/keys
# new machine (A pointer to the local server) server 192.168.xx.1 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
{^_^}
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/29/2012 07:02 PM, jdow wrote:
On 2012/02/29 06:33, Aaron Konstam wrote:
On Tue, 2012-02-28 at 14:10 -0800, jdow wrote:
On 2012/02/28 07:38, Aaron Konstam wrote:
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Run: system-config-date and in the Time Zone display be sure UTC is checked.
Unless somebody broke ntp that last is in no way required. It has never been required. It doesn't even seem to require the motherboard clock to be set to UTC.
{^_^}
Although it is always good to hear from jdow her statement is wrong. Tim Waugh and I spent at least a month trying to debug the fact that on my network printer browsing did not work. After a lot of agony and searching log files we found that the problem was the print client was jumping around in time so the server got confused about the browsing and just gave up. Also ntpd would quit shortly after it was started. The problem was fixed by checking UTC in the system-config-date display.
I cannot speak to chrony. But I've been running ntp happily since it was xntp.
On my SL6.2 virtual test machines which run in VirtualBox hosted on Win 7 the clocks are all set, properly, to Los Angeles time. ntp locks right up slick as you could ask. I do take back the bit about motherboard running UTC. I notice VirtualBox has the UTC checkbox ticked. So motherboard is UTC. I believe there is a configuration setting for NTP to handle that. But the timezone setting certainly does not have to he UTC.
[jdow@sl6 ~]$ date;date -u Wed Feb 29 15:49:08 PST 2012 Wed Feb 29 23:49:08 UTC 2012
ntpq> peers remote refid st t when poll reach delay offset jitter ==============================================================================
+we.love.servers 192.43.244.18 2 u 29 64 377 36.411 -84.322 10.851 +64.73.32.134 192.36.143.150 2 u 1 64 377 85.706 -101.83 11.770 -mirror 204.9.54.119 2 u 46 64 377 83.161 -69.662 21.143 *me2.xxxxxxxxx.x 69.25.96.13 2 u 44 64 377 0.431 -97.046 13.406
On the SL6.2 firewall machine the motherboard clock is set to UTC, the system is set to Los Angeles time. [jdow@me2 ~]$ date;date -u Wed Feb 29 15:49:43 PST 2012 Wed Feb 29 23:49:43 UTC 2012
It setup this way mostly right out of the box. I had OTHER problems porting in my very historically based configuration; but, ntp was no big deal.
(SELinux is a borked pain in the asterisk. I leave it running. But I am less and less enthused by it every day. It, dhcpd, named, and SpamAssassin don't seem to get along well together when dhcpd is supposed to update a useful dhcpd setup. And some how named gets MANY hanging locks that make it impossible to shut it down gracefully.)
This is the important part of the setup. ===8<--- driftfile /var/lib/ntp/drift restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst includefile /etc/ntp/crypto/pw keys /etc/ntp/keys #trustedkey 4 8 42 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
The virtual machines are similar: ===8<--- driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1
server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst
includefile /etc/ntp/crypto/pw keys /etc/ntp/keys
# new machine (A pointer to the local server) server 192.168.xx.1 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
{^_^}
Please tell us the problems you are having with SELinux? Maybe we can fix it for everyone if you have a common configuration. Open a Bugzilla please.
On Wed, 2012-02-29 at 16:02 -0800, jdow wrote:
On 2012/02/29 06:33, Aaron Konstam wrote:
On Tue, 2012-02-28 at 14:10 -0800, jdow wrote:
On 2012/02/28 07:38, Aaron Konstam wrote:
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service â”” 4150 /usr/sbin/chronyd -u chrony but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.Run: system-config-date and in the Time Zone display be sure UTC is checked.
Unless somebody broke ntp that last is in no way required. It has never been required. It doesn't even seem to require the motherboard clock to be set to UTC.
{^_^}
Although it is always good to hear from jdow her statement is wrong. Tim Waugh and I spent at least a month trying to debug the fact that on my network printer browsing did not work. After a lot of agony and searching log files we found that the problem was the print client was jumping around in time so the server got confused about the browsing and just gave up. Also ntpd would quit shortly after it was started. The problem was fixed by checking UTC in the system-config-date display.
I cannot speak to chrony. But I've been running ntp happily since it was xntp.
On my SL6.2 virtual test machines which run in VirtualBox hosted on Win 7 the clocks are all set, properly, to Los Angeles time. ntp locks right up slick as you could ask. I do take back the bit about motherboard running UTC. I notice VirtualBox has the UTC checkbox ticked. So motherboard is UTC. I believe there is a configuration setting for NTP to handle that. But the timezone setting certainly does not have to he UTC.
[jdow@sl6 ~]$ date;date -u Wed Feb 29 15:49:08 PST 2012 Wed Feb 29 23:49:08 UTC 2012
ntpq> peers remote refid st t when poll reach delay offset jitter ============================================================================== +we.love.servers 192.43.244.18 2 u 29 64 377 36.411 -84.322 10.851 +64.73.32.134 192.36.143.150 2 u 1 64 377 85.706 -101.83 11.770 -mirror 204.9.54.119 2 u 46 64 377 83.161 -69.662 21.143 *me2.xxxxxxxxx.x 69.25.96.13 2 u 44 64 377 0.431 -97.046 13.406
On the SL6.2 firewall machine the motherboard clock is set to UTC, the system is set to Los Angeles time. [jdow@me2 ~]$ date;date -u Wed Feb 29 15:49:43 PST 2012 Wed Feb 29 23:49:43 UTC 2012
It setup this way mostly right out of the box. I had OTHER problems porting in my very historically based configuration; but, ntp was no big deal.
(SELinux is a borked pain in the asterisk. I leave it running. But I am less and less enthused by it every day. It, dhcpd, named, and SpamAssassin don't seem to get along well together when dhcpd is supposed to update a useful dhcpd setup. And some how named gets MANY hanging locks that make it impossible to shut it down gracefully.)
This is the important part of the setup. ===8<--- driftfile /var/lib/ntp/drift restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst includefile /etc/ntp/crypto/pw keys /etc/ntp/keys #trustedkey 4 8 42 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
The virtual machines are similar: ===8<--- driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1
server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst
includefile /etc/ntp/crypto/pw keys /etc/ntp/keys
# new machine (A pointer to the local server) server 192.168.xx.1 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
{^_^}
Sometimes I wonder if we are all speaking the same language. I can't comment on what VirtualBox does, nor what Windows 7 does, but here is my experience.
My hardware was set to UTC time. My system time was set to local time CDT. But until UTC was checked in the system-config-date GUI, nether cups printer browsing would work nor would ntpd stay running.
On 2012/03/01 06:28, Aaron Konstam wrote:
Sometimes I wonder if we are all speaking the same language. I can't comment on what VirtualBox does, nor what Windows 7 does, but here is my experience.
My hardware was set to UTC time. My system time was set to local time CDT. But until UTC was checked in the system-config-date GUI, nether cups printer browsing would work nor would ntpd stay running.
Odds are it was something else in your setup. And don't forget, I tend to administer via command prompts via ssh into the machine. That can make a BIG difference. On the commandline "ntpq" is a nice friend.
I vaguely remember going through this hassle back with xntp when it was a new thing. I got it tamed and that taming moves with me as I move onwards in distros. I always use ntpdate to prime the pump, though. That might be some of the magic. Some other parts of the magic is make sure ntpd or ntpdate does not try to run before the outside network is up AND the firewall is configured. I load the outside net "by hand" very late in the startup sequence and have ifup-local fire off some startup commands for the likes of fetchmail, ntp, and firewall configuration.
{^_^}
On Thu, 2012-03-01 at 08:28 -0600, Aaron Konstam wrote:
My hardware was set to UTC time. My system time was set to local time CDT. But until UTC was checked in the system-config-date GUI, nether cups printer browsing would work nor would ntpd stay running.
If your hardware is set to UTC, then your time configuration should be set to UTC. The setting is for what the hardware clock is set to, not what the software clock is running on.
When you set what timezone you are in, the computer works out the difference between it and UTC, and your software clocks show you your local time.
If the time is wrong, then that could upset some services that might treat files from the future as being invalid, or very old files as some type of other problem.
On Fri, 2012-03-02 at 21:11 +1030, Tim wrote:
On Thu, 2012-03-01 at 08:28 -0600, Aaron Konstam wrote:
My hardware was set to UTC time. My system time was set to local time CDT. But until UTC was checked in the system-config-date GUI, nether cups printer browsing would work nor would ntpd stay running.
If your hardware is set to UTC, then your time configuration should be set to UTC. The setting is for what the hardware clock is set to, not what the software clock is running on.
When you set what timezone you are in, the computer works out the difference between it and UTC, and your software clocks show you your local time.
If the time is wrong, then that could upset some services that might treat files from the future as being invalid, or very old files as some type of other problem.
The above is exactly what happened to me, which prevented cups browsing to occur.
On Fri, 2012-03-02 at 07:34 -0600, Aaron Konstam wrote:
The above is exactly what happened to me, which prevented cups browsing to occur.
Not so much that CUPS is upset that you had the setting for UTC set, but that you had time and/or timezone set wrong, then.
All services should work properly whether the hardware clock is set to UTC or not. The software that handles the time will get it right when you set the configuration for UTC to match what you're actually doing with the hardware clock. If you mis-set that, you can expect problems.
I don't know whether it's "supposed to be" that all programs ignore the hardware clock, and check the software clock for time. But I dare say that it's possible for them to look at the hardware clock, directly. Either way, whether reading software or hardware clocks, your system configurations that say what your timezone is, and whether the hardware clock runs on local time or UTC, should be set correctly.
On Sat, 2012-03-03 at 22:08 +1030, Tim wrote:
On Fri, 2012-03-02 at 07:34 -0600, Aaron Konstam wrote:
The above is exactly what happened to me, which prevented cups browsing to occur.
Not so much that CUPS is upset that you had the setting for UTC set, but that you had time and/or timezone set wrong, then.
All services should work properly whether the hardware clock is set to UTC or not. The software that handles the time will get it right when you set the configuration for UTC to match what you're actually doing with the hardware clock. If you mis-set that, you can expect problems.
I don't know whether it's "supposed to be" that all programs ignore the hardware clock, and check the software clock for time. But I dare say that it's possible for them to look at the hardware clock, directly. Either way, whether reading software or hardware clocks, your system configurations that say what your timezone is, and whether the hardware clock runs on local time or UTC, should be set correctly.
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly and ntpd would crash shortly after starting.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/03/2012 10:13 AM, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock
was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly and ntpd would crash shortly after starting. ntpd would not really crash - it would exit with an error because the time difference was too great.
Mikkel
Am 03.03.2012 17:50, schrieb Mikkel L. Ellertson:
On 03/03/2012 10:13 AM, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly and ntpd would crash shortly after starting
ntpd would not really crash - it would exit with an error because the time difference was too great
and the practical difference is?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/03/2012 11:19 AM, Reindl Harald wrote:
Am 03.03.2012 17:50, schrieb Mikkel L. Ellertson:
On 03/03/2012 10:13 AM, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly and ntpd would crash shortly after starting
ntpd would not really crash - it would exit with an error because the time difference was too great
and the practical difference is?
An error message in the logs about why it exited. It makes it much easier to troubleshoot why it quit.
Besides, a program crash indicates bad programming, while an error exit shows the programmer provided for this possibility.
Mikkel - -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
On Sat, 2012-03-03 at 10:13 -0600, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly
That's still not an issue of CUPS not liking the setting of UTC (how you originally presented the situation). The issue of CUPS not working was not one of "UTC" or "not UTC" being set.
It's CUPS not liking you setting the clock wrongly, as may well happen with other things.
And that was the point I was making.
and ntpd would crash shortly after starting.
Really crash or just exit doing nothing? There's a difference.
Anyway, it hardly matters, time configuration needs setting up properly for NTP to work.
On Sun, 2012-03-04 at 22:39 +1030, Tim wrote:
On Sat, 2012-03-03 at 10:13 -0600, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly
That's still not an issue of CUPS not liking the setting of UTC (how you originally presented the situation). The issue of CUPS not working was not one of "UTC" or "not UTC" being set.
It's CUPS not liking you setting the clock wrongly, as may well happen with other things.
And that was the point I was making.
Well your point is incorrect. Cups browsing did not work if UTC was not set. TThe clocks were set correctly. The hardware clock was operating on UTC time and the system clock was running on local time.
On 2012/03/04 13:57, Aaron Konstam wrote:
On Sun, 2012-03-04 at 22:39 +1030, Tim wrote:
On Sat, 2012-03-03 at 10:13 -0600, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly
That's still not an issue of CUPS not liking the setting of UTC (how you originally presented the situation). The issue of CUPS not working was not one of "UTC" or "not UTC" being set.
It's CUPS not liking you setting the clock wrongly, as may well happen with other things.
And that was the point I was making.
Well your point is incorrect. Cups browsing did not work if UTC was not set. TThe clocks were set correctly. The hardware clock was operating on UTC time and the system clock was running on local time.
There are three "clocks" you want to consider.
The battery powered HW clock is read exactly once, on boot. "hwclock" reads /etc/adjtime. The third line in /etc/adjtime declares either UTC or LOCAL for what time the hardware clock keeps
The system clock internally is always kept in UTC.
The clock presented to the user in the date command or ls commands, for examples, is in adjusted automatically by the OS on queries to match the system's time zone setting. So you have to have both time zone setting and hardware clock setting correct or your system will get confused.
I have none of the problems you describe here with a hardware clock set to UTC and the local time zone set to Los Angeles local time.
Can you point to CUPS documentation that requires the system timezone value be set to UTC? (Of course, the internal clock Linux maintains is in UTC.)
{^_^}
On Sun, 2012-03-04 at 15:57 -0600, Aaron Konstam wrote:
Well your point is incorrect. Cups browsing did not work if UTC was not set. TThe clocks were set correctly. The hardware clock was operating on UTC time and the system clock was running on local time.
You just don't get it, do you?! You've even said it above:
Your hardware clock is running on UTC
Therefore, you ***MUST*** set your clock configuration to say that UTC is set. If you do not, then your time is set wrong.
Correct setting of your time is dependent on the hardware clock, setting the UTC/not-UTC flag, and setting the correct timezone. The combination of them all allows the computer to work out what localtime is.
Again, I repeat, it's not a CUPS fault that it doesn't like UTC set. It's your fault that you're running your clock on UTC but saying that it is not.
The UTC/not-UTC setting is for the hardware clock, not the software clock.
If you run the hardware clock on UTC, then you set the UTC flag for UTC.
If you run the hardware clock on local time, then set the UTC flag for local time.
CUPS will work either way. It doesn't care whether one clock is set to UTC, or not. What it cares about is the correct time.
But if you set your hardware clock on UTC, but say it's running localtime; or, if you set your clock on localtime, but say it's running on UTC; you ARE going to have problems, because doing so is just plain wrong.
*** THE UTC FLAG IS FOR THE HARDWARE CLOCK *** ^^^^^^^^ I've said this about three times, in three emails, what's so hard to understand about it?
On 2012/03/04 22:45, Tim wrote:
On Sun, 2012-03-04 at 15:57 -0600, Aaron Konstam wrote:
Well your point is incorrect. Cups browsing did not work if UTC was not set. TThe clocks were set correctly. The hardware clock was operating on UTC time and the system clock was running on local time.
You just don't get it, do you?! You've even said it above:
Your hardware clock is running on UTCTherefore, you ***MUST*** set your clock configuration to say that UTC is set. If you do not, then your time is set wrong.
I explained why and why your terminology is possibly confusing. If your HARDWARE clock, the one on the motehrboard, is set to UTC you must tell the OS so it knows to adjust its internal clock on boot to match by simply reading it. If it said LOCAL and you HW clock was set to local time the OS can use the TZ setting to translate the motherboard clock's local time to UTC. Then your OS's clock is set to UTC, which fact is invisible to you except that "things work."
Correct setting of your time is dependent on the hardware clock, setting the UTC/not-UTC flag, and setting the correct timezone. The combination of them all allows the computer to work out what localtime is.
Exactly. And for all directory listings and routine purposes the time displayed to the user is the system's UTC corrected to local time. So you really never see what time the OS thinks it is. It "feels like" it is local time.
Again, I repeat, it's not a CUPS fault that it doesn't like UTC set. It's your fault that you're running your clock on UTC but saying that it is not.
Fastening on CUPS is probably obscuring the matter, Tim. Concentrate on the fact that ntp was not working for him. Since it has a limited adjustment range, by design, it is quite obvious he had his motherboard clock either set to UTC and he'd told his OS it was local time, or his motherboard clock was set to local time and he'd told the OS it was UTC. Either way ntp will not startup correctly and will drop out. The check box for telling the OS that the hardware clock is UTC or local time is rather easy to overlook during setup.
The UTC/not-UTC setting is for the hardware clock, not the software clock.
Well, the check box is as is the value it changes, the third line in /etc/adjtime. {^_-} That is quite distinct from the TZ setting even if it appears on the same panel.
If you run the hardware clock on UTC, then you set the UTC flag for UTC.
If you run the hardware clock on local time, then set the UTC flag for local time.
Exactly. And maybe the above and my last posting helps send some understanding on the problem. {o.o}
CUPS will work either way. It doesn't care whether one clock is set to UTC, or not. What it cares about is the correct time.
But if you set your hardware clock on UTC, but say it's running localtime; or, if you set your clock on localtime, but say it's running on UTC; you ARE going to have problems, because doing so is just plain wrong.
*** THE UTC FLAG IS FOR THE HARDWARE CLOCK *** ^^^^^^^^I've said this about three times, in three emails, what's so hard to understand about it?
Calm down, step back, and try to alter vocabulary and expand descriptions so it is easier for people to understand what is really taking place. That's what I've tried to do now. I hope it works.
And to be sure, Tim, I am not disagreeing with you. You are 100% correct and still, not perhaps, "correct enough." More detail of what is really taking place is probably needed, detail you and I know so well we forget it when explaining to people.
{^_-}
On Mon, 2012-03-05 at 17:15 +1030, Tim wrote:
On Sun, 2012-03-04 at 15:57 -0600, Aaron Konstam wrote:
Well your point is incorrect. Cups browsing did not work if UTC was not set. TThe clocks were set correctly. The hardware clock was operating on UTC time and the system clock was running on local time.
You just don't get it, do you?! You've even said it above:
Your hardware clock is running on UTCTherefore, you ***MUST*** set your clock configuration to say that UTC is set. If you do not, then your time is set wrong.
Correct setting of your time is dependent on the hardware clock, setting the UTC/not-UTC flag, and setting the correct timezone. The combination of them all allows the computer to work out what localtime is.
Again, I repeat, it's not a CUPS fault that it doesn't like UTC set. It's your fault that you're running your clock on UTC but saying that it is not.
The UTC/not-UTC setting is for the hardware clock, not the software clock.
If you run the hardware clock on UTC, then you set the UTC flag for UTC.
If you run the hardware clock on local time, then set the UTC flag for local time.
CUPS will work either way. It doesn't care whether one clock is set to UTC, or not. What it cares about is the correct time.
But if you set your hardware clock on UTC, but say it's running localtime; or, if you set your clock on localtime, but say it's running on UTC; you ARE going to have problems, because doing so is just plain wrong.
*** THE UTC FLAG IS FOR THE HARDWARE CLOCK *** ^^^^^^^^ I've said this about three times, in three emails, what's so hard to understand about it?
It is not hard and that is what I have been saying from the beginning.
On Sun, 2012-03-04 at 14:13 -0800, jdow wrote:
On 2012/03/04 13:57, Aaron Konstam wrote:
On Sun, 2012-03-04 at 22:39 +1030, Tim wrote:
On Sat, 2012-03-03 at 10:13 -0600, Aaron Konstam wrote:
Whatever you theorize, here is what happened. The hardware clock was set to UTC, and the software clock was local time. However, the UTC box in system-config-date was not checked. Result was cups browsing did not work properly
That's still not an issue of CUPS not liking the setting of UTC (how you originally presented the situation). The issue of CUPS not working was not one of "UTC" or "not UTC" being set.
It's CUPS not liking you setting the clock wrongly, as may well happen with other things.
And that was the point I was making.
Well your point is incorrect. Cups browsing did not work if UTC was not set. TThe clocks were set correctly. The hardware clock was operating on UTC time and the system clock was running on local time.
There are three "clocks" you want to consider.
The battery powered HW clock is read exactly once, on boot. "hwclock" reads /etc/adjtime. The third line in /etc/adjtime declares either UTC or LOCAL for what time the hardware clock keeps
The system clock internally is always kept in UTC.
The clock presented to the user in the date command or ls commands, for examples, is in adjusted automatically by the OS on queries to match the system's time zone setting. So you have to have both time zone setting and hardware clock setting correct or your system will get confused.
I have none of the problems you describe here with a hardware clock set to UTC and the local time zone set to Los Angeles local time.
Can you point to CUPS documentation that requires the system timezone value be set to UTC? (Of course, the internal clock Linux maintains is in UTC.)
{^_^}
I am tired of this argument. Everyone is saying what I said at the beginning and then arguing with me when they say the same thing. In the beginning you said the setting the time to UTC does not matter and we now seem to all agree, so let us go on to something else.
On 2012/03/05 07:43, Aaron Konstam wrote:
On Sun, 2012-03-04 at 14:13 -0800, jdow wrote:
... I wrote a whole lot...
I am tired of this argument. Everyone is saying what I said at the beginning and then arguing with me when they say the same thing. In the beginning you said the setting the time to UTC does not matter and we now seem to all agree, so let us go on to something else.
You said it in such a way as to lead to massive misunderstanding. You do not set the time to UTC. The system presumes it knows UTC based on the setting in /etc/adjtime and TZ, if needed.
Your wording suggested you merely changed the TZ setting to UTC because anything else didn't work.
Sorry for not divining your real meaning from the start. I tend to guess wrong on ambiguities.
{^_^}
On Mon, 2012-03-05 at 09:36 -0600, Aaron Konstam wrote:
It is not hard and that is what I have been saying from the beginning.
It's the opposite of what you've been saying, repeatedly. Geez.
You kept saying CUPS wouldn't work if UTC was set. That's wrong. You said that you'd set the clock correctly, that was wrong.
For your benefit, and anyone else following the thread, ignoring the hole you're digging and just discussing clocks and timekeeping...
The hardware clock is the one that actually runs on the motherboard, whether the computer is running or not (the BIOS battery also powers the clock). Gnome, and probably others, also call it the system clock. It's this clock that the UTC flag refers to.
The software clock is the one that that Linux is running when the OS is running. It's what you see whenever you see the time on the desktop. Generally, you set your timezone so that it shows local time. But, if you travel, for instance, you can change the timezone at will. That'll change the display of time, without actually changing the clock (the displayed time always been an offset from the clock, the offset being set by your choice of timezone).
The software clock is set going using the time from the hardware clock when you boot. And the hardware clock is tweaked to match the software clock when you shutdown. NTP, or other time-keeping software, generally just keeps the software clock running on time. Letting your OS update the hardware clock, to match, on shutdown. Though, NTP (or similar) could update both when they adjust the clock to be correct.
You can run the hardware clock on local or UTC.
The advantage of UTC, is that it's a consistent time, unmangled by daylight savings, and constant if you move across timezones. The displayed time is changed, not the clock.
But if you dual-boot with an OS that doesn't understand UTC, you can run the clock on localtime. The hardware clock will get changed as daylight savings starts and ends, which can cause some problems. Even more so if Linux correctly sets the time at the changeover, then Windows dumbly moves the time by an hour, just because of the date, without actually checking what time the clock was set to against a timeserver. More fun ensues if you reboot several times on that date, and Windows insists on doing it more than once (yes, I have seen that happen, it's stupid, and not supposed to happen, but can).
A hardware clock running on localtime will also change time if you change timezones and you reset the time to suit the new localtime (your change will change the hardware and software clocks). This can also cause a few nuisance problems if you do change the clock/timezone a few times (e.g. users travelling cross-country). You can find that files get confusing dates (in the future, or simply not at the time you recall making them - which can be a problem for any software that uses dates in organising data).
To get sane time on your computer, you need to do three things:
* Set the UTC flag appropriately to match whether the hardware clock is running on UTC or localtime. * Set the timezone to match where you actually are. * Set the time correctly.
Letting your computer run an NTP, or other time keeping program, keeps the time running correctly with no further manual tweaking needed by you, so long as you did the prior three things correctly, and so long as there's nothing wrong with your hardware (such as the battery that the hardware clock depends on being okay). If the time keeps going wrong, software aborts/crashes/errors, then you need to check what's wrong.
On Tue, 2012-03-06 at 21:43 +1030, Tim wrote:
On Mon, 2012-03-05 at 09:36 -0600, Aaron Konstam wrote:
It is not hard and that is what I have been saying from the
beginning.
It's the opposite of what you've been saying, repeatedly. Geez.
You kept saying CUPS wouldn't work if UTC was set. That's wrong. You said that you'd set the clock correctly, that was wrong.
I don't know why I keep responding to you. I said that cups browsing does not work if you don't set UTC. Over and over that is what I said. Both the hardware and system clock were set correctly which was why it took so long to find the problem.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/06/2012 08:32 AM, Aaron Konstam wrote:
I don't know why I keep responding to you. I said that cups browsing does not work if you don't set UTC. Over and over that is what I said. Both the hardware and system clock were set correctly which was why it took so long to find the problem.
That is because the problem was with how you had the clock set. Cups browsing will work without setting UTC if the hardware clock is set to local time, and you have the system time zone set correctly. That way, the system clock is set correctly to UTC. You will run into problems if the hardware clock is set to local time, and you set UTC, or if the system time zone setting is wrong.
If you do not have the time configuration set properly, you will have problem with other programs besides CUPS. It is not a CUPS specific problem. It is a system configuration problem that affects CUPS browsing.
Mikkel - -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
(Top posting intentionally....)
Tim, please calm down. He did say that. And it was ambiguous. He meant the UTC check box on the dialog not the UTC timezone. Remember, they are two different values. It appears he was set to UTC in hardware but had not told the OS "hwclock" utility that the hardware clock was set to UTC. So it presumed local time and the rest is history.
We both misunderstood what he meant. Aaron and I have cleared it up in email. I'm sorry for the misunderstanding. Text is a one dimensional medium that breeds misunderstandings like this.
We've been arguing past each other. {o.o}
On 2012/03/06 03:13, Tim wrote:
On Mon, 2012-03-05 at 09:36 -0600, Aaron Konstam wrote:
It is not hard and that is what I have been saying from the beginning.
It's the opposite of what you've been saying, repeatedly. Geez.
You kept saying CUPS wouldn't work if UTC was set. That's wrong. You said that you'd set the clock correctly, that was wrong.
For your benefit, and anyone else following the thread, ignoring the hole you're digging and just discussing clocks and timekeeping...
The hardware clock is the one that actually runs on the motherboard, whether the computer is running or not (the BIOS battery also powers the clock). Gnome, and probably others, also call it the system clock. It's this clock that the UTC flag refers to.
The software clock is the one that that Linux is running when the OS is running. It's what you see whenever you see the time on the desktop. Generally, you set your timezone so that it shows local time. But, if you travel, for instance, you can change the timezone at will. That'll change the display of time, without actually changing the clock (the displayed time always been an offset from the clock, the offset being set by your choice of timezone).
The software clock is set going using the time from the hardware clock when you boot. And the hardware clock is tweaked to match the software clock when you shutdown. NTP, or other time-keeping software, generally just keeps the software clock running on time. Letting your OS update the hardware clock, to match, on shutdown. Though, NTP (or similar) could update both when they adjust the clock to be correct.
You can run the hardware clock on local or UTC.
The advantage of UTC, is that it's a consistent time, unmangled by daylight savings, and constant if you move across timezones. The displayed time is changed, not the clock.
But if you dual-boot with an OS that doesn't understand UTC, you can run the clock on localtime. The hardware clock will get changed as daylight savings starts and ends, which can cause some problems. Even more so if Linux correctly sets the time at the changeover, then Windows dumbly moves the time by an hour, just because of the date, without actually checking what time the clock was set to against a timeserver. More fun ensues if you reboot several times on that date, and Windows insists on doing it more than once (yes, I have seen that happen, it's stupid, and not supposed to happen, but can).
A hardware clock running on localtime will also change time if you change timezones and you reset the time to suit the new localtime (your change will change the hardware and software clocks). This can also cause a few nuisance problems if you do change the clock/timezone a few times (e.g. users travelling cross-country). You can find that files get confusing dates (in the future, or simply not at the time you recall making them - which can be a problem for any software that uses dates in organising data).
To get sane time on your computer, you need to do three things:
* Set the UTC flag appropriately to match whether the hardware clock is running on UTC or localtime. * Set the timezone to match where you actually are. * Set the time correctly.Letting your computer run an NTP, or other time keeping program, keeps the time running correctly with no further manual tweaking needed by you, so long as you did the prior three things correctly, and so long as there's nothing wrong with your hardware (such as the battery that the hardware clock depends on being okay). If the time keeps going wrong, software aborts/crashes/errors, then you need to check what's wrong.
On 2012/03/06 06:32, Aaron Konstam wrote:
On Tue, 2012-03-06 at 21:43 +1030, Tim wrote:
On Mon, 2012-03-05 at 09:36 -0600, Aaron Konstam wrote:
It is not hard and that is what I have been saying from the
beginning.
It's the opposite of what you've been saying, repeatedly. Geez.
You kept saying CUPS wouldn't work if UTC was set. That's wrong. You said that you'd set the clock correctly, that was wrong.
I don't know why I keep responding to you. I said that cups browsing does not work if you don't set UTC. Over and over that is what I said. Both the hardware and system clock were set correctly which was why it took so long to find the problem.
I of course read that as UTC TZ setting not the UTC check box on the system clock configuration futilty. (I edit adjtime by hand. I've been bit by GUI futilities too often. They are either "take over and screw up everthing" like the network configuration or (IMHO) inadequate to the job like the various firewall setup tools. Erm, I have an exotic firewall.)
{^_^}
On Tue, 2012-03-06 at 07:48 -0800, jdow wrote:
Tim, please calm down.
There's noting uncalm about my messages. If I were flaming him, or anyone else, there'd be no doubt about it. Though he is very close to being told RTFM.
My messages were blunt, using direct language, avoiding pussyfooting around, with emphasis placed around the important parts in the messages. i.e. If you don't read the whole message, as some are apt to do, hopefully they notice the emphasised parts.
On Tue, 2012-03-06 at 08:32 -0600, Aaron Konstam wrote:
I don't know why I keep responding to you. I said that cups browsing does not work if you don't set UTC. Over and over that is what I said.
I respond because that is wrong. It does work. CUPS browsing does work for people with UTC set and for people without UTC set. It works for me, it works for them.
You have a fault, it's not CUPS, and it's been pointed out where the problem actually is.
You are misdiagnosing cause and effect.
Both the hardware and system clock were set correctly which was why it took so long to find the problem.
According to what you have said, over numerous messages, you have *not* set your time correctly. You've misunderstood how the clocks should be configured. That is, the time the clock is set for, *and* *all* the parameters that describe to the system how the clock is set.
The simple proof is, if you have set the clock configuration correct, CUPS browsing will work.
Until you fix the actual problem, explained numerous times, you going to experience other problems. One of them is going to be hitting your head against other people who keep pointing out what you're doing wrong. It won't stop being wrong just because you don't like it.
And corrections aren't just made for your benefit, whether or not you accept them, they're also made for people researching the same problems, so they get the correct answers.
Go back and read the messages, mine and jdow's, read the documentation for setting the clock, and do it correctly. Do not assume that because your clock appears to show the correct time, according to you looking at it and comparing it with some non-computer clock.
NB: You can't just change the UTC setting on and off to test things (such as CUPS browsing). You have to set the time of the clock in accordance with the UTC setting, too.
Tim, please read fully and respond to the issues raised. You are falling into the imprecision of language trap, too.
On 2012/03/06 22:23, Tim wrote:
On Tue, 2012-03-06 at 08:32 -0600, Aaron Konstam wrote:
I don't know why I keep responding to you. I said that cups browsing does not work if you don't set UTC. Over and over that is what I said.
I respond because that is wrong. It does work. CUPS browsing does work for people with UTC set and for people without UTC set. It works for me, it works for them.
You have a fault, it's not CUPS, and it's been pointed out where the problem actually is.
You are misdiagnosing cause and effect.
Now you are being imprecise. Do you mean UTC time zone setting or UTC hardware clock setting with and without agreement between actual hardware clock setting and the UTC/LOCAL indication in /etc/adjtime (the check box on the time zone setting tool)?
This is known working: HARDWARE CHECKBOX TIMEZONE UTC UTC ANY LOCAL LOCAL ANY
These are known to break at least NTP: HARDWARE CHECKBOX TIMEZONE UTC LOCAL ANY LOCAL UTC ANY
Do all four work for cups? (I'd rather suspect it would unless there is an SSL connection being set or there is a sanity check in CUPS that does not seem to be published.)
Both the hardware and system clock were set correctly which was why it took so long to find the problem.
According to what you have said, over numerous messages, you have *not* set your time correctly. You've misunderstood how the clocks should be configured. That is, the time the clock is set for, *and* *all* the parameters that describe to the system how the clock is set.
You still ignore the correct two places that must agree for "everything" to work, the setting for the motherboard clock must be either UTC or local time and that information must be telegraphed to the OS with the value in the third line of "/etc/adjtime" which is apparently set by the appropriate checkbox on the time zone setting panel.
The simple proof is, if you have set the clock configuration correct, CUPS browsing will work.
He has said he made it correct. Apparently he meant making the motherboard clock and the checkbox agree. He was NOT talking about timezone setting.
Until you fix the actual problem, explained numerous times, you going to experience other problems. One of them is going to be hitting your head against other people who keep pointing out what you're doing wrong. It won't stop being wrong just because you don't like it.
And corrections aren't just made for your benefit, whether or not you accept them, they're also made for people researching the same problems, so they get the correct answers.
Go back and read the messages, mine and jdow's, read the documentation for setting the clock, and do it correctly. Do not assume that because your clock appears to show the correct time, according to you looking at it and comparing it with some non-computer clock.
NB: You can't just change the UTC setting on and off to test things (such as CUPS browsing). You have to set the time of the clock in accordance with the UTC setting, too.
At worst Aaron is guilty ONLY of imprecision in telling us what he had to do. We cleared this up in private emails.
{^_^}
Tim:
You are misdiagnosing cause and effect.
jdow:
Now you are being imprecise.
Cause and effect: Has CUPS stopped working because UTC is set? Is the time set wrong, and has CUPS stopped working because the time is set wrong? Is CUPS faulty? Has CUPS merely indicated that something else is wrong?
Misdiagnosis: CUPS browsing has stopped working. Hmm, I'll blame CUPS, and the UTC flag.
Correct diagnosis: CUPS browsing has stopped working. Changing UTC flag changes behaviour. Investigate whether I've got the clock set right. Does setting the time configuration cause CUPS to start working properly again? Yes, there's nothing wrong with CUPS, the fault was external.
Of course, if you don't understand how to properly set the clocks, you're going to paint yourself into a corner with the wrong diagnosis.
I've brought up CUPS again, as the original posting used it as the thing that noticed a problem, the original poster continually insisted CUPS had a problem (when it didn't), right up to the last post they responded to me on the list with.
Now onto discussing time, as time setting is the problem, CUPS was just the thing that brought the error to people's attention.
Do you mean UTC time zone setting
I'd never seen a UTC "timezone" setting, nor even heard of anyone referring to one. Likewise with Greenwich Mean Time. It's not a zone (GMT or UTC), as such, but a reference point. Only KDE seems to offer it as a choice, and it's a highly illogical choice. And I'd not mentioned, in any way, UTC as a timezone setting in prior messages.
If you live in Greenwich, do you run your clocks on GMT? No.
Can you live in UTC? No.
Does any country have a timezone which is exactly the same as UTC? (Same hours, no daylight savings / summertime.) I don't know. But, logically, and to prevent people doing silly things, you'd really want to call such a timezone by the name of the timezone (country/local).
Is there a practical point in having a computer show UTC as its displayed time. Yes, perhaps... Such as a server that people will manage from different international locations, and you want to try to force them to think about the time, and only have to do one calculation (there time against UTC, rather than figuring out the difference between two different timezones). But it's still a rather foolish and illogical thing to do. It's more pragmatic to set the timezone to where the server really is, and let the software manage that for you. I'd say that the only computer where it makes complete sense to have it say it lives in UTC, is *a* timeserver machine.
UTC hardware clock setting
The only option I have ever seen, on any release, other than checking out KDE recently, refers to a flag that say the hardware clock has been set to UTC, or not. And I've specifically been saying that the UTC flag refers to the hardware clock, and that it must reflect what the clock is set to, in my prior messages.
KDE's configurator seems rather poor in that it will let you set a real timezone, or a pseudo-UTC one, but has no additional flag to say how you want the hardware clock to be run. One has to presume that it automatically does something to make it correct when you set the clock (set the UTC flag, or set the hardware clock to match the time according to how the UTC flag was already set). If this doesn't actually work, though it appears to here, then that's a fault that can be raised (but with the KDE date and time tool, not a CUPS issue).
The Gnome tool, at least, lets you separately set whether the "system" (hardware) clock is set to local or UTC, set the date and clock to a specific date and time (or let a NTP server do so, for you), and set the timezone (with no obvious listing for an illogical UTC timezone that doesn't exist - there may be some timezones that are the same as UTC, but UTC isn't a timezone).
the UTC/LOCAL indication in /etc/adjtime (the check box on the time zone setting tool)?
I haven't mentioned the configuration file that it's set in. And if one is using one of the configuration GUIs to set the time, it hasn't really been important to the user how and where the setting is set. But anyway, set it by hand, or let the configurator set it for you, and the result's the same. *It* is the UTC flag.
This is known working: HARDWARE CHECKBOX TIMEZONE UTC UTC ANY LOCAL LOCAL ANY
The above two are the only way to correctly set the time.
These are known to break at least NTP: HARDWARE CHECKBOX TIMEZONE UTC LOCAL ANY LOCAL UTC ANY
The above two would always be incorrect, and I wouldn't expect anything to work reliably on such a system. I wouldn't really care if they didn't, because you shouldn't expect things to run properly under faulty conditions. I certainly expect anything that does date comparisons to mess up when the time is set wrong (all aspects of clock setting, not just that you might put in 4pm instead of 5pm).
Furthermore, I wouldn't be at all surprised that some services may well need restarting after changing the time. More so if you've happened to set the clock backwards.
You still ignore the correct two places that must agree for "everything" to work, the setting for the motherboard clock must be either UTC or local time and that information must be telegraphed to the OS with the value in the third line of "/etc/adjtime" which is apparently set by the appropriate checkbox on the time zone setting panel.
No, I haven't ignored that, at all. Haven't you read my messages? I've said, numerous times, that the UTC flag must reflect what the hardware clock is set to. I've explained it briefly, I've explained it in detail.
How and where that flag is being set isn't the issue. And unless someone mis-setting this specifically says whether they were using a GUI or hand-diddling configuration files, that's not a route I was going to go down.
My approach has always been to say *what* needs to be done, not *how* it should be done. e.g. If I were to tell someone to rename a file in their homespace, the last way I'd tell them to do that would be with a list of instructions for what commands to issue, or what steps to take with a certain file browser. I'd say, delete *this* file.
More so, for this reason, too. From my memory, it was /etc/localtime (linked to a timezone file, or not), and /etc/sysconfig/clock, but not /etc/adjtime, that were the configuration files for the hardware clock being set to localtime or GMT. And that /etc/adjtime was a file that NTP used for itself (and possibly a NTP equivalent replacement program).
If one's using a configuration tool to set these things, then it should handle all aspects, correctly, for you (set the clock to the right time, set the timezone you've picked, set the UTC flag if appropriate). The Gnome and KDE tools appear to be doing their jobs, here. No amount of fiddling with them has managed to break CUPS browsing, for me.
And that's why, all the way along, I've talked about setting the UTC/not-UTC flag for the hardware clock to match the hardware clock, *and* set the timezone correctly (two different things, mentioned separately).
The person with the problem should really state what they're using to set things. Then we can guide them through using that thing, rather than start them off using unfamiliar tools. Sure, get them to switch tools if you have to, as a second approach.
NB: I am also looking at Fedora 16, not just Fedora 9, I happen to be typing this email on a different computer (before someone jumps to the obvious wrong conclusion when they look at my email signature).
The simple proof is, if you have set the clock configuration correct, CUPS browsing will work.
He has said he made it correct. Apparently he meant making the motherboard clock and the checkbox agree. He was NOT talking about timezone setting.
I've barely mentioned timezone settings, in as much as setting it correctly, and certainly never mentioned attempting to set UTC as a timezone (it's not really what you'd call a timezone, anyway). I've been been discussing, over and over, UTC/not-UTC flag for the hardware clock.
Just where do you see an option that lets you set UTC as a "timezone"? KDE is the only place I've seen that. And I don't recall Aaron saying what he's using. And one really should (say what they're using) if one is using something other than the default GUI Fedora uses (Gnome), even if it is damn annoying (Gnome3, at least, in the latest incarnation).
At worst Aaron is guilty ONLY of imprecision in telling us what he had to do.
That's been obvious, for some time. It seems he doesn't understand the aspects that are involved in setting clocks, particularly in a something designed for an international environment.
We cleared this up in private emails.
Well, there's certainly been no indication that things have been cleared up in public emails. Quite the contrary. All the public emails have indicated that things are not right (i.e. insisting, right up to the last email, that setting UTC stops CUPS from functioning correctly).
If Aaron and you have been guilty of one thing, it's of *interpreting* my mails, instead of reading what they actually say. Do not take what I say to actually mean something else, nor to allude to something, take it as what it actually says.
I've explained the settings involved in the clocks, in depth. I've set them out in one-line descriptions. I've described and explained the different clocks. I've explained the pluses and minuses of setting your hardware clock on UTC or localtime. The information has been there in several different ways for someone to be able to grasp at least one of the explanations, or to ask for clarification.
If Aaron wants to persist in saying that CUPS browsing doesn't work when the clock is on UTC, then let him submit a bugzilla report. I think we know what the answer will be: No, CUPS works either way. You've got your clock configurations set wrong. Read the docs and set them right, or report a bug in the tool you used to set the time.
And no, I'm not setting out on a personal attack on Aaron. It's always been about fixing the right fault, and how the clocks should be set. If one wants to persist in arguing from the wrong end of the stick, whoever they are, they're going to keep getting told (by someone) that they're doing it wrong. This isn't Windows, you can't just keep rebooting until something different happens.
Sigh - twit filter.
I keep at least some timekeeping around here in UTC specifically for the unambiguous logging it provides. In the past I have maintained clock to UTC when I kept manual logs. I can see perfectly valid reasons to have a computer timezone set to UTC. But, I guess you're not only irritating and irritable but also unimaginative.
Have a nice day.
{+_+}
On 2012/03/07 23:50, Tim wrote:
Tim:
You are misdiagnosing cause and effect.
jdow:
Now you are being imprecise.
Cause and effect: Has CUPS stopped working because UTC is set? Is the time set wrong, and has CUPS stopped working because the time is set wrong? Is CUPS faulty? Has CUPS merely indicated that something else is wrong?
Misdiagnosis: CUPS browsing has stopped working. Hmm, I'll blame CUPS, and the UTC flag.
Correct diagnosis: CUPS browsing has stopped working. Changing UTC flag changes behaviour. Investigate whether I've got the clock set right. Does setting the time configuration cause CUPS to start working properly again? Yes, there's nothing wrong with CUPS, the fault was external.
Of course, if you don't understand how to properly set the clocks, you're going to paint yourself into a corner with the wrong diagnosis.
I've brought up CUPS again, as the original posting used it as the thing that noticed a problem, the original poster continually insisted CUPS had a problem (when it didn't), right up to the last post they responded to me on the list with.
Now onto discussing time, as time setting is the problem, CUPS was just the thing that brought the error to people's attention.
Do you mean UTC time zone setting
I'd never seen a UTC "timezone" setting, nor even heard of anyone referring to one. Likewise with Greenwich Mean Time. It's not a zone (GMT or UTC), as such, but a reference point. Only KDE seems to offer it as a choice, and it's a highly illogical choice. And I'd not mentioned, in any way, UTC as a timezone setting in prior messages.
If you live in Greenwich, do you run your clocks on GMT? No.
Can you live in UTC? No.
Does any country have a timezone which is exactly the same as UTC? (Same hours, no daylight savings / summertime.) I don't know. But, logically, and to prevent people doing silly things, you'd really want to call such a timezone by the name of the timezone (country/local).
Is there a practical point in having a computer show UTC as its displayed time. Yes, perhaps... Such as a server that people will manage from different international locations, and you want to try to force them to think about the time, and only have to do one calculation (there time against UTC, rather than figuring out the difference between two different timezones). But it's still a rather foolish and illogical thing to do. It's more pragmatic to set the timezone to where the server really is, and let the software manage that for you. I'd say that the only computer where it makes complete sense to have it say it lives in UTC, is *a* timeserver machine.
UTC hardware clock setting
The only option I have ever seen, on any release, other than checking out KDE recently, refers to a flag that say the hardware clock has been set to UTC, or not. And I've specifically been saying that the UTC flag refers to the hardware clock, and that it must reflect what the clock is set to, in my prior messages.
KDE's configurator seems rather poor in that it will let you set a real timezone, or a pseudo-UTC one, but has no additional flag to say how you want the hardware clock to be run. One has to presume that it automatically does something to make it correct when you set the clock (set the UTC flag, or set the hardware clock to match the time according to how the UTC flag was already set). If this doesn't actually work, though it appears to here, then that's a fault that can be raised (but with the KDE date and time tool, not a CUPS issue).
The Gnome tool, at least, lets you separately set whether the "system" (hardware) clock is set to local or UTC, set the date and clock to a specific date and time (or let a NTP server do so, for you), and set the timezone (with no obvious listing for an illogical UTC timezone that doesn't exist - there may be some timezones that are the same as UTC, but UTC isn't a timezone).
the UTC/LOCAL indication in /etc/adjtime (the check box on the time zone setting tool)?
I haven't mentioned the configuration file that it's set in. And if one is using one of the configuration GUIs to set the time, it hasn't really been important to the user how and where the setting is set. But anyway, set it by hand, or let the configurator set it for you, and the result's the same. *It* is the UTC flag.
This is known working: HARDWARE CHECKBOX TIMEZONE UTC UTC ANY LOCAL LOCAL ANY
The above two are the only way to correctly set the time.
These are known to break at least NTP: HARDWARE CHECKBOX TIMEZONE UTC LOCAL ANY LOCAL UTC ANY
The above two would always be incorrect, and I wouldn't expect anything to work reliably on such a system. I wouldn't really care if they didn't, because you shouldn't expect things to run properly under faulty conditions. I certainly expect anything that does date comparisons to mess up when the time is set wrong (all aspects of clock setting, not just that you might put in 4pm instead of 5pm).
Furthermore, I wouldn't be at all surprised that some services may well need restarting after changing the time. More so if you've happened to set the clock backwards.
You still ignore the correct two places that must agree for "everything" to work, the setting for the motherboard clock must be either UTC or local time and that information must be telegraphed to the OS with the value in the third line of "/etc/adjtime" which is apparently set by the appropriate checkbox on the time zone setting panel.
No, I haven't ignored that, at all. Haven't you read my messages? I've said, numerous times, that the UTC flag must reflect what the hardware clock is set to. I've explained it briefly, I've explained it in detail.
How and where that flag is being set isn't the issue. And unless someone mis-setting this specifically says whether they were using a GUI or hand-diddling configuration files, that's not a route I was going to go down.
My approach has always been to say *what* needs to be done, not *how* it should be done. e.g. If I were to tell someone to rename a file in their homespace, the last way I'd tell them to do that would be with a list of instructions for what commands to issue, or what steps to take with a certain file browser. I'd say, delete *this* file.
More so, for this reason, too. From my memory, it was /etc/localtime (linked to a timezone file, or not), and /etc/sysconfig/clock, but not /etc/adjtime, that were the configuration files for the hardware clock being set to localtime or GMT. And that /etc/adjtime was a file that NTP used for itself (and possibly a NTP equivalent replacement program).
If one's using a configuration tool to set these things, then it should handle all aspects, correctly, for you (set the clock to the right time, set the timezone you've picked, set the UTC flag if appropriate). The Gnome and KDE tools appear to be doing their jobs, here. No amount of fiddling with them has managed to break CUPS browsing, for me.
And that's why, all the way along, I've talked about setting the UTC/not-UTC flag for the hardware clock to match the hardware clock, *and* set the timezone correctly (two different things, mentioned separately).
The person with the problem should really state what they're using to set things. Then we can guide them through using that thing, rather than start them off using unfamiliar tools. Sure, get them to switch tools if you have to, as a second approach.
NB: I am also looking at Fedora 16, not just Fedora 9, I happen to be typing this email on a different computer (before someone jumps to the obvious wrong conclusion when they look at my email signature).
The simple proof is, if you have set the clock configuration correct, CUPS browsing will work.
He has said he made it correct. Apparently he meant making the motherboard clock and the checkbox agree. He was NOT talking about timezone setting.
I've barely mentioned timezone settings, in as much as setting it correctly, and certainly never mentioned attempting to set UTC as a timezone (it's not really what you'd call a timezone, anyway). I've been been discussing, over and over, UTC/not-UTC flag for the hardware clock.
Just where do you see an option that lets you set UTC as a "timezone"? KDE is the only place I've seen that. And I don't recall Aaron saying what he's using. And one really should (say what they're using) if one is using something other than the default GUI Fedora uses (Gnome), even if it is damn annoying (Gnome3, at least, in the latest incarnation).
At worst Aaron is guilty ONLY of imprecision in telling us what he had to do.
That's been obvious, for some time. It seems he doesn't understand the aspects that are involved in setting clocks, particularly in a something designed for an international environment.
We cleared this up in private emails.
Well, there's certainly been no indication that things have been cleared up in public emails. Quite the contrary. All the public emails have indicated that things are not right (i.e. insisting, right up to the last email, that setting UTC stops CUPS from functioning correctly).
If Aaron and you have been guilty of one thing, it's of *interpreting* my mails, instead of reading what they actually say. Do not take what I say to actually mean something else, nor to allude to something, take it as what it actually says.
I've explained the settings involved in the clocks, in depth. I've set them out in one-line descriptions. I've described and explained the different clocks. I've explained the pluses and minuses of setting your hardware clock on UTC or localtime. The information has been there in several different ways for someone to be able to grasp at least one of the explanations, or to ask for clarification.
If Aaron wants to persist in saying that CUPS browsing doesn't work when the clock is on UTC, then let him submit a bugzilla report. I think we know what the answer will be: No, CUPS works either way. You've got your clock configurations set wrong. Read the docs and set them right, or report a bug in the tool you used to set the time.
And no, I'm not setting out on a personal attack on Aaron. It's always been about fixing the right fault, and how the clocks should be set. If one wants to persist in arguing from the wrong end of the stick, whoever they are, they're going to keep getting told (by someone) that they're doing it wrong. This isn't Windows, you can't just keep rebooting until something different happens.
By the way, you are also ignorant. You can set your timezone to GMT, GMT plus and minus N hours, and UTC using the date and time facility.
{+_+}
On 2012/03/07 23:50, Tim wrote:
Tim:
You are misdiagnosing cause and effect.
jdow:
Now you are being imprecise.
Cause and effect: Has CUPS stopped working because UTC is set? Is the time set wrong, and has CUPS stopped working because the time is set wrong? Is CUPS faulty? Has CUPS merely indicated that something else is wrong?
Misdiagnosis: CUPS browsing has stopped working. Hmm, I'll blame CUPS, and the UTC flag.
Correct diagnosis: CUPS browsing has stopped working. Changing UTC flag changes behaviour. Investigate whether I've got the clock set right. Does setting the time configuration cause CUPS to start working properly again? Yes, there's nothing wrong with CUPS, the fault was external.
Of course, if you don't understand how to properly set the clocks, you're going to paint yourself into a corner with the wrong diagnosis.
I've brought up CUPS again, as the original posting used it as the thing that noticed a problem, the original poster continually insisted CUPS had a problem (when it didn't), right up to the last post they responded to me on the list with.
Now onto discussing time, as time setting is the problem, CUPS was just the thing that brought the error to people's attention.
Do you mean UTC time zone setting
I'd never seen a UTC "timezone" setting, nor even heard of anyone referring to one. Likewise with Greenwich Mean Time. It's not a zone (GMT or UTC), as such, but a reference point. Only KDE seems to offer it as a choice, and it's a highly illogical choice. And I'd not mentioned, in any way, UTC as a timezone setting in prior messages.
If you live in Greenwich, do you run your clocks on GMT? No.
Can you live in UTC? No.
Does any country have a timezone which is exactly the same as UTC? (Same hours, no daylight savings / summertime.) I don't know. But, logically, and to prevent people doing silly things, you'd really want to call such a timezone by the name of the timezone (country/local).
Is there a practical point in having a computer show UTC as its displayed time. Yes, perhaps... Such as a server that people will manage from different international locations, and you want to try to force them to think about the time, and only have to do one calculation (there time against UTC, rather than figuring out the difference between two different timezones). But it's still a rather foolish and illogical thing to do. It's more pragmatic to set the timezone to where the server really is, and let the software manage that for you. I'd say that the only computer where it makes complete sense to have it say it lives in UTC, is *a* timeserver machine.
UTC hardware clock setting
The only option I have ever seen, on any release, other than checking out KDE recently, refers to a flag that say the hardware clock has been set to UTC, or not. And I've specifically been saying that the UTC flag refers to the hardware clock, and that it must reflect what the clock is set to, in my prior messages.
KDE's configurator seems rather poor in that it will let you set a real timezone, or a pseudo-UTC one, but has no additional flag to say how you want the hardware clock to be run. One has to presume that it automatically does something to make it correct when you set the clock (set the UTC flag, or set the hardware clock to match the time according to how the UTC flag was already set). If this doesn't actually work, though it appears to here, then that's a fault that can be raised (but with the KDE date and time tool, not a CUPS issue).
The Gnome tool, at least, lets you separately set whether the "system" (hardware) clock is set to local or UTC, set the date and clock to a specific date and time (or let a NTP server do so, for you), and set the timezone (with no obvious listing for an illogical UTC timezone that doesn't exist - there may be some timezones that are the same as UTC, but UTC isn't a timezone).
the UTC/LOCAL indication in /etc/adjtime (the check box on the time zone setting tool)?
I haven't mentioned the configuration file that it's set in. And if one is using one of the configuration GUIs to set the time, it hasn't really been important to the user how and where the setting is set. But anyway, set it by hand, or let the configurator set it for you, and the result's the same. *It* is the UTC flag.
This is known working: HARDWARE CHECKBOX TIMEZONE UTC UTC ANY LOCAL LOCAL ANY
The above two are the only way to correctly set the time.
These are known to break at least NTP: HARDWARE CHECKBOX TIMEZONE UTC LOCAL ANY LOCAL UTC ANY
The above two would always be incorrect, and I wouldn't expect anything to work reliably on such a system. I wouldn't really care if they didn't, because you shouldn't expect things to run properly under faulty conditions. I certainly expect anything that does date comparisons to mess up when the time is set wrong (all aspects of clock setting, not just that you might put in 4pm instead of 5pm).
Furthermore, I wouldn't be at all surprised that some services may well need restarting after changing the time. More so if you've happened to set the clock backwards.
You still ignore the correct two places that must agree for "everything" to work, the setting for the motherboard clock must be either UTC or local time and that information must be telegraphed to the OS with the value in the third line of "/etc/adjtime" which is apparently set by the appropriate checkbox on the time zone setting panel.
No, I haven't ignored that, at all. Haven't you read my messages? I've said, numerous times, that the UTC flag must reflect what the hardware clock is set to. I've explained it briefly, I've explained it in detail.
How and where that flag is being set isn't the issue. And unless someone mis-setting this specifically says whether they were using a GUI or hand-diddling configuration files, that's not a route I was going to go down.
My approach has always been to say *what* needs to be done, not *how* it should be done. e.g. If I were to tell someone to rename a file in their homespace, the last way I'd tell them to do that would be with a list of instructions for what commands to issue, or what steps to take with a certain file browser. I'd say, delete *this* file.
More so, for this reason, too. From my memory, it was /etc/localtime (linked to a timezone file, or not), and /etc/sysconfig/clock, but not /etc/adjtime, that were the configuration files for the hardware clock being set to localtime or GMT. And that /etc/adjtime was a file that NTP used for itself (and possibly a NTP equivalent replacement program).
If one's using a configuration tool to set these things, then it should handle all aspects, correctly, for you (set the clock to the right time, set the timezone you've picked, set the UTC flag if appropriate). The Gnome and KDE tools appear to be doing their jobs, here. No amount of fiddling with them has managed to break CUPS browsing, for me.
And that's why, all the way along, I've talked about setting the UTC/not-UTC flag for the hardware clock to match the hardware clock, *and* set the timezone correctly (two different things, mentioned separately).
The person with the problem should really state what they're using to set things. Then we can guide them through using that thing, rather than start them off using unfamiliar tools. Sure, get them to switch tools if you have to, as a second approach.
NB: I am also looking at Fedora 16, not just Fedora 9, I happen to be typing this email on a different computer (before someone jumps to the obvious wrong conclusion when they look at my email signature).
The simple proof is, if you have set the clock configuration correct, CUPS browsing will work.
He has said he made it correct. Apparently he meant making the motherboard clock and the checkbox agree. He was NOT talking about timezone setting.
I've barely mentioned timezone settings, in as much as setting it correctly, and certainly never mentioned attempting to set UTC as a timezone (it's not really what you'd call a timezone, anyway). I've been been discussing, over and over, UTC/not-UTC flag for the hardware clock.
Just where do you see an option that lets you set UTC as a "timezone"? KDE is the only place I've seen that. And I don't recall Aaron saying what he's using. And one really should (say what they're using) if one is using something other than the default GUI Fedora uses (Gnome), even if it is damn annoying (Gnome3, at least, in the latest incarnation).
At worst Aaron is guilty ONLY of imprecision in telling us what he had to do.
That's been obvious, for some time. It seems he doesn't understand the aspects that are involved in setting clocks, particularly in a something designed for an international environment.
We cleared this up in private emails.
Well, there's certainly been no indication that things have been cleared up in public emails. Quite the contrary. All the public emails have indicated that things are not right (i.e. insisting, right up to the last email, that setting UTC stops CUPS from functioning correctly).
If Aaron and you have been guilty of one thing, it's of *interpreting* my mails, instead of reading what they actually say. Do not take what I say to actually mean something else, nor to allude to something, take it as what it actually says.
I've explained the settings involved in the clocks, in depth. I've set them out in one-line descriptions. I've described and explained the different clocks. I've explained the pluses and minuses of setting your hardware clock on UTC or localtime. The information has been there in several different ways for someone to be able to grasp at least one of the explanations, or to ask for clarification.
If Aaron wants to persist in saying that CUPS browsing doesn't work when the clock is on UTC, then let him submit a bugzilla report. I think we know what the answer will be: No, CUPS works either way. You've got your clock configurations set wrong. Read the docs and set them right, or report a bug in the tool you used to set the time.
And no, I'm not setting out on a personal attack on Aaron. It's always been about fixing the right fault, and how the clocks should be set. If one wants to persist in arguing from the wrong end of the stick, whoever they are, they're going to keep getting told (by someone) that they're doing it wrong. This isn't Windows, you can't just keep rebooting until something different happens.
On 03/08/2012 03:50 PM, Tim wrote:
I'd never seen a UTC "timezone" setting, nor even heard of anyone referring to one.
If you look at the headers of all messages coming *from* you to this list, you will see....
Received: from smtp-mm01.fedoraproject.org (smtp-mm01.fedoraproject.org [80.239.156.217]) by lists.fedoraproject.org (Postfix) with ESMTP id 03C3C40843 for users@lists.fedoraproject.org; Thu, 8 Mar 2012 07:51:05 +0000 (UTC) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by smtp-mm01.fedoraproject.org (Postfix) with ESMTP id 94E6CC0314 for users@lists.fedoraproject.org; Thu, 8 Mar 2012 07:51:04 +0000 (UTC)
So, you can no longer claim not to have see one.
TO NO-REPLY TIM WITH LOVE AND SQUALOR.
On Thu, 2012-03-08 at 18:20 +1030, Tim wrote:
Cause and effect: Has CUPS stopped working because UTC is set? Is the time set wrong, and has CUPS stopped working because the time is set wrong? Is CUPS faulty? Has CUPS merely indicated that something else is wrong?
Misdiagnosis: CUPS browsing has stopped working. Hmm, I'll blame CUPS, and the UTC flag.
Correct diagnosis: CUPS browsing has stopped working. Changing UTC flag changes behaviour. Investigate whether I've got the clock set right. Does setting the time configuration cause CUPS to start working properly again? Yes, there's nothing wrong with CUPS, the fault was external.
Of course, if you don't understand how to properly set the clocks, you're going to paint yourself into a corner with the wrong diagnosis.
I've brought up CUPS again, as the original posting used it as the thing that noticed a problem, the original poster continually insisted CUPS had a problem (when it didn't), right up to the last post they responded to me on the list with.
Now onto discussing time, as time setting is the problem, CUPS was just the thing that brought the error to people's attention.
Do you mean UTC time zone setting
I'd never seen a UTC "timezone" setting, nor even heard of anyone referring to one. Likewise with Greenwich Mean Time. It's not a zone (GMT or UTC), as such, but a reference point. Only KDE seems to offer it as a choice, and it's a highly illogical choice. And I'd not mentioned, in any way, UTC as a timezone setting in prior messages.
I wish you would stop posting this crap: 1. My clocks were set correctly, and I know how to set the clocks. 2. I never said the problem was a defect with CUPS. I just saw the problem with CUPS browsing. - 3. If you have never seen a UTC setting choice with time zone setting you have not been watching the screens you get when you install a Fedora 16 disk. Run system-config-date and choose the time zone option and you will see it.
But most of all go away attacking someone else secure behind your email no-reply screen.
On 2012/03/08 08:47, Aaron Konstam wrote:
TO NO-REPLY TIM WITH LOVE AND SQUALOR.
On Thu, 2012-03-08 at 18:20 +1030, Tim wrote:
Cause and effect: Has CUPS stopped working because UTC is set? Is the time set wrong, and has CUPS stopped working because the time is set wrong? Is CUPS faulty? Has CUPS merely indicated that something else is wrong?
Misdiagnosis: CUPS browsing has stopped working. Hmm, I'll blame CUPS, and the UTC flag.
Correct diagnosis: CUPS browsing has stopped working. Changing UTC flag changes behaviour. Investigate whether I've got the clock set right. Does setting the time configuration cause CUPS to start working properly again? Yes, there's nothing wrong with CUPS, the fault was external.
Of course, if you don't understand how to properly set the clocks, you're going to paint yourself into a corner with the wrong diagnosis.
I've brought up CUPS again, as the original posting used it as the thing that noticed a problem, the original poster continually insisted CUPS had a problem (when it didn't), right up to the last post they responded to me on the list with.
Now onto discussing time, as time setting is the problem, CUPS was just the thing that brought the error to people's attention.
Do you mean UTC time zone setting
I'd never seen a UTC "timezone" setting, nor even heard of anyone referring to one. Likewise with Greenwich Mean Time. It's not a zone (GMT or UTC), as such, but a reference point. Only KDE seems to offer it as a choice, and it's a highly illogical choice. And I'd not mentioned, in any way, UTC as a timezone setting in prior messages.
I wish you would stop posting this crap:
- My clocks were set correctly, and I know how to set the clocks.
- I never said the problem was a defect with CUPS. I just saw the
problem with CUPS browsing. - 3. If you have never seen a UTC setting choice with time zone setting you have not been watching the screens you get when you install a Fedora 16 disk. Run system-config-date and choose the time zone option and you will see it.
But most of all go away attacking someone else secure behind your email no-reply screen.
Don't bother to reply to the nurb. He's more akin to troll than help. Either that or he is more ignorant than anybody who claims knowledge should be.
{^_^}
On 2012/03/08 09:37, Joe Zeff wrote:
On 03/08/2012 08:47 AM, Aaron Konstam wrote:
But most of all go away attacking someone else secure behind your email no-reply screen.
That just stops you from taking this to private email and makes sure the discussion stays on the list.
Private email (and long time knowledge of Aaron) led to clearing up the ambiguities. I tried to explain it to the list answering Tim's emails. But he was knowledge resistant.
I'd been surprised Aaron had this particular problem and misunderstood his fix as he described it. Two emails cleared it right up. And I am indeed sorry I'd misunderstood him.
{^_-}
On Thu, 2012-03-08 at 09:37 -0800, Joe Zeff wrote:
On 03/08/2012 08:47 AM, Aaron Konstam wrote:
But most of all go away attacking someone else secure behind your email no-reply screen.
That just stops you from taking this to private email and makes sure the discussion stays on the list.
I understand but sometimes it would be useful to reach someone directly and not to take my frustration. Tim has every right to hide behind a no-reply address, but lets be clear he is hiding.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/08/2012 05:08 PM, Aaron Konstam wrote:
On Thu, 2012-03-08 at 09:37 -0800, Joe Zeff wrote:
That just stops you from taking this to private email and makes
sure the
discussion stays on the list.
I understand but sometimes it would be useful to reach someone directly and not to take my frustration. Tim has every right to hide behind a no-reply address, but lets be clear he is hiding.
Well, it that is hiding, then not posting your phone number as part of your signature is hiding as well. Personally, I just ignore most personal email from the list, unless something that catches my interest, or it is a slow day. The exception if people I have indicated that I welcome private messages from. Tim takes a more direct approach by indicating in he email address that he will ignore messages to the address he uses for posting to the list. I have considered it, but a kill filter works for my needs.
Mikkel - -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
On Thu, 2012-03-08 at 18:14 -0600, Mikkel L. Ellertson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/08/2012 05:08 PM, Aaron Konstam wrote:
On Thu, 2012-03-08 at 09:37 -0800, Joe Zeff wrote:
That just stops you from taking this to private email and makes
sure the
discussion stays on the list.
I understand but sometimes it would be useful to reach someone directly and not to take my frustration. Tim has every right to hide behind a no-reply address, but lets be clear he is hiding.
Well, it that is hiding, then not posting your phone number as part of your signature is hiding as well. Personally, I just ignore most personal email from the list, unless something that catches my interest, or it is a slow day. The exception if people I have indicated that I welcome private messages from. Tim takes a more direct approach by indicating in he email address that he will ignore messages to the address he uses for posting to the list. I have considered it, but a kill filter works for my needs.
Mikkel
Hiding you phone number reminds me of a story. The husband of our secretary died suddenly on the basketball court. So of course the authorities wanted to notify her. But her phone number was unlisted. We tried to think who would know her phone number. The departmewnt head knew her the number,but his number was unlisted.
Through this experience I have a prejudice against people who hide from others how to reach them. I think the chances that any would want to contact Tim for nephareous purposes very small and if they did they can be screened as you point out.
-
Aaron Konstam -
Daniel J Walsh -
Ed Greshko -
Genes MailLists -
jdow -
Joe Zeff -
Kevin Martin -
Marko Vojinovic -
Marvin Kosmal -
Mikkel L. Ellertson -
Patrick Dupre -
Reindl Harald -
Rick Stevens -
Tim