[arch-dev-public] [testing] util-linux heads-up
A few remaining bugs in testing/util-linux at the moment: - shadow needs to be a dep - uuidd user's home is wrong These will be fixed in a -4 I'm rolling up. Note that testing users who have uuidd's home in /home/uuidd will want to fix this by simply running: usermod -d / uuidd One last bug about hwclock [1] is still outstanding, but I'm not able to reproduce it. I'm still unconvinced of whether it's a legit bug in hwclock or just something we need to fix in initscripts, but I've forwarded the bug onto the util-linux ML to see if I can get input from elsewhere. Cheers, Dave [1] https://bugs.archlinux.org/task/31416
Am 08.09.2012 15:33, schrieb Dave Reisner:
A few remaining bugs in testing/util-linux at the moment:
- shadow needs to be a dep - uuidd user's home is wrong
These will be fixed in a -4 I'm rolling up. Note that testing users who have uuidd's home in /home/uuidd will want to fix this by simply running:
usermod -d / uuidd
One last bug about hwclock [1] is still outstanding, but I'm not able to reproduce it. I'm still unconvinced of whether it's a legit bug in hwclock or just something we need to fix in initscripts, but I've forwarded the bug onto the util-linux ML to see if I can get input from elsewhere.
Cheers, Dave
Shouldn't uuidd user have the same uid/gid on all systems? greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, Sep 09, 2012 at 10:09:45AM +0200, Tobias Powalowski wrote:
Am 08.09.2012 15:33, schrieb Dave Reisner:
A few remaining bugs in testing/util-linux at the moment:
- shadow needs to be a dep - uuidd user's home is wrong
These will be fixed in a -4 I'm rolling up. Note that testing users who have uuidd's home in /home/uuidd will want to fix this by simply running:
usermod -d / uuidd
One last bug about hwclock [1] is still outstanding, but I'm not able to reproduce it. I'm still unconvinced of whether it's a legit bug in hwclock or just something we need to fix in initscripts, but I've forwarded the bug onto the util-linux ML to see if I can get input from elsewhere.
Cheers, Dave
Shouldn't uuidd user have the same uid/gid on all systems?
greetings tpowa
Not really important. It's used for creating /run/uuidd and running the daemon. Whether this is picked by the system or some curated number that we pick makes little difference -- we won't be shipping around files that are owned by this user.
On 9 September 2012 15:17, Dave Reisner <d@falconindy.com> wrote:
On Sun, Sep 09, 2012 at 10:09:45AM +0200, Tobias Powalowski wrote:
Am 08.09.2012 15:33, schrieb Dave Reisner:
A few remaining bugs in testing/util-linux at the moment:
- shadow needs to be a dep - uuidd user's home is wrong
These will be fixed in a -4 I'm rolling up. Note that testing users who have uuidd's home in /home/uuidd will want to fix this by simply running:
usermod -d / uuidd
One last bug about hwclock [1] is still outstanding, but I'm not able to reproduce it. I'm still unconvinced of whether it's a legit bug in hwclock or just something we need to fix in initscripts, but I've forwarded the bug onto the util-linux ML to see if I can get input from elsewhere.
Cheers, Dave
Shouldn't uuidd user have the same uid/gid on all systems?
greetings tpowa
Not really important. It's used for creating /run/uuidd and running the daemon. Whether this is picked by the system or some curated number that we pick makes little difference -- we won't be shipping around files that are owned by this user.
In my opinion the fixed uid/gid would be better for the consistency sake (ie. it's done with others too), but I don't believe this alone justifies rebuilding package with just this fix. BTW: the FS#31416 got somehow fixed by enabling hwclock daemon for one boot (see comment at the bug report). I think util-linux -4 is good-to-go after the rc.sysinig is fixed for the new hwclock behaviour. Have a nice day, Lukas
On 8 September 2012 15:33, Dave Reisner <d@falconindy.com> wrote:
One last bug about hwclock [1] is still outstanding, but I'm not able to reproduce it. I'm still unconvinced of whether it's a legit bug in hwclock or just something we need to fix in initscripts, but I've forwarded the bug onto the util-linux ML to see if I can get input from elsewhere.
Cheers, Dave
Falconindy, you're going to kill me. Today I realized that I unset HARDWARECLOCK in rc.conf yesterday, which made it look like it works due to the use of hwclock daemon. Instead the hwclock wasn't run during startup at all. So the problem is still here. This time, however, I have a fix for that. It works, although I'm not sure whether it's a correct fix. There's some strange problem with "hwclock --systz" which looks like it doesn't set the time zone correctly, but it can be fixed by using "hwclock --hctosys" instead (see attached patch). I just found out about the --debug switch to hwclock at it does print some interesting info (the output is at the end of this email). Note the "Calling settimeofday" output, especially the "tz.tz_minuteswest". This is completely utterly wrong according to "man 2 settimeofday": Under Linux there are some peculiar "warp clock" semantics associated with the settimeofday() system call if on the very first call (after booting) that has a non-NULL tz argument, the tv argument is NULL and the tz_minuteswest field is nonzero. (The tz_dsttime field should be zero for this case.) In such a case it is assumed that the CMOS clock is on local time, and that it has to be incremented by this amount to get UTC system time. No doubt it is a bad idea to use this feature. I have CMOS clock set to UTC. However, according to the documentation the hwclock causes system to think it uses local time. If I set tz_minuteswest in that call to zero manually, the error during mount disappears. However the "date" output is still incorrect. So I tried to change the settimeofday call according to the documentation. I other words, I forced tz_minuteswest to 0 in all calls in hwclock.c. And (surprisingly) it fixed this problem. To sum, what I think happens here: prerequisites: * CMOS (hardware) time set to UTC * Time zone different from UTC, in my case its "Europe/Prague" (UTC + 2 hours) what is the problem: 1. hwclock calls settimeofday with tz_minuteswest = -120 2. due to tz_minuteswest being non-zero, kernel thinks the hardware clock is in local time and thus it sets its clock to UTC - 2 hours 3. a) the wrong kernel clock causes the "Superblock last write time is in the future." warnings. b) and because kernel clock is UTC - 2, date shows "kernel time + 2" which resuts in showing the time for UTC-2+2, which is equal to UTC time. what should happen: 1. hwclock calls settimeofday with tz_minuteswest = 0 2. kernel knows the hardware clock is in UTC, and it sets its clock appropriately (ie to UTC) 3. now that the kernel clock is in UTC, date shows correctly UTC+2, ie. localtime Broken --------- # hwclock --utc --noadjfile Using /dev interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/09/10 06:19:46 Hw clock time : 2012/09/10 06:19:46 = 1347257986 seconds since 1969 Mon Sep 10 08:19:46 2012 -0.234800 seconds # date output Mon Sep 10 08:19:45 CEST 2012 # hwclock --systz --debug hwclock from util-linux 2.22 Last drift adjustment done at 1347212233 seconds after 1969 Last calibration done at 1347212233 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Current system time: 1347257985 = 2012/09/10 06:19:45 Calling settimeofday: UTC: 2012/09/10 06:19:45 tv.tv_sec = 1347257985, tv.tv_usec = 784261 tz.tz_minuteswest = -120 # date output Mon Sep 10 06:19:45 CEST 2012 Working ---------- #hwclock --utc --noadjfile Using /dev interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/09/10 06:22:24 Hw clock time : 2012/09/10 06:22:24 = 1347258144 seconds since 1969 Mon Sep 10 08:22:24 2012 -0.453554 seconds # date output Mon Sep 10 08:22:23 CEST 2012 # hwclock --hctosys --debug hwclock from util-linux 2.22 Using /dev interface to clock. Last drift adjustment done at 1347212233 seconds after 1969 Last calibration done at 1347212233 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/09/10 06:22:25 Hw clock time : 2012/09/10 06:22:25 = 1347258145 seconds since 1969 Calling settimeofday: tv.tv_sec = 1347258145, tv.tv_usec = 0 tz.tz_minuteswest = -120 # date Mon Sep 10 08:22:25 CEST 2012 /me hides Lukas
On Sep 10, 2012 3:48 AM, "Lukas Jirkovsky" <l.jirkovsky@gmail.com> wrote:
On 8 September 2012 15:33, Dave Reisner <d@falconindy.com> wrote:
One last bug about hwclock [1] is still outstanding, but I'm not able to reproduce it. I'm still unconvinced of whether it's a legit bug in hwclock or just something we need to fix in initscripts, but I've forwarded the bug onto the util-linux ML to see if I can get input from elsewhere.
Cheers, Dave
Falconindy, you're going to kill me.
Yup. Today I realized that I unset
HARDWARECLOCK in rc.conf yesterday, which made it look like it works due to the use of hwclock daemon. Instead the hwclock wasn't run during startup at all. So the problem is still here.
This time, however, I have a fix for that. It works, although I'm not sure whether it's a correct fix.
Its not. There's some strange problem with
"hwclock --systz" which looks like it doesn't set the time zone correctly, but it can be fixed by using "hwclock --hctosys" instead (see attached patch).
I just found out about the --debug switch to hwclock at it does print some interesting info (the output is at the end of this email). Note the "Calling settimeofday" output, especially the "tz.tz_minuteswest". This is completely utterly wrong according to "man 2 settimeofday":
Under Linux there are some peculiar "warp clock" semantics associated with the settimeofday() system call if on the very first call (after booting) that has a non-NULL tz argument, the tv argument is NULL and the tz_minuteswest field is nonzero. (The tz_dsttime field should be zero for this case.) In such a case it is assumed that the CMOS clock is on local time, and that it has to be incremented by this amount to get UTC system time. No doubt it is a bad idea to use this feature.
I have CMOS clock set to UTC. However, according to the documentation the hwclock causes system to think it uses local time. If I set tz_minuteswest in that call to zero manually, the error during mount disappears. However the "date" output is still incorrect. So I tried to change the settimeofday call according to the documentation. I other words, I forced tz_minuteswest to 0 in all calls in hwclock.c. And (surprisingly) it fixed this problem.
Very surprising that it does anything at all. I've asked upstream about this and I've started looking at what the kernel does. I'm starting to wonder if calling hwclock with --systz is ever a good idea when the user wants to use the hwclock in UTC. Here's what I think: If UTC: do nothing. Do absolutely nothing at all. The hwclock maintains itself from the bios clock and user land tools read TZ from /etc/localtime or the environment. Everything should just work. Should... If localtime: call hwclock --systz. This is the _one_ chance you get to do any sort of warp adjustment and it must be done on the very first call of settimeofday(). I don't believe calling hwclock with --hctosys is ever wanted on bootup. Im on a bus right now and haven't tried this, so grain of salt and all that. But, evidence points to this being the right thing to do.
To sum, what I think happens here: prerequisites: * CMOS (hardware) time set to UTC * Time zone different from UTC, in my case its "Europe/Prague" (UTC + 2
hours)
what is the problem: 1. hwclock calls settimeofday with tz_minuteswest = -120 2. due to tz_minuteswest being non-zero, kernel thinks the hardware clock is in local time and thus it sets its clock to UTC - 2 hours 3. a) the wrong kernel clock causes the "Superblock last write time is in the future." warnings. b) and because kernel clock is UTC - 2, date shows "kernel time + 2" which resuts in showing the time for UTC-2+2, which is equal to UTC time.
what should happen: 1. hwclock calls settimeofday with tz_minuteswest = 0 2. kernel knows the hardware clock is in UTC, and it sets its clock appropriately (ie to UTC) 3. now that the kernel clock is in UTC, date shows correctly UTC+2, ie. localtime
Broken --------- # hwclock --utc --noadjfile Using /dev interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/09/10 06:19:46 Hw clock time : 2012/09/10 06:19:46 = 1347257986 seconds since 1969 Mon Sep 10 08:19:46 2012 -0.234800 seconds
# date output Mon Sep 10 08:19:45 CEST 2012
# hwclock --systz --debug hwclock from util-linux 2.22 Last drift adjustment done at 1347212233 seconds after 1969 Last calibration done at 1347212233 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Current system time: 1347257985 = 2012/09/10 06:19:45 Calling settimeofday: UTC: 2012/09/10 06:19:45 tv.tv_sec = 1347257985, tv.tv_usec = 784261 tz.tz_minuteswest = -120
# date output Mon Sep 10 06:19:45 CEST 2012
Working ---------- #hwclock --utc --noadjfile Using /dev interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/09/10 06:22:24 Hw clock time : 2012/09/10 06:22:24 = 1347258144 seconds since 1969 Mon Sep 10 08:22:24 2012 -0.453554 seconds
# date output Mon Sep 10 08:22:23 CEST 2012
# hwclock --hctosys --debug hwclock from util-linux 2.22 Using /dev interface to clock. Last drift adjustment done at 1347212233 seconds after 1969 Last calibration done at 1347212233 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/09/10 06:22:25 Hw clock time : 2012/09/10 06:22:25 = 1347258145 seconds since 1969 Calling settimeofday: tv.tv_sec = 1347258145, tv.tv_usec = 0 tz.tz_minuteswest = -120
# date Mon Sep 10 08:22:25 CEST 2012
/me hides
Lukas
participants (3)
-
Dave Reisner
-
Lukas Jirkovsky
-
Tobias Powalowski