Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
On 01/03/11 18:55, Felix Miata wrote:
Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
you can use the date command.
Usage: date [OPTION]... [+FORMAT] or: date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]] Display the current time in the given FORMAT, or set the system date.
Paolo
On 2011/01/03 18:33 (GMT-0500) Paolo Galtieri composed:
On 01/03/11 18:55, Felix Miata wrote:
Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
you can use the date command.
As it stands now I must do that every boot, which is what I don't want to keep needing to do.
set date != config date
Usage: date [OPTION]... [+FORMAT] or: date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]] Display the current time in the given FORMAT, or set the system date.
What cmdline (not GUI) tool is used to config(ure) ntpd (aka "config date")?
On 01/03/11 19:43, Felix Miata wrote:
On 2011/01/03 18:33 (GMT-0500) Paolo Galtieri composed:
On 01/03/11 18:55, Felix Miata wrote:
Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
you can use the date command.
As it stands now I must do that every boot, which is what I don't want to keep needing to do.
set date != config date
Usage: date [OPTION]... [+FORMAT] or: date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]] Display the current time in the given FORMAT, or set the system date.
What cmdline (not GUI) tool is used to config(ure) ntpd (aka "config date")?
you can run
chkconfig ntpd on
This configures ntpd to run as a service.
Then run
service ntpd start
to start it. When you reboot the system ntpd will run and as long as you have internet connectivity your date will be set. You can run tzselect to set timezone info.
Paolo
On Mon, 2011-01-03 at 18:43 -0500, Felix Miata wrote:
On 2011/01/03 18:33 (GMT-0500) Paolo Galtieri composed:
On 01/03/11 18:55, Felix Miata wrote:
Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
you can use the date command.
As it stands now I must do that every boot, which is what I don't want to keep needing to do.
set date != config date
---- date -s "January 3 2011 19:43:00" #something like this... untested hwclock --systohc
Craig
On Mon, Jan 03, 2011 at 05:55:29PM -0500, Felix Miata wrote:
Is there another cmdline date configuration tool?
system-config-date is doing more than just setting a time zone but if you want to do only that then there are many such tools and one possible is known as '/bin/cp'. Just copy a desired zone file from /usr/share/zoneinfo/ to /etc/localtime. Remaining functionality of system-config-date is covered by 'date' and 'chkconfig'.
Michal
On 2011/01/03 18:18 (GMT-0700) Michal Jaegermann composed:
Felix Miata wrote:
Is there another cmdline date configuration tool?
system-config-date is doing more than just setting a time zone but if you want to do only that then there are many such tools and one possible is known as '/bin/cp'. Just copy a desired zone file from /usr/share/zoneinfo/ to /etc/localtime. Remaining functionality of system-config-date is covered by 'date' and 'chkconfig'.
Maybe the problem is that systemd doesn't know about any of this. According to chkconfig, ntpd is on, and according to diff, /etc/localtime and /usr/share/zoneinfo/US/Eastern contain entirely identical bits. Yet, each Rawhide boot produces filesystem mount times and clock time off by the TZ offset.
On Mon, Jan 03, 2011 at 10:53:04PM -0500, Felix Miata wrote:
Maybe the problem is that systemd doesn't know about any of this.
I do not think that systemd is supposed to know anything about your time zone; I may miss something.
According to chkconfig, ntpd is on,
ntpd is designed to give up if it has to compensate for to big time differences although it is often configured to "jump" once at the very start. BTW - with an unstable reference (due to a crazy network latencies, for example) chrony does much better job.
and according to diff, /etc/localtime and /usr/share/zoneinfo/US/Eastern contain entirely identical bits. Yet, each Rawhide boot produces filesystem mount times and clock time off by the TZ offset.
Do you have TZ set in an enviroment? You should not do that with a proper content of /etc/localtime. Anyway, I do not recall such issue in those bits of rawhide I have now on hands.
Michal
On 2011/01/04 00:09 (GMT-0500) Michal Jaegermann composed:
On Mon, Jan 03, 2011 at 10:53:04PM -0500, Felix Miata wrote:
Maybe the problem is that systemd doesn't know about any of this.
I do not think that systemd is supposed to know anything about your time zone; I may miss something.
What I was supposing was that something in the sysvinit/upstart/systemd conversion process was resulting in ntpd not actually getting started.
According to chkconfig, ntpd is on,
ntpd is designed to give up if it has to compensate for to big time differences although it is often configured to "jump" once at the very start. BTW - with an unstable reference (due to a crazy network latencies, for example) chrony does much better job.
This is actually two multiboot systems, one currently only with DOS, openSUSE 11.3, openSUSE Factory, Fedora 14, and Rawhide (the other with more than a dozen installed OSes). The two latter OS were freshly installed yesterday, as there was only Rawhide upgraded from F14 previously, and it refused to give me gettys when the upgrade finished. Because I could find no installation files for Rawhide, I did a fresh minimal 14 install (which BTW had no problem figuring out my TZ on its own), then added various KDE and additional networking, then upgraded to Rawhide. DOS and the SUSE's give me no clock problems, while both Fedoras do.
and according to diff, /etc/localtime and /usr/share/zoneinfo/US/Eastern contain entirely identical bits. Yet, each Rawhide boot produces filesystem mount times and clock time off by the TZ offset.
Do you have TZ set in an enviroment? You should not do that with a
If there was, it would have been put there by Anaconda, not me, but I don't see one.
proper content of /etc/localtime. Anyway, I do not recall such issue in those bits of rawhide I have now on hands.
How & when was that installation created? When will a netboot installation kernel/initrd set be available for Rawhide again?
On 01/03/2011 05:55 PM, Felix Miata wrote:
Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
There was a problem with systemd not enabling hwclock-load.service a few weeks ago. That said, if your system (rawhide?) is up-to-date, then the problem is elsewhere. See https://bugzilla.redhat.com/show_bug.cgi?id=656747 especially comment 5.
On 2011/01/04 09:02 (GMT-0500) Clyde E. Kunkel composed:
On 01/03/2011 05:55 PM, Felix Miata wrote:
Is there another cmdline date configuration tool? system-config-date seems to require X (depends on gnome-python2-canvas; RuntimeError: could not open display), which ATM will not start on my system, while each boot corrupts the time in the amount of the TZ offset.
There was a problem with systemd not enabling hwclock-load.service a few weeks ago. That said, if your system (rawhide?) is up-to-date, then the problem is elsewhere. See https://bugzilla.redhat.com/show_bug.cgi?id=656747 especially comment 5.
The way I read that bug, my problem on first glance seemed opposite:
current UTC: 14:29 local time: 09:29 Rawhide time: 04:27
Nevertheless, systemctl enable hwclock-load.service fixed it. Thanks for the pointer to that bug, which long ago as it was marked fixed, I would have thought would have been inapplicable. I wonder if something since has inadvertently undone that fix, or a refinement of it is necessary for upgrades from F14 to Rawhide?
On 01/04/2011 09:37 AM, Felix Miata wrote:
<snip> The way I read that bug, my problem on first glance seemed opposite:
current UTC: 14:29 local time: 09:29 Rawhide time: 04:27
Nevertheless, systemctl enable hwclock-load.service fixed it. Thanks for the pointer to that bug, which long ago as it was marked fixed, I would have thought would have been inapplicable. I wonder if something since has inadvertently undone that fix, or a refinement of it is necessary for upgrades from F14 to Rawhide?
Hmmm...well, your differences are all nearly 5 hrs, so may be same problem. The bz seems to say problem was on "package install." Maybe on an upgrade it isn't fixed. Oh well, all is well that ends well.
Regards, OldFart
-
Clyde E. Kunkel -
Craig White -
Felix Miata -
Michal Jaegermann -
Paolo Galtieri