| Commit message (Collapse) | Author | Files | Lines |
|---|
|
C.f. ac0a94f7438b49a0890d9806db1fa211a5bca10a.
Fixes #12693.
|
|
The parent is waiting for an EOF on the pipe transmitting the pager name
before starting to send data. With external pagers this happens due to
execlp() CLOEXEC'ing the pipe, so the internal pager needs to close it
manually.
|
|
Fixes #12650
cryptsetup: Extract dependency check to a separate function
cryptsetup: style improvements, error checking
Return early on failure/nothing to do
Removed braces from single-line ifs
Check return value of fstab_filter_options
cryptsetup: code style
|
|
This is just a follow-up to https://github.com/systemd/systemd/pull/12617.
|
|
The idea is to have at least one range to make the new format clearly
distinguishable from the old. But it is enough to just do it once.
In particular, in case the affinity would be specified like 0, 2, 4, 6…,
this gives much shorter output.
|
|
|
|
|
|
|
|
|
|
|
|
Maximum time interval of DHCPv4 request is 63sec.
So, setting 100sec is enough.
|
|
|
|
cpu_set_malloc() was the last user. It doesn't seem useful to keep
it just to save the allocation of a few hundred bytes in a test, so
it is dropped and a fixed maximum is allocated (1024 bytes).
|
|
If we had a configuration setting from a configuration file, and it was
removed, we'd still remember the old value, because there's was no mechanism to
"reset" everything, just to assign new values.
Note that the effect of this is limited. For settings that have an "ongoing" effect,
like systemd.confirm_spawn, the new value is simply used. But some settings can only
be set at start.
In particular, CPUAffinity= will be updated if set to a new value, but if
CPUAffinity= is fully removed, it will not be reset, simply because we don't
know what to reset it to. We might have inherited a setting, or we might have
set it ourselves. In principle we could remember the "original" value that was
set when we were executed, but propagate this over reloads and reexecs, but
that would be a lot of work for little gain. So this corner case of removal of
CPUAffinity= is not handled fully, and a reboot is needed to execute the
change. As a work-around, a full mask of CPUAffinity=0-8191 can be specified.
|
|
We have settings which may be set on the kernel command line, and also
in /proc/cmdline (for pid1). The settings in /proc/cmdline have higher priority
of course. When a reload was done, we'd reload just the configuration file,
losing the overrides.
So read /proc/cmdline again during reload.
Also, when initially reading the configuration file when program starts,
don't treat any errors as fatal. The configuration done in there doesn't
seem important enough to refuse boot.
|
|
This makes the handling of this option match what we do in unit files. I think
consistency is important here. (As it happens, it is the only option in
system.conf that is "non-atomic", i.e. where there's a list of things which can
be split over multiple assignments. All other options are single-valued, so
there's no issue of how to handle multiple assignments.)
|
|
|
|
|
|
It just seems to fit better there and it's always better to have things
in shared/ rather than basic/.
|
|
The CPU_SET_S api is pretty bad. In particular, it has a parameter for the size
of the array, but operations which take two (CPU_EQUAL_S) or even three arrays
(CPU_{AND,OR,XOR}_S) still take just one size. This means that all arrays must
be of the same size, or buffer overruns will occur. This is exactly what our
code would do, if it received an array of unexpected size over the network.
("Unexpected" here means anything different from what cpu_set_malloc() detects
as the "right" size.)
Let's rework this, and store the size in bytes of the allocated storage area.
The code will now parse any number up to 8191, independently of what the current
kernel supports. This matches the kernel maximum setting for any architecture,
to make things more portable.
Fixes #12605.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We now don't have the support to delete netdevs and dependent
upon iproute to delete. With this we can delete via networkctl
and use in our test cases too.
Note that it supports deleting multiple links at once.
```
sudo ./networkctl delete test1 test2 test3 test4
```
|
|
refactor to use timerfd in place of rtc wakealarm
confirm CLOCK_BOOTTIME_ALARM support in can_s2h
Remove CLOCK_BOOTTIME_ALARM task from TODO
remove unnecessary check on clock_supported return
|
|
|
|
|
|
|
|
nlmon is a Netlink monitor device.
|
|
|
|
|
|
|
|
|
|
|
|
But some tests requires both IPv4 and IPv6 addresses are configured.
Only in that case wait for addresses to be configured.
|
|
|
|
|
