Add (void) casting for a couple of functions where we knowingly ignore
the returning error code.
Use EXIT_FAILURE where appropriate.
Try to initialize structures at declaration time, or at once.
Also, make it slightly more powerful, by accepting a flags argument, and
make it safe for handling if more than one cmsg attribute happens to be
attached.
Currently, we guarantee that if two event-sources with the same priority
fire at the same time, they're always dispatched in the same order. While
this might sound nice in theory, there's is little benefit in providing
stability on that level. We have no control over the order the events are
reported, hence, we cannot guarantee that we get notified about both at
the same time.
By dropping the stability guarantee, we loose roughly 10% Heap swaps in
the prioq on a desktop cold-boot. Krzysztof Kotlenga even reported up to
20% on his tests. This sounds worth optimizing, so drop the stability
guarantee.
Add comment to prioq.c explaining what it does. And more importantly,
mention that we implement a Heap. It's more than annoying having to
figure out what the code actually does, without ever mentioning the word
'heap'.
In some situations rebooting after fixing rootfs fails because
the job for reboot.target gets canceled. To avoid this
the "mode" parameter of the StartUnitReplace() call needs to be
set to "replace-irreversibly".
This introduces two new helpers alongside sd_bus_path_{encode,decode}(),
which work similarly to their counterparts, but accept a format-string as
input. This allows encoding and decoding multiple labels of a format
string at the same time.
Tested with a dummy service running 'sleep', modifying its CPUAffinity,
restarting the service and checking the ^Cpus_allowed entries in the
/proc/PID/status file.
Use the new code in config_parse_cpu_affinity2.
Tested by modifying CPUAffinity=... setting in /etc/systemd/system.conf
and reloading the daemon, then checking ^Cpus_allowed in /proc/1/status
to confirm the correct CPU mask is in place.
The DHCP variable in the [Network] section of the network configuration
file moves the link to the configured state according to the following:
DHCP=yes Link is configured when either DHCPv4 or DHCPv6 succeed
DHCP=ipv4 Link is configured only when DHCPv4 succeeds
DHCP=ipv6 Link is configured only when DHCPv6 succeeds
DHCP=no Neither DHCPv4 or DHCPv6 is attempted
Reported by Martin Pitt.
Fixes https://github.com/systemd/systemd/issues/1368
This cleans up exec_child() function by moving mac_smack_apply_pid()
and setup_pam() to the same condition block, since both of them have
the same condition (i.e params->apply_permissions). It improves
readability without changing its operation.
Whenever a Router Advertisement is received, dhcp6_configure() will be
called. A Router Advertisment can also instruct DHCPv6 to start acquiring
IPv6 addresses in manged mode, if it previously was handling only other
information. As an Router Advertisment is also received after the DHCPv6
client has resumed from a suspend, fix the function not to assume DHCPv6
is currently running, but instead try to restart it. Handle
sd_dhcp6_start() returning -EALREADY indicating that the DHCPv6 client was
already running.
Collect all client unrefs in one place to unclutter the error handling.
Fixes https://github.com/systemd/systemd/issues/963
Update the test case to stop the ongoing Information Request exchange
before unsetting its state. To keep the test case callback verification
simpler, temporarily unset the callback function before stopping.
Prevent modifications to index, MAC address, DUID and Information
Request while the DHCPv6 client is running.
Require the DHCPv6 client to be stopped first instead of always
unconditionally restarting it if the caller calls
sd_dhcp6_client_start() more than once. With this change, handling
of for example incoming Router Advertisments becomes much easier.
When 'SmackProcessLabel=' is used in user@.service file, all processes
launched in systemd user session should be labeled as the designated name
of 'SmackProcessLabel' directive. However, if systemd has its own smack
label using '--with-smack-run-label' configuration, '(sd-pam)' is
labeled as the specific name of '--with-smack-run-label'. If
'SmackProcessLabel=' is used in user@.service file without
'--with-smack-run-label' configuration, (sd-pam) is labeled as "_" since
systemd (i.e. pid=1) is labeled as "_".
This is mainly because setup_pam() function is called before applying
smack label to child process. This patch fixes it by calling setup_pam()
after setting the smack label.
If we spawn a unit with a non-empty 'PAMName=', we fork off a
child-process _inside_ the unit, known as '(sd-pam)', which watches the
session. It waits for the main-process to exit and then finishes it via
pam_close_session(3).
However, the '(sd-pam)' setup is highly asynchronous. There is no
guarantee that process gets spawned before we finish the unit setup.
Therefore, there might be a root-owned process inside of the cgroup of
the unit, thus causing cg_migrate() to error-out with EPERM.
This patch makes setup_pam() synchronous and waits for the '(sd-pam)'
setup to finish before continuing. This guarantees that setresuid(2) was
at least tried before we continue with the child setup of the real unit.
Note that if setresuid(2) fails, we already warn loudly about it. You
really must make sure that you own the passed user if using 'PAMName='.
It seems very plausible to rely on that assumption.
Add a 'destination' match rule for every SERVICE argument in addition to
the 'sender' rule. This is consistent with busctl(1), which documents
monitor as dumping "messages to or from this peer".