11:16 a.m.
i notice this since upgraded to Fedora 16 on mostly all
virtual machines while i have never seeen this with F15
how to track down and for which component file a bugreport?
EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr
systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in
der Zukunft.
systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[606]: /tmp: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der
Zukunft.
systemd-fsck[606]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[609]: /var/cache: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt
in der Zukunft.
systemd-fsck[609]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[611]: /Volumes/dune: Der Zeitpunkt des letzten Schreibens von SuperBlock
liegt in der Zukunft.
systemd-fsck[611]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[607]: /var/log: 85/65280 Dateien (24.7% nicht
zusammenh\xffffffc3\xffffffa4\xffffffa4ngend),
15985/261048 Bl\xffffffc3\xffffffb6\xffffffb6cke
12:13 p.m.
On 3/26/12 11:16 AM, Reindl Harald wrote:
i notice this since upgraded to Fedora 16 on mostly all
virtual machines while i have never seeen this with F15
how to track down and for which component file a bugreport?
EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr
systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in
der Zukunft.
systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[606]: /tmp: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der
Zukunft.
systemd-fsck[606]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[609]: /var/cache: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt
in der Zukunft.
systemd-fsck[609]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[611]: /Volumes/dune: Der Zeitpunkt des letzten Schreibens von SuperBlock
liegt in der Zukunft.
systemd-fsck[611]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
systemd-fsck[607]: /var/log: 85/65280 Dateien (24.7% nicht
zusammenh\xffffffc3\xffffffa4\xffffffa4ngend),
15985/261048 Bl\xffffffc3\xffffffb6\xffffffb6cke
N_("@S last write time is in the future.\n\t(by less than a day, "
"probably due to the hardware clock being incorrectly set). "),
These messages are from e2fsck...
Can you check whether the hardware clock is being moved back when you reboot?
-Eric
12:29 p.m.
On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
i notice this since upgraded to Fedora 16 on mostly all
virtual machines while i have never seeen this with F15
how to track down and for which component file a bugreport?
http://forums.fedoraforum.org/showthread.php?t=273727
-jef
12:34 p.m.
On Mon, Mar 26, 2012 at 9:29 AM, Jef Spaleta <jspaleta(a)gmail.com> wrote:
On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> i notice this since upgraded to Fedora 16 on mostly all
> virtual machines while i have never seeen this with F15
>
> how to track down and for which component file a bugreport?
http://forums.fedoraforum.org/showthread.php?t=273727
Bug report from 2009 concerning the very same issue.
https://bugzilla.redhat.com/show_bug.cgi?id=522969
You'll note that this is clearly a cyclic issue that comes and goes
across multiple release timescales...as far back as F9.
-jef
12:44 p.m.
Am 26.03.2012 19:34, schrieb Jef Spaleta:
On Mon, Mar 26, 2012 at 9:29 AM, Jef Spaleta
<jspaleta(a)gmail.com> wrote:
> On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
>> i notice this since upgraded to Fedora 16 on mostly all
>> virtual machines while i have never seeen this with F15
>>
>> how to track down and for which component file a bugreport?
>
> http://forums.fedoraforum.org/showthread.php?t=273727
Bug report from 2009 concerning the very same issue.
https://bugzilla.redhat.com/show_bug.cgi?id=522969
You'll note that this is clearly a cyclic issue that comes and goes
across multiple release timescales...as far back as F9
hmmm - which HWCLOCK clock?
we are speaking about VMware Machines on ESXi/vSphere
the problem with this issue is that it costs much time
at boot and wasted every systemd-improvement multiple
sync to HWCLOCK is also disabled in /etc/sysconfig/ntpd
since forever, yes there is not running chrony because
internal ntpd
cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g"
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no
1:22 p.m.
hmmm - which HWCLOCK clock?
we are speaking about VMware Machines on ESXi/vSphere
My best suggestion for you is to read the following document.
www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
and follow the best practises outlined there. You should have your
linux guests setting so system time is in UTC not local time. I would
suspect base on your symptoms you've got the wrong settings for the
guest operating system.
The issue here is long standing and predates systemd. You really do
need to follow the best practise recommendations set forth by vmware
when using their virtualization product.
-jef
1:42 p.m.
Am 26.03.2012 20:22, schrieb Jef Spaleta:
> hmmm - which HWCLOCK clock?
> we are speaking about VMware Machines on ESXi/vSphere
My best suggestion for you is to read the following document.
www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
and follow the best practises outlined there. You should have your
linux guests setting so system time is in UTC not local time. I would
suspect base on your symptoms you've got the wrong settings for the
guest operating system.
The issue here is long standing and predates systemd. You really do
need to follow the best practise recommendations set forth by vmware
when using their virtualization product.
the document above is hughe outdated
this machines are installed 2008 with F9 and since then
upgraded, the first time this ever happens is after
upgrade to F16
all guests are using two ntp-servers in the LAN and time
is stable as long no reboot is done proven by the following
output which is a script calling "date" per ssh on each guest
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
2:18 p.m.
Am 26.03.2012 21:11, schrieb Jef Spaleta:
On Mon, Mar 26, 2012 at 10:42 AM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> the document above is hughe outdated
Oh well. Nevermind then. Good luck correcting your configs
as you see in this output the configs are correct
this 19 guests are using the same ntp-servers (ntpd not chrony)
a script on one machine fires up "date" on each one
3 of them are currently F15, the rest F16
the last one is even connected over cable-internet
and sychronized to the host-ntpd which has the
same time sources as all other guests over openVPN
the problem happens only on F16 guests
so i see no time-config problem here
the 6 seconds difference are the ssh-logins on the machines
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
12:43 p.m.
On Mon, Mar 26, 2012 at 6:16 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
i notice this since upgraded to Fedora 16 on mostly all
virtual machines while i have never seeen this with F15
how to track down and for which component file a bugreport?
EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr
systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in
der Zukunft.
systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter
Hardware-Uhr) REPARIERT.
Compare the hardware clock and system time, you might be hitting
something like https://bugzilla.redhat.com/show_bug.cgi?id=750883 .
Mirek
2:51 p.m.
Reindl Harald wrote:
i notice this since upgraded to Fedora 16 on mostly all
virtual machines while i have never seeen this with F15
When did you see that? Yesterday? Might that be related to DST (Daylight
Savings Time, or Dumb Sucker Time as I like to call it ;-) )?
Kevin Kofler
3:17 p.m.
Am 26.03.2012 21:51, schrieb Kevin Kofler:
Reindl Harald wrote:
> i notice this since upgraded to Fedora 16 on mostly all
> virtual machines while i have never seeen this with F15
When did you see that? Yesterday? Might that be related to DST (Daylight
Savings Time, or Dumb Sucker Time as I like to call it ;-) )?
****argh**** some bastard script/update must have touched
"/etc/adjtime" because this was surely UTC and never
modified by me since summer 2008 :-(
[root@arrakis:~]$ cat /etc/adjtime
0.081032 1331163580 0.000000
1331163580
LOCAL
[root@arrakis:~]$ stat /etc/adjtime
Datei: „/etc/adjtime“
Größe: 46 Blöcke: 8 EA Block: 4096 reguläre Datei
Gerät: 811h/2065d Inode: 81938 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff : 2010-12-08 18:08:32.499797772 +0100
Modifiziert: 2012-03-08 00:39:41.499387577 +0100
Geändert : 2012-03-08 00:39:41.499387577 +0100
Geburt : -
_______________________________________
after sync this file from my workstation which is still UTC
* unlink /etc/localtime
* ln -s /usr/share/zoneinfo/Europe/Vienna /etc/localtime
this seems to be OK again, nevermind, i have seen this
not a single time since years :-( sorry for the noise
4428
days inactive
4428
days old
11 comments
5 participants
participants (5)
-
Eric Sandeen -
Jef Spaleta -
Kevin Kofler -
Miloslav Trmač -
Reindl Harald