1. If we exited emergency mode immediately, we don't want to have an
irreversible stop job still running for syslog.socket. I _suspect_ that
can't happen, but let's not waste effort working out exactly why it's
impossible and not just very improbable.
2. Similarly, it seems undesirable to have rescue.service and
emergency.service both running with an open FD of /dev/console, for
however short a period.
Note this commit only changes how the code is expressed; it does not change
the existence of any dependency.
The `Conflicts=` was added in 3136ec90, "Stop syslog.socket when entering
emergency mode". The discussion in the issue #266 raised concerns that
this might be needed for other units, but failed to point out why
syslog.socket is special. The reason is that syslog.socket has
DefaultDepedencies=no, so it does not get Requires=sysinit.target like
other socket units do. But syslog.service does require sysinit.target,
among other things.
We don't have many socket, path, or timer units with
DefaultDependencies=no, and I don't think any of the triggered services
have such additional hard dependencies as syslog.service does.
It is much less confusing if we keep this `Conflicts=` in the same file as
the `DefaultDependencies=no` which made it necessary.
The original aim of this commit is that starting machines.target from the
rescue shell would not kill the rescue shell and lock you out of the
system.
This is similar to commit 6579a622, for the conflict between
sysinit.target and the _emergency_ shell. That particular commit
introduced an ordering cycle and will need to be reverted and/or
fixed. This one does not, because it does not need to introduce any new
dependencies.
The reason why this commit is allowable also has it's own merit:
machines.target was not marked as AllowIsolate. Also, the point of
containers is to not escape them... I don't think we want to promote
machines.target as a default target or similar; you would generally want
some system service to allow you to shut down the machine, for example. I
don't see this approach used in CoreOS, nor in Fedora Atomic Host; we are
missing any positive examples of its utility.
Requires=basic.target / After=basic.target can be removed for the same
reason.
Previously, if a PTR query is seen for a non-existing record, we'd
generate an empty response (but not NXDOMAIN or so). Fix that. If we
have no data about an IP address, then let's say so, so that the
original error is returned, instead of anything synthesized.
Fixes: #6543
Let's ensure that "no gateway" translates to "no domain", instead of an
empty reply. This is in line with what nss-myhostname does in the same
case, hence let's unify behaviour here of nss-myhostname and resolved.
THe match cookie was used by kdbus to identify matches we install
uniquely. But given that kdbus is gone, the cookie serves no process
anymore, let's kill it.
When debug logging is enabled we show brief information about every bus
message we send or receieve. Pretty much all information is shown,
except for the error name if a message is an error (interestingly we do
print the error text however). Fix that, and add the error name as well.
The script wasn't apparently used since the switch to meson, because
it required the sys subdirectory to be present in the same subdirectory
where the output script is located.
Let's use f-strings to make the whole thing more readable. Add some
extra checks.
This is primarly useful to support escaped double quotes in PROGRAM or
IMPORT{program} directives.
The only possibilty before this patch was to use an external shell script but
this seems too cumbersome for trivial logics such as
PROGRAM=="/bin/sh -c 'FOO=\"%s{model}\"; echo ${FOO:0:4}'"
or any similar shell constructs that needs to deals with patterns including
whitespaces.
As it's the case for single quote and for directives running a program, words
within escaped double quotes will be considered as a single argument.
Fixes: #6835
Starting with kernel version 4.8 the kernel has a single `l3mdev` rule
that handles this. This rule will be created when the first VRF device
is added.
When an interface has been enslaved to a VRF the received routes should
be added to the VRFs RT instead of the main table.
This change modifies the default behaviour of routes in the case where a
network belongs to an VRF. When the user does not configure a
`DHCP.RouteTable` in a `systemd.network` file and the interface belongs
to a VRF, the VRFs routing table is used instead of RT_TABLE_MAIN.
When the user has configured a custom routing table for DHCP the VRFs
table is ignored and the users preference takes precedence.
This slightly changes how we log about failures. Previously,
service_enter_dead() would log that a service unit failed along with its
result code, and unit_notify() would do this again but without the
result code. For other unit types only the latter would take effect.
This cleans this up: we keep the message in unit_notify() only for debug
purposes, and add type-specific log lines to all our unit types that can
fail, and always place them before unit_notify() is invoked.
Or in other words: the duplicate log message for service units is
removed, and all other unit types get a more useful line with the
precise result code.
This makes sure that if we learn via inotify or another event source
that a cgroup is empty, and we checked that this is indeed the case (as
we might get spurious notifications through inotify, as the inotify
logic through the "cgroups.event" is pretty unspecific and might be
trigger for a variety of reasons), then we'll enqueue a defer event for
it, at a priority lower than SIGCHLD handling, so that we know for sure
that if there's waitid() data for a process we used it before
considering the cgroup empty notification.
Fixes: #6608
We are about to add second cgroup-related queue, called
"cgroup_empty_queue", hence let's rename "cgroup_queue" to
"cgroup_realize_queue" (as that is its purpose) to minimize confusion
about the two queues.
Just a rename, no functional changes.
From bce67bbee3, systemd-networkd always shows
```
rtnl: received address with invalid family type 32, ignoring.
```
during boot-up. In the code, there are log_warning() and log_debug() for the
same situation, and the log_debug() is never called. So, let's lower the
log level and remove never called function.
Normally, Symlinks= failing is not considered fatal nor destructive.
Let's slightly alter behaviour here if RemoveOnStop= is turned on. In
that case the use in a way opted for destructive behaviour and we do
unlink all sockets and symlinks when the socket unit goes down. And that
means we might as well unlink any pre-existing if this mode is selected.
Yeah, it's a bit of a stretch to do this, but @OhNoMoreGit is right: if
RemoveOnStop= is on we are destructive regarding any pre-existing
symlinks on stop, and it would be quite weird if we wouldn't be on
start.
Note that this change does not make symlink creation failing fatal. I am
not entirely sure about whether it should be, but I am leaning towards
not making it fatal for two reasons: symlinks like this tend to be a
compatibility feature, and hence unlikely to be essential for operation,
in a way this breaks compatibility, and while doing that is not off the
table, we should probably avoid it if we are not entirely sure it's a
good thing.
Note that this also changes plain symlink() to symlink_idempotent() so
that existing symlinks with the right destination are nothing we log
about.
Fixes: #6920
Let's use proc_cmdline_get_key() instead of some strstr() logic to find
a kernel command line key. Using strstr() gets confused by similarly
named keys, and we should reuse our own code as much as we can anyway...
Fixes: #6330
Just brief texts for now, so that we have something
(And in the long rung we should beef all this up, and add a test that
every ID listed in sd-messages.h is accompanied by a matching catalog
entry)
Alan Jenkins
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
John Lin
Yu Watanabe
Franck Bui
Andreas Rammhold