shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-02-14 05:57:40 +03:00
Code
systemd/units/user-runtime-dir@.service.in

23 lines
678 B
SYSTEMD
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 13:23:58 +09:00
# SPDX-License-Identifier: LGPL-2.1-or-later
logind: split %t directory creation to a helper unit 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.
2017-12-09 19:30:17 +01:00
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
logind: change user-runtime-dir to query runtime dir size from logind via the bus I think this is a slightly cleaner approach than parsing the configuration file at multiple places, as this way there's only a single reload cycle for logind.conf, and that's systemd-logind.service's runtime. This means that logind and dbus become a requirement of user-runtime-dir, but given that XDG_RUNTIME_DIR is not set anyway without logind and dbus around this isn't really any limitation. This also simplifies linking a bit as this means user-runtime-dir doesn't have to link against any code of logind itself.
2018-08-08 14:50:57 +02:00
Description=User Runtime Directory /run/user/%i
man: add a description of user@.service, user-runtime-dir@.service, user-*.slice Fixes #9590.
2018-07-20 15:49:57 +02:00
Documentation=man:user@.service(5)
logind: don't delay login for root even if systemd-user-sessions.service is not activated yet If for any reason something goes wrong during the boot process (most likely due to a network issue), system admins should be allowed to log in to the system to debug the problem. However due to the login session barrier enforced by systemd-user-sessions.service for all users, logins for root will be delayed until a (dbus) timeout expires. Beside being confusing, it's not a nice user experience to wait for an indefinite period of time (no message is shown) this and also suggests that something went wrong in the background. The reason of this delay is due to the fact that all units involved in the creation of a user session are ordered after systemd-user-sessions.service, which is subject to network issues. If root needs to log in at that time, logind is requested to create a new session (via pam_systemd), which ultimately ends up waiting for systemd-user-session.service to be activated. This has the bad side effect to block login for root until the dbus call done by pam_systemd times out and the PAM stack proceeds anyways. To solve this problem, this patch orders the session scope units and the user instances only after systemd-user-sessions.service for unprivileged users only.
2022-07-07 12:02:04 +02:00
After=dbus.service
logind: split %t directory creation to a helper unit 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.
2017-12-09 19:30:17 +01:00
StopWhenUnneeded=yes
user-runtime-dir@.service: don't stop on runlevel switch (#10079) 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
2018-09-14 04:11:57 +01:00
IgnoreOnIsolate=yes
logind: split %t directory creation to a helper unit 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.
2017-12-09 19:30:17 +01:00
[Service]
meson: use jinja2 for unit templates We don't need two (and half) templating systems anymore, yay! I'm keeping the changes minimal, to make the diff manageable. Some enhancements due to a better templating system might be possible in the future. For handling of '## ' — see the next commit.
2021-05-16 11:55:36 +02:00
ExecStart={{ROOTLIBEXECDIR}}/systemd-user-runtime-dir start %i
ExecStop={{ROOTLIBEXECDIR}}/systemd-user-runtime-dir stop %i
units: make sure user-runtime-dir@.service is Type=oneshot We order user@.service after it, hence we need to properly know when it finished starting up.
2018-08-02 20:57:56 +02:00
Type=oneshot
units: use =yes rather than =true everywhere So far we always used "yes" instead of "true" in all our unit files, except for one outlier. Let's do this here too. No change in behaviour whatsoever, except that it looks prettier ;-)
2018-09-12 19:04:24 +02:00
RemainAfterExit=yes
units: assign user-runtime-dir@.service to user-%i.slice 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.
2018-08-03 10:45:31 +02:00
Slice=user-%i.slice
Copy Permalink