If for any reason local-fs.target fails at startup while a password is
requested by systemd-cryptsetup@.service, we end up with the emergency shell
competing with systemd-ask-password-console.service for the console.
This patch makes sure that:
- systemd-ask-password-console.service is stopped before entering in emergency
mode so it won't make any access to the console while the emergency shell is
running.
- systemd-ask-password-console.path is also stopped so any attempts to restart
systemd-cryptsetup in the emergency shell won't restart
systemd-ask-password-console.service and kill the emergency shell.
- systemd-ask-password-wall.path is stopped so
systemd-ask-password-wall.service won't be started as this service pulls
the default dependencies in.
Fixes: #10131
systemd-tmpfiles-setup.service needs to be ordered after
systemd-journald.service, so entries in /run/log/journal are already
created when systemd-tmpfiles tries to adjust its permissions.
This is specially problematic for setups using a volatile journal where
the initrd does not ship a machine-id (i.e. OSTree-based systems), where
logs from the initrd will be inaccessible for users in the
systemd-journal group. It also has a side effect of `journalctl --user`
failing with "No journal files were opened due to insufficient
permissions".
Fixes#10128.
We would create a useless empty directory under build/.
It seems we were lucky and all symlinks were installed into directories
which were alredy created because we installed something into the same
location earlier.
While at it, also add '-v' to 'mkdir -p'. This will print the names of
directories as they are created (just once), making it easier to see all of
what the install script is doing.
Followup to commit 13cf422e04b7 ("user@.service: don't kill user manager at runlevel switch")
I think there's a general rule that units with `StopWhenUnneeded=yes` need
`IgnoreOnIsolate=yes`... But it doesn't apply to `suspend.target` and friends.
`printer.target` and friends break on isolate even if we apply the rule[1].
That just leaves `graphical-session.target`, which is a user service.
"isolate" is *mostly* a weird attempt to emulate runlevels, so I decided
not to worry about it for user services.
[1] https://github.com/systemd/systemd/issues/6505#issuecomment-320644819
Loggin in as root user and then switching the runlevel results in a
stop of the user manager, even though the user ist still logged in.
That leaves a broken user session.
Adding "IgnoreOnIsolate=true" to user@.service fixes this.
This service won't use much resources, but it's certainly nicer to see
it attached th the user's slice along with user@.service, so that
everything we run for a specific user is properly bound into one unit.
We use systemd-user-sessions.service as barrier when to allow login
sessions. With this patch user@.service is ordered after that too, so
that any login related code (which user-runtime-dir@.service is) is
guaranteed to run after the barrier, and never before.
This is an additional synchronization point normally not needed. Hence,
let's make it passive, i.e. pull it in from the unit which wants to be
ordered before the update service rather than by the update service
itself.
systemd offline-updates allows dropping multiple system update units
to be added to system-update.target.wants.
As documented in systemd.offline-updates(7) only 1 of these units
should actually be active (based on the /system-update symlink) and
when that unit is done it should reboot the system.
In some cases it is desirable to run a unit whenever booting in
offline-updates mode indepedent of which update unit is going to
handle the update. One example of this is integration with bootloader
code which checks if the previous boot was succesful.
Since the active unit will reboot the system when it is done, there
is no guarantee that adding such a unit to system-update.target.wants
will get it executed always.
This commit adds a system-update-pre.target which can be used for
units which should always run when booting in offline-updates mode.
This is generally the safer approach, and is what container managers
(including nspawn) do, hence let's move to this too for our own
services. This is particularly useful as this this means the new
@system-service system call filter group will get serious real-life
testing quickly.
This also switches from firing SIGSYS on unexpected syscalls to
returning EPERM. This would have probably been a better default anyway,
but it's hard to change that these days. When whitelisting system calls
SIGSYS is highly problematic as system calls that are newly introduced
to Linux become minefields for services otherwise.
Note that this enables a system call filter for udev for the first time,
and will block @clock, @mount and @swap from it. Some downstream
distributions might want to revert this locally if they want to permit
unsafe operations on udev rules, but in general this shiuld be mostly
safe, as we already set MountFlags=shared for udevd, hence at least
@mount won't change anything.
This adds a small service "systemd-portabled" and a matching client
"portablectl", which implement the "portable service" concept.
The daemon implements the actual operations, is PolicyKit-enabled and is
activated on demand with exit-on-idle.
Both the daemon and the client are an optional build artifact, enabled
by default rhough.
Unfortunately this needs a new binary to do the mount because there's just
too many special steps to outsource this to systemd-mount:
- EPERM needs to be treated specially
- UserRuntimeDir= setting must be obeyed
- SELinux label must be adjusted
This allows user@.service to be started independently of logind.
So 'systemctl start user@nnn' will start the user manager for user nnn.
Logind will start it too when the user logs in, and will stop it (unless
lingering is enabled) when the user logs out.
Fixes#7339.
This removes the UserTasksMax= setting in logind.conf. Instead, the generic
TasksMax= setting on the slice should be used. Instead of a transient unit we
use a drop-in to tweak the default definition of a .slice. It's better to use
the normal unit mechanisms instead of creating units on the fly. This will also
make it easier to start user@.service independently of logind, or set
additional settings like MemoryMax= for user slices.
The setting in logind is removed, because otherwise we would have two sources
of "truth": the slice on disk and the logind config. Instead of trying to
coordinate those two sources of configuration (and maintainer overrides to
both), let's just convert to the new one fully.
Right now now automatic transition mechanism is provided. logind will emit a
hint when it encounters the setting, but otherwise it will be ignored.
Fixes#2556.
Systems that have an accurate real-time clock may have an initial
unsynchronized time that is close enough to the synchronized time that
the final adjustment doesn't trigger a waking "clock set" event. Have
timesyncd touch a file in its runtime directory as a secondary signal
for synchronization. Continue to support the timerfd-based trigger as a
sufficient condition when the watchfile is not present.
Closes issue #8683
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
We still get the errors logged, but we don't fail the service. This
is better for users because rerunning tmpfiles-setup.service a second
time is dangerous (c.f. cd9f5b68ce).
Note that this only touches sd-tmpfiles-setup.service and
sd-tmpfiles-setup-dev.service. sd-tmpfiles-clean.service is as before.
https://bugzilla.redhat.com/show_bug.cgi?id=1539341
Use `systemctl --user --force exit` to implement the systemd-exit
user service.
This removes our dependence on an external `kill` binary and the
concerns about whether they recognize SIGRTMIN+n by name or what their
interpretation of SIGRTMIN is.
Tested: `systemctl --user start systemd-exit.service` kills the
`systemd --user` instance for my user.
Suspend to Hibernate is a new sleep method that invokes suspend
for a predefined period of time before automatically waking up
and hibernating the system.
It's similar to HybridSleep however there isn't a performance
impact on every suspend cycle.
It's intended to use with systems that may have a higher power
drain in their supported suspend states to prevent battery and
data loss over an extended suspend cycle.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
CPU accounting has a too bad impact on performance to be enabled by
default. Therefore we should not delegate "cpu" for now.
OTOH since commit e0c46a7364, memory accounting
has been turned on for all units by default so it makes sense to delegate this
controller by default.
`-.mount` is placed in `system.slice`, and hence depends on it.
`-.mount` is always active and can never be stopped. Therefore the same
should be true of `system.slice`.
Synthesize it as perpetual (unless systemd is running as a user manager).
Notice we also drop `Before=slices.target` as unnecessary.
AFAICS the justification for `perpetual` is to provide extra protection
against unintentionally stopping every single service. So adding
system.slice to the perpetual units is perfectly consistent.
I don't expect this will (or can) fix any other problem. And the
`perpetual` protection probably isn't formal enough to spend much time
thinking about. I've just noticed this a couple of times, as something
that looks strange.
Might be a bit surprising that we have user.slice on-disk but not
system.slice, but I think it's ok. `systemctl status system.slice` will
still point you towards `man systemd.special`. The only detail is that the
system slice disables `DefaultDependencies`. If you're worrying about how
system shutdown works when you read `man systemd.slice`, I think it is not
too hard to guess that system.slice might do this:
> Only slice units involved with early boot
> or late system shutdown should disable this option
(Docs are great. I really appreciate the systemd ones).
On systems that only use resolved for name resolution, there are usecases that
require resolved to be started before sysinit target, such that network name
resolution is available before network-online/sysinit targets. For example,
cloud-init for some datasources hooks into the boot process ahead of sysinit
target and may need network name resolution at that point already.
systemd-resolved already starts pretty early in the process, thus starting it
slightly earlier should not have negative side effects.
However, this depends on resolved ability to connect to system DBus once that
is up.
Franck Bui