In early userspace, if kernel initialization happens extremely quickly,
a call to systemd-timestamp can potentially result in division by zero.
Ensure that the check in timespec_load, which only makes sense if tv_sec
is greater than zero, is guarded by this condition.
Starting a swap unit pointing to (What) a symlink (e.g. /dev/mapper/swap
or /dev/disk/by-uuid/...) would have said unit marked active, following
the one using the "actual" device (/dev/{dm-1,sda3}), but that new unit
would be seen as inactive.
Since all requests to stop swap units would follow/redirect to it,
and it is seen inactive, nothing would be done (swapoff never called).
This is because this unit would be treated twice in
swap_process_new_swap, the second call to swap_add_one causing it to
eventually be marked inactive.
l might contain zero strings, however there is still memory
allocated for NULL terminator, use _cleanup_strv_free_ instead to
prevent tiny leak in such case.
Network file systems generally do not offer inotify() that would work
across the network. We hence cannot rely on inotify() exclusiely in
those case. Provide an API to determine these cases, and suggest doing
manual regular rechecks.
Note that this is not complete yet, as we need to rescan journal dirs on
network file systems explicitly to find new/removed files
When traversing entry array chains for a bisection or for retrieving an
item by index we previously always started at the beginning of the
chain. Since we tend to look at the same chains repeatedly, let's cache
where we have been the last time, and maybe we can skip ahead with this
the next time.
This turns most bisections and index lookups from O(log(n)*log(n)) into
O(log(n)). More importantly however, we seek around on disk much less,
which is good to reduce buffer cache and seek times on rotational disks.
I hit an "assert(j->installed)" failure in transaction_apply(). Looking
into the backtrace I saw what happened:
1. The system was booting. var.mount/start was an installed job.
2. I pressed Ctrl+Alt+Del.
3. reboot.target was going to be isolated.
4. transaction_apply() proceeded to install a var.mount/stop job.
5. job_install() canceled the conflicting start job.
6. Depending jobs ended recursively with JOB_DEPENDENCY, among them was
local-fs.target/start.
7. Its OnFailure action triggered - emergency.target was now going to be
isolated.
8. We recursed back into transaction_apply() where the half-installed
var.mount/stop job confused us.
Recursing from job installation back into the transaction code cannot be
a good idea. Avoid the problem by canceling the conflicting job
non-recursively in job_install(). I don't think we'll miss anything by
not recursing here. After all, we are called from transaction_apply().
We will not be installing just this one job, but all jobs from a
transaction. All requirement dependencies will be included in it and
will be installed separately. Every transaction job will get a chance
to cancel its own conflicting installed job.
Mostly useful for testing purposes. Setting Age to 1s works just as
well, but it is surprising that using 0s (or just 0) does not work.
Also clarify this in the documentation.
If you enter unit_add_exec_dependencies with m->where = NULL, you'll
very likely end up aborting somewhere under socket_needs_mount.
(When systemd goes to check to see if the journald socket requires your
mount, it'll do path_startswith(path, m->where)... *kaboom*)
This patch should ensure that:
a) both branches in mount_add_one() set m->where, and
b) mount_add_extras() calls unit_add_exec_dependencies() *after*
setting m->where.
