Fixes the following warning:
sys-utils/hwclock.c: In function 'manipulate_epoch':
sys-utils/hwclock.c:1465:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (epoch_opt == -1)
Full build log available on:
https://buildd.debian.org/status/fetch.php?pkg=util-linux&arch=alpha&ver=2.26.2-9&stamp=1440078034
Detected by/via:
https://qa.debian.org/bls/packages/u/util-linux.html
Please note that this has never actually been (build-)tested on alpha,
but should hopefully resolve the warning. Note also that limits.h is
already included.
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Fortunately very few people are crazy enough to install hwclock as
setuid. Some comments in code and unfortunately also man page
advertising that setuid is no problem. That's pretty stupid promise.
The code quality is poor and it's obviously not designed to be secure
(things like popen() without drop privileges, etc.).
This patch removes all notes about "setuid support" and for sure
disable hwclock execution for non-root users.
Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786804
Signed-off-by: Karel Zak <kzak@redhat.com>
This allows using hwclock -c in automated test scripts that parse
its output line-by-line. The standard output is flushed before
each 10 second delay.
Signed-off-by: Alexey Galakhov <agalakhov@gmail.com>
commit d53f8ecfbf
introduced the TZUTC environment variable to
facilitate use of the zoneinfo 'right' database.
This was incorrect. Either the TZDIR environment
variable should be used or a system-wide
configuration for the 'right' database should be
used.
See hwclock(8) POSIX vs 'RIGHT' for more details.
TZUTC was undocumented and should be safe to remove.
The commit also caused a regression when using
musl libc, because when TZUTC is unset getenv()
returns a NULL pointer.
Reported-by: Isaac Dunham <ibid.ag@gmail.com>
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Increased the precision in debug output showing
the clock drift and the time lapsed.
Showing a clock drift of 0.0 while giving a value that the
drift factor was adjusted by makes no sense.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
As said in include/c.h the usleep() is marked as obsolete, so do the same
that most of the other util-linux calls do with this interface.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The old behavior when hwclock was unable to access
the rtc device was to fallback to direct ISA I/O.
This was sometimes allowing two processes to access
the Hardware Clock at the same time and hanging the
system. This is the reason the rtc device driver
only allows one process to open it.
Now hwclock defaults to using the rtc device and only
uses direct ISA when that option is given.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
We have enabled CMOS also for x86_64, but it should be available only
if --directisa is explicitly specified.
Signed-off-by: Karel Zak <kzak@redhat.com>
Hwclock's default timescale was changed to UTC in:
commit 7894bf0f08
Date: Mon Feb 21 13:27:07 2011 +0000
This change was incomplete.
With no /etc/adjtime file the current behavior is:
hwclock --utc --adjust #Creates a UTC file.
hwclock --localtime --adjust #File is not created.
That is the opposite of what UTC default should do.
With this patch the behavior is:
hwclock --utc --adjust #File is not created.
hwclock --localtime --adjust #Creates a LOCAL file.
'Creates a xxxx file' means: An /etc/adjtime file
is created with zero for all parameters except the
Hardware Clock's timescale field, which is set to
the value indicated by xxxx.
The second item missed in the patch was a test in
the save_adjtime() function that defaults to LOCAL.
Theoretically we cannot get to the save function
without having a value set for adjtime.local_utc,
but the test is there so it needs be correct.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
This adds a concise description of a tool to its usage text.
A first form of this patch was proposed by Steven Honeyman
(see http://www.spinics.net/lists/util-linux-ng/msg09994.html).
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
To facilitate the calculation of 'cold' vs 'warm' Hardware Clock drift
factor the limit on the update period needs to be less than 8 hours.
4 hours should be enough drift to allow calculations that are not
grossly out of range.
For example, with a workstation that is shutdown every night the cold
drift factor can be significantly different than a drift factor based on
a 24 hour period.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
There are cases where we need to refresh the
timestamps in the adjtime file without updating the
drift factor.
For example, with ntpd and an Eleven Minute Mode
kernel, we need to call systohc at shutdown to
facilitate drift correction. With the current
behavior hwclock will clobber the drift factor to
near zero, because the Hardware Clock and System
Clock are synced by Eleven Minute Mode. What
actually needs to be done is refresh the adjtime
file timestamps and not calculate a new drift
factor.
Because it is a manual process to craft a good
Hardware Clock drift factor, that is, there is no
automated method that will produce a good drift
factor, this patch changes the default drift
calculation behavior to off, and it is turned on
by using the --update-drift option. Once we have a good
drift factor for a given machine we do not want
anything clobbering it, including an administrator
forgetting to turn off recalculation. A system
administrator should make a concious effort in
telling hwclock with the --update-drift option that
(s)he wants to recalculate the drift factor.
Without using the --update-drift option with calibrate
operations only the timestamps are refreshed in
the adjtime file. With the --update-drift option the old
default behavior of refreshing the timestamps and
updating the drift factor is performed.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
When hctosys is used at boot time, making it the
first caller of settimeofday, the responsibility
of setting persistent_clock_is_local is thrust
upon it. Currently hctosys always leaves this
variable uninitialized. This causes a Hardware
Clock configured to use the local timescale to be
clobbered with the UTC timescale by the kernel's
NTP eleven minute mode.
This patch fixes this hctosys bug, by having it
properly set persistent_clock_is_local according
to the time scale configured for the Hardware
Clock.
It does this via the kernel warp_clock function
but this in inconsequential, because we set the
system time immediately afterward.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Allowing hctosys to drift compensate facilitates:
More precise setting of the System Clock early in
the boot process when --adjust cannot be used
because the file system is not writeable.
Applies sub second drift corrections immediately,
where as --adjust cannot.
Reduces boot time by not calling hwclock multiple
times, e.g., --hctosys early before fsck when the
file system is read-only, then --adjust later when
the file system is read-write and --hctosys again
for drift correction.
Use of --adjust elsewhere may no longer be
necessary.
Part II
After the original submission of this patch I
realized that now all operations except --systz
require drift corrected Hardware Clock time.
Therefore, it should be done only once early in
the process. Upon implementation of that premise
many improvements were facilitated:
* Adds drift correction to --hctosys.
* Adds setting system time with sub-second precision.
* Adds --get, a drift corrected 'show' operation.
* Improves drift factor calculation precision while
greatly simplifying its algorithm.
* Fixes --show bug, printing integer sub-seconds, and
now uses a more intuitive positive value.
* Fixes --predict bug, drift correction must be
negated to predict future RTC time.
* Reduces the number of function arguments and
lines of code.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
sys-utils/hwclock.c:1219:13: warning: using integer absolute value function
'abs' when argument is of floating point type [-Wabsolute-value]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Translating these text elements should happen only once, which is
more likely when the text macros are used properly.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
If less than 23 hours have passed since the last calibration, hwclock
says "Not adjusting drift factor because it has been less than a day since
the last calibration.", but in fact compares to 23 hours, not 24.
This was originally reported at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689534
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Due to bug in older versions of hwclock, /etc/adjtime can contain
excessive drift value (up to many years per day). Prevent it
from applying.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
Failure of CMOS battery can cause writing of excessive drift
values (up to many years per day).
This causes excessive hwclock adjustment next time, which may lead
to overflow in calculate_adjustment() (and hang before 4a44a54b).
Prevent this situation, check drift for limits and reset drift to zero
instead.
Steps to reproduce:
mv /etc/adjtime /etc/adjtime.backup
rm /etc/adjtime
hwclock --set --date 2001-01-01\ 01:00:00
changing of /etc/adjtime.
mv /etc/adjtime /etc/adjtime.saved
hwclock --set --date 2001-01-02\ 01:00:01
mv /etc/adjtime.saved /etc/adjtime
echo "======= The /etc/adjtime has a \"correct\" look:"
cat /etc/adjtime
hwclock --debug --systohc --utc
echo "======= The /etc/adjtime now has deeply failed drift value:"
cat /etc/adjtime
mv /etc/adjtime /etc/adjtime.saved
hwclock --set --date 2015-01-01\ 01:00:00
mv /etc/adjtime.saved /etc/adjtime
hwclock --debug --adjust
echo "======= And the last /etc/adjtime:"
cat /etc/adjtime
mv /etc/adjtime.backup /etc/adjtime
hwclock --systohc --utc
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
In sys-utils/hwclock.c, set_hardware_clock_exact() has some problems when the
process gets pre-empted (for more than 100ms) before reaching the time for
which it waits:
1. The "continue" statement causes execution to skip the final tdiff
assignment at the end of the do...while loop, leading to the while condition
using the wrong value of tdiff, and thus always exiting the loop once
newhwtime != sethwtime (e.g., after 1 second). This masks bug # 2, below.
2. The previously-existing bug is that because it starts over waiting for the
desired time whenever two successive calls to gettimeofday() return values >
100ms apart, the loop will never terminate unless the process holds the CPU
(without losing it for more than 100ms) for at least 500ms. This can happen
on a heavily loaded machine or on a virtual machine (or on a heavily loaded
virtual machine). This has been observed to occur, preventing a machine from
completing the shutdown or reboot process due to a "hwclock --systohc" call in
a shutdown script.
The new implementation presented in this patch takes a somewhat different
approach, intended to accomplish the same goals:
It computes the desired target system time (at which the requested hardware
clock time will be applied to the hardware clock), and waits for that time to
arrive. If it misses the time (such as due to being pre-empted for too long),
it recalculates the target time, and increases the tolerance (how late it can
be relative to the target time, and still be "close enough". Thus, if all is
well, the time will be set *very* precisely. On a machine where the hwclock
process is repeatedly pre-empted, it will set the time as precisely as is
possible under the conditions present on that particular machine. In any
case, it will always terminate eventually (and pretty quickly); it will never
hang forever.
[kzak@redhat.com: - tiny coding style changes]
Signed-off-by: Chris MacGregor <chrismacgregor@google.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Attached is a patch file leap_seconds.patch against util-linux-2.22.2
that allows leap seconds to be included in hwclock --show or --hctosys.
The current code uses the default UTC zonefile in reading the hardware
RTC with mktime(). This zonefile usually does not include leap
seconds. As of this date there have been a total of 25 leap seconds
added since the epoch (start of 1970). This is particularly a problem
for systems using ntp to maintain their system clocks because ntp does
take leap seconds into account. A user can specify a leap-second-aware
zonefile via /etc/localtime. By defining the environment variable
TZUTC, mktime() can be induced to use a matching UTC zonefile that
includes leap seconds. The default behavior (TZUTC undefined) is
unchanged.
Regards,
Joseph Parmelee
jparmele at wildbear.com
A sideeffect of 839be2ba6b is that we now
warp the systemtime according to the timezone, on the first call of
--systz. This is not always the correct thing to do, and causes a
regression for us in Arch Linux.
The behavior is correct if the RTC, and hence the systemtime, is
in localtime. However, if the systemtime is already in UTC we don't
want to touch it when we set the kernel timezone (which we still need to
do as some filesystems use this information).
An almost identical issue was also fixed in systemd commit
72edcff5db936e54cfc322d9392ec46e2428fd9b.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The new option imitates adjtimex -c functionality and outputs
the drift in 10 second intervals.
[kzak@redhat.com: - coding style
- print hw and system time columns too]
Signed-off-by: Karel Zak <kzak@redhat.com>
Not sure why, but the current --systz uses non-NULL timeval for
settimeofday(). It means that build-in kernel warp clock mechanism is
not used and the system time is always modified.
The built-in kernel implementation allows to move the clock by
timezone only for very first settimeofday() call.
Signed-off-by: Karel Zak <kzak@redhat.com>
Andreas Henriksson
Karel Zak
Alexey Galakhov
J William Piggott
Sami Kerola
Benno Schulenberg
Lauri Nurmi
peppe
Stanislav Brabec
Chris MacGregor
Joseph Parmelee
Tom Gundersen
Ondrej Oprala