units: skip modprobe@.service if the unit appears to be already loaded
Possible alternative to #14819.
For me, setting RemainAfterExit=yes would be OK, but if people think that it
might cause issues, then this could be a reasonable alternative that still
let's us skip the invocation of the separate binary.
As with the previous changes the same arguments apply
- distributions have scripts to rewrite shebangs on installation and
they know what locations to rely on.
- For tests/compilation we should rather rely on the user to have setup
there PATH correctly.
In particular this makes testing from git easier on NixOS where do not provide
/bin/bash to improve compose-ability.
Use Finished instead of Started for Type=oneshot services (#14851)
UnitStatusMessageFormats.finished_job, if present,
will be called with the same arguments as
job_get_done_status_message_format() to provide a format string
appropriate for the context
This commit replaces "Started" with "Finished" for started oneshot
units, as mentioned in the referenced issue
units: restore RemainAfterExit=yes in systemd-vconsole-setup.service
This reverts the second part of 8125e8d38e3aa099c7dce8b0161997b8842aebdc.
The first part was reverted in 750e550eba362096d56a35104c6a32631aa67b8e.
The problem starts when s-v-s.s is pulled in by something that is then pulled
in by sysinit.target. Every time a unit is started, systemd recursively checks
all dependencies, and since sysinit.target is pull in by almost anything, we'll
start s-v-s.s over and over. In particular, plymouth-start.service currently
has Wants=s-v-s.s and After=s-v-s.s.
units: do not ignore return value from systemd --user
This minus has been there since the unit was added in d42d27ead91e470cb12986d928441e56c0f543ca. I think the idea was not cause things
to fail if the user instance doesn't work. But ignoring the return value
doesn't seem to be the right way to approach the problem. In particular, if
the program fails to run, we'll get a bogus fail state, see
https://bugzilla.redhat.com/show_bug.cgi?id=1727895#c1:
with the minus:
$ systemctl start user@1002
Job for user@1002.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status user@1002.service" and "journalctl -xe" for details.
without the minus:
$ systemctl start user@1002
Job for user@1002.service failed because the control process exited with error code.
See "systemctl status user@1002.service" and "journalctl -xe" for details.
We're operating on known paths in root-owned directories here, so the detour
through toctou-safe methods that require /proc to be mounted is not necessary.
Should fix https://bugzilla.redhat.com/show_bug.cgi?id=1807768.
sysusers: many different errnos to express one condition
See https://bugzilla.redhat.com/show_bug.cgi?id=1807768. It turns
out that sysusers cannot query if the group exists:
Failed to check if group dnsmasq already exists: No such process
...
Failed to check if group systemd-timesync already exists: No such process
When the same command is executed later, the issue does not occur. Not sure why
the behaviour in the initial transaction is different. But let's accept all
errors that the man pages list. We check if the user/group exists before creating
anyway, so this seems pretty safe.
tree-wide: use the return value from sockaddr_un_set_path()
It fully initializes the address structure, so no need for pre-initialization,
and also returns the length of the address, so no need to recalculate using
SOCKADDR_UN_LEN().
socklen_t is unsigned, so let's not use an int for it. (It doesn't matter, but
seems cleaner and more portable to not assume anything about the type.)
It returns 32 bits, unsigned on amd64, so it's probably similar everywhere
with glibc. But let's make the code generic, without assuming specific size
or signedness.
.msg_namelen was set to a bogus value before we actually stored the path in the
the structure. sockaddr_un_set_path() returns the length, so just use that.
Kevin P. Fleming [Mon, 24 Feb 2020 14:54:35 +0000 (09:54 -0500)]
RequireMountsFor in systemd-nspawn should wait for machine mount
This patch modifies the RequireMountsFor setting in systemd-nspawn@.service to wait for the machine instance directory to be mounted, not just /var/lib/machines.
HATAYAMA Daisuke [Sat, 29 Feb 2020 21:31:38 +0000 (06:31 +0900)]
shared/logs-show: Remove unused OUTPUT_FOLLOW
As of the commit aae9a96d4b3a8562af9e8c6a23871b442645b954 removing --follow
option in systemctl command, OUTPUT_FOLLOW has never been set anywhere. Let's
remove it.
The condition expression of the if-statement in show_journal() that refers to
OUTPUT_FOLLOW now thus evaluates always to true. Hence, the call of
sd_journal_wait() is in dead code, and the outer infinite for-loop is
meaningless, which we remove as cleanup.
machined needs access to the host mount namespace to propagate bind
mounts created with the "machinectl bind" command. However, the
"ProtectKernelLogs" directive relies on mount namespaces to make the
kernel ring buffer inaccessible. This commit removes the
"ProtectKernelLogs=yes" directive from machined service file introduced
in 6168ae5.
Susant Sahani [Sun, 1 Mar 2020 04:12:39 +0000 (05:12 +0100)]
network: Allow to configure GW even UseRoutes=false
When use UseRoutes=False so the DHCP request itself does not request
for Classless Static Routes option.
As a result, the DHCP server will only respond with a Router option.
In this case since we are using the UseRoutes=False option the gateway
that comes in via the router option does not get configured.
This patch fixes theis behaviour.
Peter Hutterer [Mon, 10 Feb 2020 04:32:48 +0000 (14:32 +1000)]
rules.d: import the keyboard builtin instead of running it
RUN seems to be used primarily for historical reasons over the more
immediate IMPORT command. As a side-effect, RUN also runs *after* all the
rules have been processed which is not really what we want here - we expect
the device to be updated immediately. Other rules that rely on accurate evdev
axes should be able to assume the axes are already present. So let's use
IMPORT here.
For consistency, the second two rules are split across multiple lines as well.
pid1: add new mode systemd.show-status=error and use it when 'quiet' is passed
systemd.show-status=error is useful for the case where people care about errors
only.
If people want to have a quiet boot, they most likely don't want to see all
status output even if there is a delay in boot, so make "quiet" imply
systemd.show-status=error instead of systemd.show-status=auto.
pid1: when showing error status, do not switch to status=temporary
We would flip to status=temporary mode on the first error, and then switch back
to status=auto after the initial transaction was done. This isn't very useful,
because usually all the messages about successfully started units and not
related to the original failure. In fact, all those messages most likely cause
the information about the prime error to scroll off screen. And if the user
requested quiet boot, there's no reason to think that they care about those
success messages.
Also, when logging about dependency cycles, treat this similarly to a unit
error and show the message even if the status is "soft disabled" (before we
wouldn't show it in that case).
pid1: make cylon timeout significantly bigger when not showing any messages
When we are booting with show-status=on, normally new status updates happen a
few times per second. Thus, it is reasonable to start showing the cylon eye
after 5 s, because that means a significant delay has happened. When we are
running with show-status=off or show-status=auto (and no error had occured),
the user is expecting maybe 15 to 90 seconds with no output (because that's
usually how long the whole boot takes). So we shouldn't bother the user with
information about a few seconds of delay. Let's make the timeout 25s if we are
not showing any messages.
Conversly, when we are outputting status messages, we can show the cylon eye
with a shorter delay, now that we removed the connection to enablement status.
Let's make this 2s, so users get feedback about delays more quickly.
pid1: touch the /run/systemd/show-status just once
We know if we created the file before, no need to repeat the operation. The
state in /run should always match our internal state. Since we call
manager_set_show_status() quite often internally, this saves quite a few
pointless syscalls.
We would say "Enabling" also for SHOW_STATUS_AUTO, which is actually
"soft off". So just print the exact state to make things easier to understand.
Also add a helper function to avoid repeating the enum value list.
pid1: do not fail if we get EPERM while setting up network name
In a user namespace container:
Feb 28 12:45:53 0b2420135953 systemd[1]: Starting Home Manager...
Feb 28 12:45:53 0b2420135953 systemd[21]: systemd-homed.service: Failed to set up network namespacing: Operation not permitted
Feb 28 12:45:53 0b2420135953 systemd[21]: systemd-homed.service: Failed at step NETWORK spawning /usr/lib/systemd/systemd-homed: Operation not permitted
Feb 28 12:45:53 0b2420135953 systemd[1]: systemd-homed.service: Main process exited, code=exited, status=225/NETWORK
Feb 28 12:45:53 0b2420135953 systemd[1]: systemd-homed.service: Failed with result 'exit-code'.
Feb 28 12:45:53 0b2420135953 systemd[1]: Failed to start Home Manager.
We should treat this similarly to the case where network namespace are not
supported at all.
projects / thirdparty / systemd.git / log
