Meson 0.58 has gotten quite bad with emitting a message every time
a quoted command is used:
Program /home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh found: YES (/home/zbyszek/src/systemd-work/tools/meson-make-symlink.sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program sh found: YES (/usr/bin/sh)
Program xsltproc found: YES (/usr/bin/xsltproc)
Configuring custom-entities.ent using configuration
Message: Skipping bootctl.1 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping journal-remote.conf.5 because HAVE_MICROHTTPD is false
Message: Skipping journal-upload.conf.5 because HAVE_MICROHTTPD is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Message: Skipping loader.conf.5 because ENABLE_EFI is false
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
Program ln found: YES (/usr/bin/ln)
...
Let's suffer one message only for each command. Hopefully we can silence
even this when https://github.com/mesonbuild/meson/issues/8642 is
resolved.
Currently the label database is not reloaded with libselinux 3.2 on a
policy reload.
Since libselinux 3.2 avc_open(3) uses the SELinux status page instead of
a netlink socket to check for policy reloads.
The status page is also queried in mac_selinux_maybe_reload().
Thus calls to selinux_check_access(3) might consume an update, queried
by selinux_status_updated(3), leaving mac_selinux_maybe_reload() unable
to detect a policy reload.
Do not use selinux_status_updated(3), use selinux_status_policyload(3)
unconditionally.
Relevant libselinux commit: https://github.com/SELinuxProject/selinux/commit/05bdc03130d741e53e1fb45a958d0a2c184be503
Debian Bullseye is going to ship libselinux 3.1, so stay compatible for
backports.
When `--json` option is specified, "status" and "list" commands gives
the same information, as originally "list" just gives partial
information of "status" in different format.
systemd-run is documented to as being able to connect and run on a
specific user bus with "--user --machine=lennart@.host" arguments.
This PR updates some logic that prevented this from working.
The code in service_spawn() was written as if exec_fd_event_source
was always unset. (We would either fail the assertion that is moved in the
patch, or leak the event source object if it was set.)
To make this work, let's always assert that exec_fd_event_source is unset,
and actually unset it service_sigchld_event(). I think this is the most
elegant approach. The problem is that we don't have the same information
about execution flags as in service_spawn(), so we need to conditionalize
on pid==main_pid to know if we should disable exec_fd_event_source.
I think this matches all cases where we may set exec_fd_event_source:
service_enter_start() and service_run_next_main().
service_enter_stop_post() calls service_set_state(), which will also destroy
the source. But that happens too late, because from service_enter_stop_post()
we call service_spawn() first, and then service_set_state() second.
(An alternative approach would be to deallocate the existing
exec_fd_event_source in service_spawn(). But this would mean that we would
temporarily have an event source attached to a process that we already know is
dead, which seems less than ideal.)
Original report from Dimitri John Ledkov <dimitri.ledkov@canonical.com>:
> Ubuntu private bug reference for this issue at the moment is
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1921145
> Michael's and Ian's team run into an issue when using systemd in the
> initrd, without dbus daemon running, and launching a unit in a
> particular way that appears to lock up systemd (pid 1) it self.
> michael vogt: "The attached script works for me to reproduce this on
> classic. I tested 20.04 (245) and 21.04 (247) in a qemu VM. Sometimes
> I need to run it multiple times but usually it crashes after at most 2
> runs. Use "journalctl | tail" to see the messages, it's the same that
> Ian reported. There is also a /var/crash/_usr_lib_systemd_systemd
> crash file created."
> I understand that the particular way to run a unit is very odd,
> however, it is currently possible to invoke, and it would be expected
> for pid1 to not lock up and crash.
> The Assertion that systemd hits is along the lines of:
> [ 10.182627] systemd[1]: Assertion 's' failed at
> src/core/service.c:3204, function service_dispatch_exec_io().
> Aborting.
> [ 10.195458] systemd[1]: Caught <ABRT>, dumped core as pid 449.
> [ 10.204446] systemd[1]: Freezing execution.
Apparently CAN links will show up in rtnetlink with very low MTUs. We
shouldn't consider them relevant if no IP is spoken over them, since
these MTUs are irrelevant for us then.
Hence, let's check if there's an address assigned to the link before
considering its MTU.
As additional safety net filter out MTUs smaller than the minimum DNS
packet size, too.
Finally, in case we don't find any suitable interface MTU, let's default
to 1500 as the generic Ethernet MTU.
Fixes: #19396
This mirrors the change done for systemd-resolved in
9793530228. Quoting that patch:
> We generally operate on the assumption that a source is "gone" as soon as we
> unref it. This is generally true because we have the only reference. But if
> something else holds the reference, our unref doesn't really stop the source
> and it could fire again.
In particular, we take temporary references from sd-event code, and when called
from an sd-event callback, we could temporarily see this elevated reference
count. This patch doesn't seem to change anything, but I think it's nicer to do
the same change as in other places and not rely on _unref() immediately
disabling the source.
This drops the "const" specifier from the opaque object parameters to
various functions in our API.
This effectively reverts #19292 and more.
Why drop this? Our public APIs should not leak too much information
about how stuff is implemented internally. In our public APIs we
shouldn't give too many guarantees we don#t want to necessarily keep.
Specifically: in many cases it makes sense that getters actually
generate/parse/allocate data on the fly, storing/caching the result
internally, to speed things up, do things lazily or to track memory
allocations so that they can be freed later. Doing this means we need to
change the objects, even though the getters are semantically a read
operation.
We want to retain the freedom that we can change things around
internally. By exposing the objects as "const" we remove a good chunk of
that, for little gain.
See sd_bus_creds_get_description() for a real example of a getter that
implicitly caches and thus modifies the relevant object.
This removes the "const" decorators from sd-dhcp and sd-netlink, two
APIs that we intend to make public eventually even though they still are
not, leaving us the chance to still fix this before it becomes set in
stone.
Why is this necessary? Several examples below.
- When a route sets prefsrc, then the address must be already assigned
(see issue #19285), and also it must be ready if IPv6.
- When a route or nexthop sets gateway, then the address must be reachable.
- When a route sets nexthop ID, then the corresponding nexthop must be
assigned.
- When a route sets multipath routes on another interface, then the
interface must exist and be ready to configure.
- When configuring address, the same address must not be under removing
(see issue #18108).
Etc,. etc,...
So, this makes all requests about addresses, routes, and nethops are once
stored in the queue, and will be processed when they are ready to configure.
Fixes#18108 and #19285.
Zbigniew Jędrzejewski-Szmek
Christian Göttsche
Yu Watanabe
Anita Zhang
Michael Catanzaro
Lennart Poettering