We use LOG_PRI() in all log_*() functions, so let's do that here too for
consistency. Effectively this doesn't change anything since we only use
LOG_{INFO,DEBUG,...} as the argument.
udev: don't complain when udev_watch_end() is called without udev_watch_init()
E.g. udevadm test prints "Invalid inotify descriptor." which is
meaningless without any context. I think it should be OK to call udev_watch_end()
from a cleanup path without any warning (even at debug level).
man: add more details for IMPORT, PROGRAM and RUN keys
967de8faceaa83c11a1215515cb135d7a8c0c32c added a note that I found very hard
to understand. Reword it, and also describe how IMPORT and PROGRAM are different
from RUN.
There is no reason to consider this wrong. In fact one could argue that +=
is more appropriate, because we always add to options, and not replace previous
assignments. If we output a debug message, we implicitly ask people to "fix" this,
and we shouldn't.
Udev logs are full of messages about wrong operator type:
...
Reading rules file: /usr/lib/udev/rules.d/60-persistent-storage.rules
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:30 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:54 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:57 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:60 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:63 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:66 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:67 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:93 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:107 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:110 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-storage.rules:113 IMPORT key takes '==' or '!=' operator, assuming '=='.
Reading rules file: /usr/lib/udev/rules.d/60-persistent-v4l.rules
/usr/lib/udev/rules.d/60-persistent-v4l.rules:7 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-v4l.rules:9 IMPORT key takes '==' or '!=' operator, assuming '=='.
/usr/lib/udev/rules.d/60-persistent-v4l.rules:16 IMPORT key takes '==' or '!=' operator, assuming '=='.
...
The warning was downgraded in f0beb6f816035e438d684cc52ae76fc4a44fc197, but I
think it should be removed altogether. IMPORT{program}="asdf" seems like an
obvious way to write this, and people don't expect to have to write "==".
So let's just allow any operator.
nspawn: mount os-release in two steps to make it read-only
The kernel interface requires setting up read-only bind-mounts in
two steps, the bind first and then a read-only remount.
Fix nspawn-mount, and cover this case in the integration test.
man: don't claim environment.d/ was about sessions
This only sets the environment for user *services*, it has no effect on
sessions, as those get an env block set up by whatever program sets them
up and not systemd.
network: dhcp4: do not assign new address before old one is not removed
If DHCP4 client lost a lease, and then soon acquire new lease, then
the removal of the old address may not be completed. If that happens,
and the new and old addresses are the same, then the new address will be
considered as a foreign address. Such a situation can occur when the
DHCP4 server is restarted.
This makes networkd wait for the removal of the old address when a new
lease is acquired.
This also makes the link in configuring state when renewing address.
network: do not make link in configured state when no address is assigned
When DHCP6 and RA are enabled, and RA does not provide any addresses,
then link may become configured state even if no address is assigned,
due to the time-lag between RA completion and DHCP reply.
This makes if DHCP is explicitly enabled, then link must have at least
one valid address to be in the configured state.
timer: Adjust calendar timers based on monotonic timer instead of realtime
When the RTC time at boot is off in the future by a few days, OnCalendar=
timers will be scheduled based on the time at boot. But if the time has been
adjusted since boot, the timers will end up scheduled way in the future, which
may cause them not to fire as shortly or often as expected.
Update the logic so that the time will be adjusted based on monotonic time.
We do that by calculating the adjusted manager startup realtime from the
monotonic time stored at that time, by comparing that time with the realtime
and monotonic time of the current time.
Added a test case to validate this works as expected. The test case creates a
QEMU virtual machine with the clock 3 days in the future. Then we adjust the
clock back 3 days, and test creating a timer with an OnCalendar= for every 15
minutes. We also check the manager startup timestamp from both `systemd-analyze
dump` and from D-Bus.
Test output without the corresponding code changes that fix the issue:
Timer elapse outside of the expected 20 minute window.
next_elapsed=1594686119
now=1594426921
time_delta=259198
With the code changes in, the test passes as expected.
The test is failing in koji, and the line from printf() does not end up
in the logs for some reason. log_info() works fine, so let's just use
that here too.
Judging by https://launchpad.net/~upstream-systemd-ci/+archive/ubuntu/systemd-ci/+packages,
it got updated about 15 hours ago and the "build check" action has been
failing with
```
The following packages have unmet dependencies:
kbd : Depends: console-setup but it is not going to be installed or
E: Unable to correct problems, you have held broken packages.
console-setup-mini but it is not going to be installed
```
since then
pid1: create ro private tmp dirs when /tmp or /var/tmp is read-only
Read-only /var/tmp is more likely, because it's backed by a real device. /tmp
is (by default) backed by tmpfs, but it doesn't have to be. In both cases the
same consideration applies.
If we boot with read-only /var/tmp, any unit with PrivateTmp=yes would fail
because we cannot create the subdir under /var/tmp to mount the private directory.
But many services actually don't require /var/tmp (either because they only use
it occasionally, or because they only use /tmp, or even because they don't use the
temporary directories at all, and PrivateTmp=yes is used to isolate them from
the rest of the system).
To handle both cases let's create a read-only directory under /run/systemd and
mount it as the private /tmp or /var/tmp. (Read-only to not fool the service into
dumping too much data in /run.)
$ sudo systemd-run -t -p PrivateTmp=yes bash
Running as unit: run-u14.service
Press ^] three times within 1s to disconnect TTY.
[root@workstation /]# ls -l /tmp/
total 0
[root@workstation /]# ls -l /var/tmp/
total 0
[root@workstation /]# touch /tmp/f
[root@workstation /]# touch /var/tmp/f
touch: cannot touch '/var/tmp/f': Read-only file system
This commit has more changes than I like to put in one commit, but it's touching all
the same paths so it's hard to split.
exec_runtime_make() was using the wrong cleanup function, so the directory would be
left behind on error.
nss-mymachines: drop support for UID/GID resolving
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.
We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)
The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
docs: permit user/group services that do not support enumeration
sssd people don't like enumeration and for some other cases it's not
nice to support either, in particular when synthesizing records for
container/userns UID/GID ranges.
Let's add a catalog entry explaining further details.
Most importantly though: talk to PID 1 directly, via the private D-Bus
socket, so that this actually works correctly during early boot, where
D-Bus is not around.
Apparently systemd is no longer installed in fedora containers
by default
```
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348:
starting container process caused "exec: \"/sbin/init\": stat /sbin/init: no such file or directory": unknown.
The command "$CI_MANAGERS/fedora.sh SETUP" failed and exited with 127 during .
```
repart: include more relevant information in the warning message, fix test
The test would always fail with a long uname. In F33 this is right
now "5.8.0-0.rc2.20200622git625d3449788f.1.fc33.x86_64" which caused the
test to always fail.
projects / thirdparty / systemd.git / log
