shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-21 13:34:21 +03:00
Code
main
systemd/units/user@.service.in

35 lines
1.0 KiB
SYSTEMD
Raw Permalink 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)
logind-user: track user started/stopping state through user-runtime-dir@.service Before #30884, the user state is tied to user@.service (user service manager). However, #30884 introduced sessions that need no manager, and we can no longer rely on that. Consider the following situation: 1. A 'background-light' session '1' is created (i.e. no user service manager is needed) 2. Session '1' scope unit pulls in user-runtime-dir@.service 3. Session '1' exits. A stop job is enqueued for user-runtime-dir@.service due to StopWhenUnneeded=yes 4. At the same time, another session '2' which requires user manager is started. However, session scope units have JobMode=fail, therefore the start job for user-runtime-dir@.service that was pulled in by session '2' scope job is deleted as it conflicts with the stop job. We want session scope units to continue using JobMode=fail, but we still need the dependencies to be started correctly, i.e. explicitly requested by logind beforehand. Therefore, let's stop using StopWhenUnneeded=yes for user-runtime-dir@.service, and track users' `started` and `stopping` state based on that when user@.service is not needed. Then, for every invocation of user_start(), we'll recheck if we need the service manager and start it if so. Also, the dependency type on user-runtime-dir@.service from user@.service is upgraded to `BindsTo=`, in order to ensure that when logind stops the former, the latter is stopped as well.
2024-01-13 21:38:11 +03:00
BindsTo=user-runtime-dir@%i.service
units: add dep on systemd-logind.service by user@.service Let's make sure logind is accessible by the time user@.service runs, and that logind stays around as long as it does so. Addresses an issue reported here: https://lists.freedesktop.org/archives/systemd-devel/2024-June/050468.html This addresses an issued introduced by 278e815bfa3e4c2e3914e00121c37fc844cb2025, which dropped the a dependency from user@.service systemd-user-sessions.service without replacement. While dropping that dependency does make sense, it should have been replaced with the weaker dependency on systemd-logind.service, hence fix that now. user@.service is after all a logind concept, hence logind really should be around for its lifetime. systemd-user-sessions.service is a later milestone that only really should apply to regular users (not root), hence it's too strong a requirement.
2024-07-01 13:40:33 +03:00
After=systemd-logind.service user-runtime-dir@%i.service dbus.service systemd-oomd.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
Drop split-usr and unmerged-usr support As previously announced, execute order 66: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html The meson options split-usr, rootlibdir and rootprefix become no-ops that print a warning if they are set to anything other than the default values. We can remove them in a future release.
2023-06-12 04:15:19 +03:00
ExecStart={{LIBEXECDIR}}/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
units/{user,capsule}@.service: issue daemon-reexec when notify-reloading Closes #28367 (but not really in the exact form, see below) We have the problem of restarting all user manager instances after upgrade. Current approaches involve systemctl kill with SIGRTMIN+25, which is async and feels rather ugly [1][2]; or systemctl --machine=user@ --user, which requires entering each user session. Neither is particularly elegant. Instead, let's just signal daemon-reexec when user@.service is reloaded from system manager. Our long goal of dropping daemon-reload in favor of reexec (see TODO) is unlikely to happen due to user dbus restrictions, but here the synchronization is done via READY=1. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/main/systemd.install?ref_type=heads#L37 [2] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.postinst#L24 #28367 would not really work for us now I come to think about it, because all processes will be reparented to pid1 as soon as original user manager process exits. This alternative approach seems good enough for our use case.
2024-10-10 22:32:17 +03:00
# Reexecute the manager on service reload, instead of reloading.
# This provides a synchronous method for restarting all user manager
# instances after upgrade.
ReloadSignal=RTMIN+25
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