This reverts commit 8688c29b5aece49805a244676cba5bba0196f509, but leaves the
reproducer. Structured assignment should be enough to fully initialize the
variable and new0 is not necessary.
The buffer retrieved from memstream has the size that the same as the written
data. When we write do write(f, s, strlen(s)), then no terminating NUL is written,
and the buffer is not (necessarilly) a proper C string.
Felix Riemann [Wed, 29 May 2019 19:17:42 +0000 (21:17 +0200)]
pager: Fix deadlock when using built-in pager
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.
Roberto Santalla [Sun, 26 May 2019 11:55:30 +0000 (13:55 +0200)]
cryptsetup: Add dependency for detached header
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
shared/cpu-set-util: only force range printing one time
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.
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).
pid1: when reloading configuration, forget old settings
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.
pid1: don't reset setting from /proc/cmdline upon restart
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.)
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.
Susant Sahani [Wed, 22 May 2019 09:46:41 +0000 (15:16 +0530)]
networkctl: add support to delete virtual netdevs
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.
Milan Broz [Mon, 27 May 2019 07:44:14 +0000 (09:44 +0200)]
cryptsetup: Add LUKS2 token support.
LUKS2 supports so-called tokens. The libcryptsetup internally
support keyring token (it tries to open device using specified
keyring entry).
Only if all token fails (or are not available), it uses a passphrase.
This patch aligns the functionality with the cryptsetup utility
(cryptsetup luksOpen tries tokens first) but does not replace
the systemd native ask-password function (can be used the same in
combination with this patch).
Milan Broz [Mon, 27 May 2019 07:27:54 +0000 (09:27 +0200)]
cryptsetup: Do not fallback to PLAIN mapping if LUKS data device set fails.
If crypt_load() for LUKS succeeds, we know that it is a LUKS device.
Failure of data device setting should fail in this case; remapping
as a PLAIN device late could mean data corruption.
(If a user wants to map PLAIN device over a device with LUKS header,
it should be said explicitly with "plain" argument type.)
Also, if there is no explicit PLAIN type requested and crypt device
is already initialized (crypt_data_type() is set), do not run
the initialization again.
rules: enable hardware-related targets also for user instances
> the odd thing is that these units are also defined for the systemd user
> instance. However, because these are bound to SYSTEMD_USER_WANTS rather than
> SYSTEMD_WANTS they are effectively useless unless some other software
> installs the corresponding udev rules first.
This adds the rules and starts those targets also for user instances.
Fixes #12330.
Yu Watanabe [Sat, 25 May 2019 22:21:00 +0000 (07:21 +0900)]
udev: suppress warning when interface matches 99-default.link
This suppress the following warning:
```
systemd-udevd[437]: Config file /usr/lib/systemd/network/99-default.link
applies to device based on potentially unpredictable interface name 'wlan0'
```
Frantisek Sumsal [Mon, 27 May 2019 17:59:26 +0000 (19:59 +0200)]
test: correctly fail when system is borked
In certain situations, the systemctl commands may fail (e.g. due to
missing shared libraries), but the 'script' continues and creates a
/testok file, marking the test incorrectly as passed. Let's fix this and
bail out immediately when a command exits with a non-zero exit code.