shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-25 01:34:28 +03:00
Code
6ce3d33bd5
systemd/units/user@.service.in

31 lines
868 B
SYSTEMD
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 07:23:58 +03:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Add SPDX license headers to unit files
2017-11-18 19:35:03 +03:00
#
logind: add service for per-user shared systemd daemon
2011-06-30 04:18:01 +04:00
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
relicense to LGPLv2.1 (with exceptions) We finally got the OK from all contributors with non-trivial commits to relicense systemd from GPL2+ to LGPL2.1+. Some udev bits continue to be GPL2+ for now, but we are looking into relicensing them too, to allow free copy/paste of all code within systemd. The bits that used to be MIT continue to be MIT. The big benefit of the relicensing is that closed source code may now link against libsystemd-login.so and friends.
2012-04-12 02:20:58 +04:00
# 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
logind: add service for per-user shared systemd daemon
2011-06-30 04:18:01 +04:00
# (at your option) any later version.
[Unit]
Improve messages about user mode a bit
2014-01-09 02:20:45 +04:00
Description=User Manager for UID %i
man: add a description of user@.service, user-runtime-dir@.service, user-*.slice Fixes #9590.
2018-07-20 16:49:57 +03:00
Documentation=man:user@.service(5)
units: Order user@.service after systemd-oomd.service The user manager connects to oomd over varlink. Currently, during shutdown, if oomd is stopped before any user manager, the user manager will try to reconnect to the socket, leading to a warning from pid 1 about a conflicting transaction. Let's fix this by ordering user@.service after systemd-oomd.service, so that user sessions are stopped before systemd-oomd is stopped, which makes sure that the user sessions won't try to start oomd via its socket after systemd-oomd is stopped.
2023-03-17 15:07:56 +03:00
After=user-runtime-dir@%i.service dbus.service systemd-oomd.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 21:30:17 +03:00
Requires=user-runtime-dir@%i.service
user@.service: don't kill user manager at runlevel switch 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.
2018-09-12 16:10:58 +03:00
IgnoreOnIsolate=yes
logind: add service for per-user shared systemd daemon
2011-06-30 04:18:01 +04:00
[Service]
pam_systemd: export DBUS_SESSION_BUS_ADDRESS
2014-01-06 08:00:16 +04:00
User=%i
Add pam configuration to allow user sessions to work out of the box systemd-logind will start user@.service. user@.service unit uses PAM with service name 'systemd-user' to perform account and session managment tasks. Previously, the name was 'systemd-shared', it is now changed to 'systemd-user'. Most PAM installations use one common setup for different callers. Based on a quick poll, distributions fall into two camps: those that have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia, Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE). Distributions that have system-auth have just one configuration file that contains auth, password, account, and session blocks, and distributions that have common-auth also have common-session, common-password, and common-account. It is thus impossible to use one configuration file which would work for everybody. systemd-user now refers to system-auth, because it seems that the approach with one file is more popular and also easier, so let's follow that.
2013-09-11 22:31:14 +04:00
PAMName=systemd-user
pid1: make sure we send our calling service manager RELOADING=1 when reloading And send READY=1 again when we are done with it. We do this not only for "daemon-reload" but also for "daemon-reexec" and "switch-root", since from the perspective of an encapsulating service manager these three operations are not that different.
2023-01-02 17:01:56 +03:00
Type=notify-reload
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 12:55:36 +03:00
ExecStart={{ROOTLIBEXECDIR}}/systemd --user
logind: port over to use scopes+slices for all cgroup stuff In order to prepare things for the single-writer cgroup scheme, let's make logind use systemd's own primitives for cgroup management. Every login user now gets his own private slice unit, in which his sessions live in a scope unit each. Also, add user@$UID.service to the same slice, and implicitly start it on first login.
2013-07-02 03:46:30 +04:00
Slice=user-%i.slice
core: introduce new KillMode=mixed which sends SIGTERM only to the main process, but SIGKILL to all daemon processes This should fix some race with terminating systemd --user, where the system systemd instance might race against the user systemd instance when sending SIGTERM.
2014-01-29 16:38:55 +04:00
KillMode=mixed
user: delegate cpu controller, assign weights to user slices So far we didn't enable the cpu controller because of overhead of the accounting. If I'm reading things correctly, delegation was enabled for a while for the units with user and pam context set, i.e. for user@.service too. a931ad47a8623163a29d898224d8a8c1177ffdaf added the explicit Delegate=yes|no switch, but it was initially set to 'yes'. acc8059129b38d60c1b923670863137f8ec8f91a disabled delegation for user@.service with the justication that CPU accounting is expensive, but half a year later a88c5b8ac4df713d9831d0073a07fac82e884fb3 changed DefaultCPUAccounting=yes for kernels >=4.15 with the justification that CPU accounting is inexpensive there. In my (very noncomprehensive) testing, I don't see a measurable overhead if the cpu controller is enabled for user slices. I tried some repeated compilations, and there is was no statistical difference, but the noise level was fairly high. Maybe better benchmarking would reveal a difference. The goal of this change is very simple: currently all of the user session, including services like the display server and pipewire are under user@.service. This means that when e.g. a compilation job is started in the session's app.slice, the processes in session.slice compete for CPU and can be starved. In particular, audio starts to stutter, etc. With CPU controller enabled, I can start start 'ninja -C build -j40' in a tab and this doesn't have any noticable effect on audio. I don't think the particular values matter too much: the CPU controller is work-convserving, and presumably the session slice would never need more than e.g. one 1 full CPU, i.e. half or a quarter of available CPU resources on even the smallest of today's machines. app.slice and session.slice are assigned equal weights, background.slice is assigned a smaller fraction. CPUWeight=100 is the default, but I wrote it explicitly to make it easier for users to see how the split is done. So effectively this should result in session.slice getting as much power as it needs. If if turns out that this does have a noticable overhead, we could make it opt-in. But I think that the benefit to usability is important enough to enable it by default. W/o something like this the session is not really usable with background tasks.
2022-07-02 11:33:49 +03:00
Delegate=pids memory cpu
units: make system service manager create init.scope subcgroup for user service manager This one is basically for free, since the service manager is already prepared for being invoked in init.scope. Hence let's start it in the right cgroup right-away.
2023-04-24 11:11:46 +03:00
DelegateSubgroup=init.scope
Set user@.service TasksMax=infinity The user manager is still limited by its parent slice user-UID.slice, which defaults to 4096 tasks. However, it no longer has an additional limit of 512 tasks. Fixes #1955.
2015-11-23 01:00:43 +03:00
TasksMax=infinity
core: split system/user job timeouts and make them configurable Config options are -Ddefault-timeout-sec= and -Ddefault-user-timeout-sec=. Existing -Dupdate-helper-user-timeout= is renamed to -Dupdate-helper-user-timeout-sec= for consistency. All three options take an integer value in seconds. The renaming and type-change of the option is a small compat break, but it's just at compile time and result in a clear error message. I also doubt that anyone was actually using the option. This commit separates the user manager timeouts, but keeps them unchanged at 90 s. The timeout for the user manager is set to 4/3*user-timeout, which means that it is still 120 s. Fedora wants to experiment with lower timeouts, but doing this via a patch would be annoying and more work than necessary. Let's make this easy to configure.
2021-01-26 22:23:12 +03:00
TimeoutStopSec={{ DEFAULT_USER_TIMEOUT_SEC*4//3 }}s
units: turn off keyring handling for user@.service This service uses PAM anyway, hence let pam_keyring set things up for us. Moreover, this way we ensure that the invocation ID is not set for this service as key, and thus can't confuse the user service's invocation ID. Fixes: #11649
2019-03-13 20:47:28 +03:00
KeyringMode=inherit
units: run user service managers at OOM score adjustment 100 Let's make it slightly more likely that a per-user service manager is killed than any system service. We use a conservative 100 (from a range that goes all the way to 1000). Replaces: #17426 Together with the previous commit this means: system manager and system services are placed at OOM score adjustment 0 (specifically: they inherit kernel default of 0). User service manager (both for root and non-root) are placed at 100. User services for non-root are placed at 200, those for root inherit 100. Note that processes forked off the user *sessions* (i.e. not forked off the per-user service manager) remain at 0 (e.g. the shell process created by a tty or ssh login). This probably should be addressed too one day (maybe in pam_systemd?), but is not covered here.
2021-09-30 12:23:32 +03:00
OOMScoreAdjust=100
units: let systemd --user manage its own memory pressure handling Let's make things systematic: the per-user and the per-system manager should manage their own memory pressure, as they are, well, managers of things. This is particularly relevant and the per-user service manager should watch its own "init.scope" subcgroup, instead of the main service unit cgroup, and hence $MEMORY_PRESSURE_WATCH as set by the per-system service manager would simply be wrong.
2023-02-24 12:42:10 +03:00
MemoryPressureWatch=skip
Copy Permalink