hwclock's ADJPATH

hwclock's ADJPATH

[Tom Gundersen]

Hi guys,

Sami's latest hwclock patches reminded me of something I have long
been meaning to bring up:

I have been unable to figure out how to use hwclock in such a way that
we (Arch Linux) can set a reasonable ADJPATH.

These are the constraints we have:

/etc could possibly be mounted read-only.
/var might not be mounted at early boot.

This is the usage we have (in the cases where a machine does not use ntp):

1) At early boot we call "hwclock --systz", which require us to read
ADJPATH to determine if RTC is in UTC/LOCAL (so ADJTIME can not be in
/var).
2) From time to time (typically at shutdown), we call "hwclock
--adjust", which require us to write to ADJPATH (so ADJPATH can not be
in /etc).
3) The administrator should manually call "hwclock --set" and make
sure ADJPATH is writeable when this is done (for this, ADJPATH could
be either in /etc or /var).



Are these reasonable constraints and a reasonable usecase? If so, it
seems to me that the only way to make this work is to split ADJPATH
into two files, /etc/adjtime containing UTC/LOCAL and
/var/lib/hwclock/adjtime containing everything else. Or am I missing
something?

Cheers,

Tom

Re: hwclock's ADJPATH

[Karel Zak]

On Tue, Jul 26, 2011 at 02:06:20AM +0200, Tom Gundersen wrote:
> These are the constraints we have:
> 
> /etc could possibly be mounted read-only.
> /var might not be mounted at early boot.
> 
> This is the usage we have (in the cases where a machine does not use ntp):
> 
> 1) At early boot we call "hwclock --systz", which require us to read
> ADJPATH to determine if RTC is in UTC/LOCAL (so ADJTIME can not be in
> /var).
>
> 2) From time to time (typically at shutdown), we call "hwclock
> --adjust", which require us to write to ADJPATH (so ADJPATH can not be
> in /etc).
> 3) The administrator should manually call "hwclock --set" and make
> sure ADJPATH is writeable when this is done (for this, ADJPATH could
> be either in /etc or /var).
> 
> 
> 
> Are these reasonable constraints and a reasonable usecase? If so, it
> seems to me that the only way to make this work is to split ADJPATH
> into two files, /etc/adjtime containing UTC/LOCAL and
> /var/lib/hwclock/adjtime containing everything else. Or am I missing
> something?

 You're probably right. Note that you can use:

    hwclock --systz $(CLOCK_ZONE_OPTION)

 where the CLOCK_ZONE_OPTION will be --utc or --local from some extra
 file (e.g. /etc/sysconfig/hwclock), then /etc/adjtime will be
 unnecessary for --systz.

 And for hwclock --set or --adjust you can use
 --adjfile=/var/lib/hwclock/adjtime or so.


 Note that systemd will probably not call hwclock at all, it will read
 only /etc/adjtime to get UTC/LOCAL setting and call settimeofday().
 The --adjust is somehow unexpected on systems with systemd.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com