The different libc implements TZ deprecation in settimeofday() library
function in the different way. Let's hide these portability issues and
use directly Linux syscall to set timezone.
Addresses: https://github.com/karelzak/util-linux/issues/995
Signed-off-by: Karel Zak <kzak@redhat.com>
CC: J William Piggott <elseifthen@gmx.com>
According to audit_log_user_message(3) result 1 is "success" and 0 is
"failed", we use standard EXIT_{SUCCESS,FAILURE} macros with reverse
status.
Addresses: https://github.com/karelzak/util-linux/issues/966
Signed-off-by: Karel Zak <kzak@redhat.com>
______________________________________________________
GNU C Library NEWS -- history of user-visible changes.
Version 2.31
Deprecated and removed features, and other changes affecting compatibility:
* The settimeofday function can still be used to set a system-wide time
zone when the operating system supports it. This is because the Linux
kernel reused the API, on some architectures, to describe a system-wide
time-zone-like offset between the software clock maintained by the kernel,
and the "RTC" clock that keeps time when the system is shut down.
However, to reduce the odds of this offset being set by accident,
settimeofday can no longer be used to set the time and the offset
simultaneously. If both of its two arguments are non-null, the call
will fail (setting errno to EINVAL).
Callers attempting to set this offset should also be prepared for the call
to fail and set errno to ENOSYS; this already happens on the Hurd and on
some Linux architectures. The Linux kernel maintainers are discussing a
more principled replacement for the reused API. After a replacement
becomes available, we will change settimeofday to fail with ENOSYS on all
platforms when its 'tzp' argument is not a null pointer.
settimeofday itself is obsolescent according to POSIX. Programs that set
the system time should use clock_settime and/or the adjtime family of
functions instead. We may cease to make settimeofday available to newly
linked binaries after there is a replacement for Linux's time-zone-like
offset API.
______________________________________________________
hwclock(8) had one settimeofday(2) call where both args were set for
--hctosys when the RTC was ticking UTC. This allowed setting the system
time, timezone, and locking the warp_clock function with a single call.
That operation now takes 3 calls of settimeofday(2).
Although this common operation now takes three calls, the overall logic
for the set_system_clock() function was simplified.
Co-Author: Karel Zak <kzak@redhat.com>
Signed-off-by: J William Piggott <elseifthen@gmx.com>
The currently used date/time parser (for hwclock --set --date <date>)
is gnulib based code with GPLv3.
This patch allows to avoid this code and replace it with minimalistic
date/time parser.
Addresses: https://github.com/karelzak/util-linux/issues/891
Reported-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Let's be more verbose and provide real open() error to make
debugging easier on --verbose.
For example:
$ hwclock --verbose
hwclock from util-linux 2.34.193-6bebea-dirty
System Time: 1570445823.701266
Trying to open: /dev/rtc0
hwclock: cannot open /dev/rtc0: Permission denied <---
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.
Addresses: https://github.com/karelzak/util-linux/issues/879
Signed-off-by: Karel Zak <kzak@redhat.com>
Sorry detail-oriented people tend to wipe these out if they notice them.
Add in automated tools and lots of excess end-of-line spaces get wiped
out.
Addresses: https://github.com/karelzak/util-linux/pull/849
Signed-off-by: Karel Zak <kzak@redhat.com>
- Add --disable-hwclock-cmos configuration argument
- Add USE_HWCLOCK_CMOS (enabled by default for i386/x86_64)
- Add define(USE_HWCLOCK_CMOS)
- Compile hwclock-cmos.c only if USE_HWCLOCK_CMOS is true
- Remove all unnecessary #ifdefs from hwclock-cmos.c
- Add #ifdef USE_HWCLOCK_CMOS around the determine_clock_access_method()
call in hwclock.c
Signed-off-by: Carlos Santos <unixmania@gmail.com>
This change fixes "warning: variable 'var' may be uninitialized when used
here [-Wconditional-uninitialized]" warnings reported in various files.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
* add command line option --delay <seconds>
* read RTC type from /sys/class/rtc/rtc<N>/name
* default to 0.5 (500ms) for rtc_cmos or when RTC type is impossible
determine; otherwise delay is 0.
Signed-off-by: Karel Zak <kzak@redhat.com>
Undocumented at this time, because it is a skeleton
implementation. More debugging points are to be added after
refactoring is complete, or ad hoc in the mean time.
When fully implemented, enough time may have passed that the
deprecated --debug could be used to replace --ul-debug.
[kzak@redhat.com: - use __UL_INIT_DEBUG_FROM_STRING() to initialize the mask
- add hwclock_init_debug()]
Coauthored-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Warn on --debug; do not fallthrough because
the message is lost in the verbose output.
Coauthored-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Print a message when the format_iso_time() buffer is exceeded, because
there is more than one type of failure that returns -1.
Also remove the corresponding message from hwclock.c.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
commit f0a0ce7 makes debug mode implicit for the --test option.
Using the previous command syntax of --test and --debug
together invokes the undocumented Level 2 debugging when
setting the RTC. This can cause many thousands of lines of
output like:
1510967983.499968 < 1510967983.500000 (-0.000032)
Fix: bump Level 2 debugging to Level 9, just before the
other undocumented Level 10. This makes it improbable for
the development debug levels to be accessed unintentionally.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
* Start the ISO format flags at bit 0 instead of bit 1.
* Remove unnecessary _8601 from ISO format flag names to
avoid line wrapping and to ease readability.
* ISO timestamps have date-time-timzone in common, so move
the TIMEZONE flag to bit 2 causing all timestamp masks
to have the first three bits set and the last four bits
as timestamp 'options'.
* Change the 'SPACE' flag to a 'T' flag, because it makes
the code and comments more concise.
* Add common ISO timestamp masks.
* Implement the ISO timestamp masks in all applicable code
using the strxxx_iso() functions.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
This new function returns the GMT offset relative to its
argument. It is used in this patch to fix two bugs:
1) On platforms that the tm struct excludes tm_gmtoff,
hwclock assumes a one hour DST offset. This can cause
an incorrect kernel timezone setting. For example:
Master branch tested with tm_gmtoff illustrates the correct offset:
$ TZ="Australia/Lord_Howe" hwclock --hctosys --test | grep settimeofday
Calling settimeofday(1507494204.192398, -660)
Master branch tested without tm_gmtoff has an incorrect offset:
$ TZ="Australia/Lord_Howe" hwclock --hctosys --test | grep settimeofday
Calling settimeofday(1507494249.193852, -690)
Patched tested without tm_gmtoff has the correct offset:
$ TZ="Australia/Lord_Howe" hwclock --hctosys --test | grep settimeofday
Calling settimeofday(1507494260.194208, -660)
2) ISO 8601 'extended' format requires all time elements
to use a colon (:).
Current invalid ISO 8601:
$ hwclock
2017-10-08 16:25:17.895462-0400
Patched:
$ hwclock
2017-10-08 16:25:34.141895-04:00
Also required by this change:
login-utils/last.c: increase ISO out_len and in_len by one to
accommodate the addition of the timezone colon.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Special exit handling is not wanted for usage() or bad
command syntax. For example we do not want to audit:
hwclock --set --date foo
Signed-off-by: J William Piggott <elseifthen@gmx.com>
sysexits.h was introduced in v2.11t prior to util-linux-ng, with the
HISTORY entry: * hwclock: minor polishing.
So there was no specific issue solved by adding it. Its use was never
documented so it should be safe to remove.
Also, fix return values being used for the exit status that were not
magic constants (portability issue).
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Use plain int instead of type defining it to a boolean, and use numbers to
signify true or false as we do everywhere else in this source tree. And in
hwclock-cmos.c file booleans weren't even needed, to the related code is
removed.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Update debug messages for a combined --systz and --hctosys in
the set_system_clock function.
New debug messages:
hwclock --test -D --systz --localtime
Calling settimeofday(NULL, 240) to warp System time.
Test mode: clock was not changed
hwclock --test -D --systz --utc
Calling settimeofday(NULL, 0) to lock the warp function.
Calling settimeofday(NULL, 240) to set the kernel timezone.
Test mode: clock was not changed
hwclock --test -D --hctosys --utc
Calling settimeofday(1502239269.733639, 240)
Test mode: clock was not changed
hwclock --test -D --hctosys --localtime
Calling settimeofday(NULL, 240) to set persistent_clock_is_local.
Calling settimeofday(1502253708.200200, 240)
Test mode: clock was not changed
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Remove set_system_clock_timezone() because the previous patch
moved its functionality into set_system_clock().
Signed-off-by: J William Piggott <elseifthen@gmx.com>
The set_system_clock_timezone() function is nearly identical to
set_system_clock(). Three additional statements are required
to include systz in hctosys.
This patch is intentionally incomplete to make reviewing the
actual required changes easier. Other patches in this set will:
* remove set_system_clock_timezone()
* fix messages and debugging
* fix comments
* and finally refactor set_system_clock()
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Every hwclock operation that requires reading the RTC, tests
hclock_valid and prints a different warning. This redundancy
is unnecessary.
Move the warning to the RTC read block (the test was moved in
a previous patch in this set). This reduces function arguments
and is a significant code clean up. It will also benefit the
translators.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Correlate hclocktime with set_time instead of the other way around,
because set_time is used for timestamps in the adjtime file so it needs
to be unadulterated.
Also create var startup_hclocktime for correlated time.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Over the past decade a few commits for a corner case problem
have left the RTC read branch in a bad place.
The problem was: when a corrupted RTC could not be read, then
it also could not be reset, because hwclock would error out
due to the RTC read failure.
2.15-rc1 commit 3b96a7a Aug 9 2008
2.19-rc1 commit 5606df5 Dec 29 2010
2.23-rc1 commit ab8f402 Mar 21 2013
The first fix was to ignore a synchronization timeout only for
the busywait branch.
Two and a half years later a commit describing the same problem
took a little more heavy-handed approach by ignoring all
synchronization failures and the RTC read after it, for both of
the RTC set functions.
Because the previous fix also ignored the select() branch timeout
it caused a bogus warning. The chosen workaround for that was to
only print the select() timeout message in debug mode (this is
reverted by another patch).
The problem with these fixes is that we cannot just ignore the
synchronization timeout like that, because then the drift
correction operations will be invalid. The original logic was
correct; we must exit when synchronization fails.
Another problem is that now there are statements between the
timing-critical synchronize-read-timestamp trio (which were
also in the wrong order, but that part of the problem goes
back further in history).
The solution is to skip the RTC read block completely for the
RTC set functions when not also using the --update-drift
option. If we are updating the drift correction factor during
a set function then we must synchronize and read the RTC.
Otherwise reading the RTC is not needed. Anyone trying to set
a corrupt RTC should not be using --update-drift, because the
resulting drift correction factor would be invalid.
Using this approach has the added benefit of significantly
reducing system shutdown time when not using --update-drift:
time ./hwclock --test --systohc; time ./hwclock-master --test --systohc
Test mode: clock was not changed
real 0m0.072s
user 0m0.066s
sys 0m0.003s
Test mode: clock was not changed
real 0m1.000s
user 0m0.169s
sys 0m0.005s
I've see differences as high as 1.518 seconds.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Move the predict branch above the RTC read branch.
Move drift correction into the RTC read branch, because it
requires an accurate RTC read, and it needs to be skipped for
operations that do not require an RTC read.
Simplify the RTC read branch test.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
The systz option is all about speed, so move it to the
top and simplify the init clocks read test.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
hwclock previously used printf for custom errno messages.
Later they were converted to use warn(), but were not
squashed. One of the reasons for warn and errno is to avoid
making translators deal with a multitude custom strings.
Also the custom strings are incorrect:
hwclock --hctosys
hwclock: Must be superuser to set system clock.
Unable to set system clock.
We do not know what the system permissions are set to. The
correct response is to simply say permission was denied; as
the default errno string does. The second line is redundant
and just adds noise the code and to logs.
Patched:
hwclock --hctosys
hwclock: settimeofday() failed: Operation not permitted
Signed-off-by: J William Piggott <elseifthen@gmx.com>
hwclock --get foo
hwclock: 3 too many arguments given
Fixed:
hwclock --get foo
hwclock: 1 too many arguments given
Signed-off-by: J William Piggott <elseifthen@gmx.com>
hwclock --setepoch --epoch 0
Will warn that the epoch option is required.
The --epoch presence test is made on its argument after it is
converted to an integer. This means any value it can be tested
for, can also be given as an input.
So make the conversion after the presence test, like the
--date option does.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Make whatisdb/manpage and usage() one-line descriptions match.
Also update the description; hwclock has evolved into much more
than reading and setting the Hardware Clock. It also sets the
System Clock, warps the System Clock, sets the kernel time
configurations, and more.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
