"--offset" takes an optional argument; if none is specified,
stroull() will attempt to parse a NULL pointer. For example:
$ udevadm test-builtin 'blkid --offset' /sys/dev/block/8:1
Update "--offset" to require an argument; also verify that the
offset is not negative.
"-m" is specified as a short form of "--monitor" in the option struct,
but not included in getopt_long's optstring. Update the optstring
to be consistent with the option struct.
Follow-up for ba7f4ae617.
By default, we detect if the real root has a separate /usr/sbin directory, but
this can be overrides with -Dsplit-bin=true|false. The check assumes that
/usr/sbin is split if it is not a symlink, so it'll return a false negative
with some more complicated setups. But that's OK, in those cases this should be
configured explicitly.
This will copy the structure of the directories in the root file system to
$DESTDIR. If a directory is a directory in $DESTDIR but a symlink in the root
file system, this script will fail. This means that it's not possible to reuse
a $DESTDIR from between ba7f4ae61 and this patch.
CPU accounting has a too bad impact on performance to be enabled by
default. Therefore we should not delegate "cpu" for now.
OTOH since commit e0c46a7364, memory accounting
has been turned on for all units by default so it makes sense to delegate this
controller by default.
E.g. if you have a monthly event and you set the computer clock back one
year, we can allow the next 12 monthly events to happen naturally. In fact
we already do this when you start a Persistent=yes timer, we just need to
apply the same logic when it's running and we notice the system clock
being set backwards.
On timejumps, including suspend, timer_time_change() calls for a
re-calculation of the next elapse. Sadly I'm not quite sure what the
intended effect of this was! Because it was not managing to fire
OnCalendar= timers which fired during the suspend... unless the timer had
already fired once before.
Reported, entirely correctly as far as I can see, on stackexchange:
https://unix.stackexchange.com/questions/351829/systemd-timer-that-expired-while-suspended
/* If we know the last time this was
* triggered, schedule the job based relative
- * to that. If we don't just start from
- * now. */
+ * to that. If we don't, just start from
+ * the activation time. */
The same code is called for both the initial calculation and this
re-calculation. If we're _not_ already active, then this is before the
activation time has been recorded in the unit, so just use the current
time as before. The new code is mechanically adapted from the same
logic for `OnActiveSec=` (case TIMER_ACTIVE in the code which follows).
Tested with `date --set`.
Motivations:
* Rotate monitoring data from Atop into files which are named per-day.
Fedora currently implements this with a cron job that runs at midnight,
but that didn't handle suspend correctly either.
* unbound-anchor.timer on Fedora, is used to update DNSSEC "root trust
anchor" daily, before the TTL expires. It uses OnCalendar=daily
AccuracySec=24h. Which is a bit suspect because the TTL is 2 days, but I
think it has the right general idea.
None of the other timer settings are correct, because they would not
account for time spent in suspend. Unless you set WakeSystem
(this feature is currently undocumented).
* So in general, we can expect to see people using OnCalendar= for the same
cases as cron.daily and cron.monthly. Which use anacron to keep track of
jobs which should be run even if the system was down at the time.
Timers which are configured to run more frequently than that, are
unlikely to mind if they get run slightly more often that the writer
realized, relative to the amount of time the system was really running.
* From the user report above: "I only want to use remind to show a desktop
notification, it seems excessive to wake up the computer for that. Also,
I would like to get the reminder first thing in the morning, so the
OnActiveSec doesn't help with that."
We have two variables `b` and `base`. `b` is declared within limited
scope; `base` is declared at the top of the function. However `base`
is actually only used within a scope which is exclusive of `b`. Clarify
by moving `base` inside the limited scope as well.
(Also `base` doesn't need initializing any more than `b` does. The
declaration of `base` is now immediately followed by a case analysis of
`v->base`, which serves almost exclusively to determine the value of
`base`).
In particular:
- drop "when it is non-zero" to avoid implying that it can be called if the
queue is not empty.
- "has been created" sounds like something happened in parallel,
but what we really mean is that *this* particular object *was* created in a
certain way.
If any devices are marked with 'SYSTEMD_READY=0' then we shouldn't run any
btrfs check on them.
Indeed there's no point in running "btrfs ready" on devices that already have
SYSTEMD_READY=0 set. Most probably such devices are members of a higher layer
aggregate device such as dm-multipath or software RAID. Doing IO on them wastes
time at best, and may cause delays, timeouts, or even hangs at worst (think
active-passive multipath or degraded RAID, for example).
It was initially reported at:
https://bugzilla.opensuse.org/show_bug.cgi?id=872929
The script shouldn't rely on a previous script exiting with a status code
that prevents it to be executed. Instead, should check if the destination
directory for the BLS kernel image exists and exit otherwise.
Let's include the command line to use to get the requested output. This
makes it easy to copy/paste the command line out, and add "--in-place"
to actually apply the changes "run-coccinelle.sh" outputs.
At various places we only want to close fds if they are not
stdin/stdout/stderr, i.e. fds 0, 1, 2. Let's add a unified helper call
for that, and port everything over.
A runaway string should still be returned by the code that splits on
commas, so add a '?' to the regex so that the last '"?' in a string
still produces a valid block for the split code.
Tested:
ACTION=="remove\"GOTO=""
Which then produced:
$ test/rule-syntax-check.py src/login/70-uaccess.rules
# looking at src/login/70-uaccess.rules
Invalid line src/login/70-uaccess.rules:10: ACTION=="remove\"GOTO=""
clause: ACTION=="remove\"GOTO=""
