summaryrefslogtreecommitdiff
path: root/units
Commit message (Collapse)AuthorAgeFilesLines
* sysusers: allow defining additional sysusers lines via credentialsLennart Poettering2022-07-161-1/+5
|
* sysctl: also process sysctl requests via the "sysctl.extra" credentialLennart Poettering2022-07-141-0/+1
|
* logind: don't delay login for root even if systemd-user-sessions.service is ↵Franck Bui2022-07-126-3/+33
| | | | | | | | | | | | | | | | | | | | | | | 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.
* user: delegate cpu controller, assign weights to user slicesZbigniew Jędrzejewski-Szmek2022-07-054-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* tree-wide: link to docs.kernel.org for kernel documentationnl67202022-07-048-8/+8
| | | | | | | https://www.kernel.org/ links to https://docs.kernel.org/ for the documentation. See https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=ebc1c372850f249dd143c6d942e66c88ec610520 These URLs are shorter and nicer looking.
* tree-wide: use html links for kernel docsZbigniew Jędrzejewski-Szmek2022-07-025-5/+5
| | | | Instead of using "*.txt" as reference name, use the actual destination title.
* unit: prioritize module devicesYu Watanabe2022-07-011-1/+1
| | | | | | | | Also, prioritize tty and network devices. Follow-up for 2336bde96420475ccb054326f27290fa0228f27d Fixes #23850.
* units: add IgnoreOnIsolate=yes to systemd-journald tooZbigniew Jędrzejewski-Szmek2022-07-013-6/+11
| | | | | | | | | We already had it on the socket units, so it's possible that systemd-journald.service would be stopped and then restarted when trafic hits the sockets when something logs. Let's not try to stop it. It is supposed to run until the end and be eventually killed in the final killing spree. This might (or not) help with #23287.
* units: remove the restart limit on the modprobe@.serviceAlban Bedel2022-06-211-0/+1
| | | | | | | | | | | | | They are various cases where the same module might be repeatedly loaded in a short time frame, for example if a service depending on a module keep restarting, or if many instances of such service get started at the same time. If this happend the modprobe@.service instance will be marked as failed because it hit the restart limit. Overall it doesn't seems to make much sense to have a restart limit on the modprobe service so just disable it. Fixes: #23742
* pstore: Run after modules are loadedAlexander Graf2022-06-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | The systemd-pstore service takes pstore files on boot and transfers them to disk. It only does it once on boot and only if it finds any. The typical location of the pstore on modern systems is the UEFI variable store. Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the UEFI variable store is only available on boot after the respective module is loaded. In most situations, the pstore service gets loaded before the UEFI pstore, so we don't get to transfer logs. Instead, they accumulate, filling up the pstore over time, potentially breaking the UEFI variable store. Let's add a service dependency on any kernel module that can provide a pstore to ensure we only scan for pstate after we can actually see pstate. I have seen live occurences of systems breaking because we did not erase the pstates and ran out of UEFI nvram space. Fixes https://github.com/systemd/systemd/issues/18540
* tree-wide: replace obsolete wiki links with systemd.io/manpagesBenjamin Franzke2022-05-213-3/+3
| | | | | | | | | | | All wiki pages that contain a deprecation banner pointing to systemd.io or manpages are updated to point to their replacements directly. Helpful command for identification of available links: git grep freedesktop.org/wiki | \ sed "s#.*\(https://www.freedesktop.org/wiki[^ $<'\\\")]*\)\(.*\)#\\1#" | \ sort | uniq
* units: remove spurious empty lineLennart Poettering2022-05-041-1/+0
|
* meson: also allow setting GIT_VERSION via templatesZbigniew Jędrzejewski-Szmek2022-04-051-1/+1
| | | | | | | | | GIT_VERSION is not available as a config.h variable, because it's rendered into version.h during builds. Let's rework jinja2 rendering to also parse version.h. No functional change, the new variable is so far unused. I guess this will make partial rebuilds a bit slower, but it's useful to be able to use the full version string.
* unit: make systemd-udev-trigger.service use --prioritized-subsystemYu Watanabe2022-03-221-2/+1
| | | | Replaces #19637 and #22643.
* spelling: weekday names are capitalizedZbigniew Jędrzejewski-Szmek2022-03-211-1/+1
|
* unit: add units for new "systemd-sysupdate" toolLennart Poettering2022-03-195-0/+108
| | | | | | These unit (if enabled) will try to update the OS in regular intervals. Moreover, every day in the early morning this will attempt to reboot the system if there's a newer version installed than running.
* udev: run the main process, workers, and spawned commands in /udev subcgroupYu Watanabe2022-03-171-0/+1
| | | | | | | | And enable cgroup delegation for udevd. Then, processes invoked through ExecReload= are assigned .control subcgroup, and they are not killed by cg_kill(). Fixes #16867 and #22686.
* units: fix factory-reset.target descriptionVivien Didelot2022-03-141-1/+1
| | | | | | | | | | | | | | | The current description for the factory reset target does not add any value and doesn't respect the definition of the related property as described in systemd.unit(5). Starting the target currently results in the following log: [ 11.139174] systemd[1]: Reached target Target that triggers factory reset. Does nothing by default.. [ OK ] Reached target Target that…set. Does nothing by default.. Simply update the target description to "Factory Reset". Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
* units: drop After=systemd-resolved.service from systemd-nspawn@.serviceLennart Poettering2022-02-241-1/+1
| | | | | resolved is now started as part of early boot hence we need no explicit ordering anymore.
* units: move resolved to sysinit.target (from basic.target)Lennart Poettering2022-02-241-2/+2
| | | | | | | | | | | | | | | | | | 79a67f3ca4d32c37b5e754501852a85eae908a6a pulled systemd-resolved.service in from basic.target instead of multi-user.target, i.e. the idea is to make it an early boot service, instead of a regular service. However, early boot services are supposed to be in sysinit.target, not basic.target (the latter is just one that combines the early boot services in sysinit.target, the sockets in sockets.targt, the mounts in local-fs.target and so on into one big target). Also, the comit actually didn't add a synchronization point, i.e. not Before=, so that the whole thing was racy. Let's fix all that. Follow-up for 79a67f3ca4d32c37b5e754501852a85eae908a6a
* unit: escape %Yu Watanabe2022-02-231-1/+1
| | | | Fixes #22601.
* units: drop After=systemd-networkd.service from systemd-resolved.serviceLennart Poettering2022-02-231-1/+1
| | | | | | | | | | | This ordering existed since resolved was first created, but there should not be any need to order the two services against each other, as resolved should be able to pick up networkd DNS metadata either way (as it works with inotify in /run). Let's drop this hence, and not cargo-cult this to eternity Also see: https://github.com/systemd/systemd/pull/22389#issuecomment-1045978403
* units: we need systemd-journald.service from systemd-journal-flush.serviceLennart Poettering2022-02-021-0/+1
| | | | | | | | | | | | This is a follow-up for d5ee050ffc9d413253932d9340ade8c8fb111092, and reintroduces a requirement dep from systemd-journal-flush.service onto systemd-journald.service, but a weaker one than originally: a Wants= one instead of a Requires= one. Why? Simply because the service issues an IPC call to the journald, hence it should pull it in. (Note that socket activation doesn't happen for the Varlink socket it uses, hence we should pull in the service itself.)
* unit: introduce wait-online@.service for specific interfaceYu Watanabe2022-01-282-0/+26
| | | | | | This should be useful when a host has multiple interfaces. Inspired by #22246.
* units: don't install dbus-org.freedesktop.oom1.service aliasMichael Biebl2022-01-121-2/+1
| | | | | | | | | | | The systemd-oomd.service unit contains [Install] WantedBy=multi-user.target Alias=dbus-org.freedesktop.oom1.service which means the symlink is supposed to be created dynamically when the service is enabled.
* units: start systemd-resolved in basic.targetZbigniew Jędrzejewski-Szmek2022-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | In the olden days systemd-resolved used dbus and it didn't make sense to start it before dbus which is started fairly late. But we have mostly ported resolved over to varlink. The queries from nss-resolve are done using varlink, so name resolution can work without dbus. resolvectl still uses dbus, so e.g. 'resolvectl query' will not work, but by starting systemd-resolved earlier we're not making this any worse. If systemd-resolved is started after dbus, it registers the name and everything is fine. If it is started before dbus, it'll watch for the dbus socket and connect later. So it should be fine to start systemd-resolved earlier. (If dbus is stopped and restarted, unfortunately systemd-resolved does not reconnect. This seems to be a small bug: since our daemons know how to watch for dbus.socket, they could restart the watch if they ever lose the connection. But this scenario shouldn't happen in normal boot, and restarting dbus is not supported anyway.) Moving the start earlier the following advantages: - name resolution becomes availabe earlier, in particular for synthesized hostnames even before the network is up. - basic.target is part of initrd.target, so systemd-resolved will get started in the initrd if installed. This is required for nfs-root when the server is specified using a name (https://bugzilla.redhat.com/show_bug.cgi?id=2037311).
* homed: stop before stopping dbusMarkus Weippert2022-01-071-1/+1
| | | | | | | | | Otherwise, systemd-homed-active.service will fail to deactivate all homes because homectl can no longer talk to homed if dbus stops first. As a result, /home cannot be umounted. Doing this on systemd-homed-active.service instead works as well, but systemd-homed will exit 1 if dbus is already shut down.
* logind: add a comment with a reminder why we don't use ProtrectProc=Luca Boccassi2021-12-171-0/+1
| | | | Follow-up for https://github.com/systemd/systemd/pull/21785
* logind: allow to read /procLudwig Nussel2021-12-171-1/+0
| | | | | User name and tty are used for wall messages. For that to work logind must be able to poke around in proc entries of other processes.
* units: enable systemd-network-generator by defaultZbigniew Jędrzejewski-Szmek2021-12-161-0/+4
| | | | | | It is used by udevd and networkd. Since udevd is enabled statically, let's also change the preset to "on". networkd is opt-in, so let's pull in the generator when enabling networkd too.
* meson: build network-generator unconditionallyYu Watanabe2021-12-161-1/+1
| | | | The service also generates .link files for udevd.
* unit: run network-generator before starting udevdYu Watanabe2021-12-161-1/+1
| | | | | Otherwise, .link files generated by the service may not be loaded by udevd.
* Bump the max number of inodes for /tmp to a million tooZbigniew Jędrzejewski-Szmek2021-12-091-1/+1
| | | | | | Fixes #21626. (The bug report talks about /run, but the issue is actually with /tmp.) People use /tmp for various things that fit in memory, e.g. unpacking packages, and 400k is not much. Let's raise is a bit.
* units/systemd-udevd: allow bpf() syscallMaciek Borzecki2021-12-071-1/+1
| | | | | | | | | | | | | | | | | Programs run by udev triggers may need to execute the bpf() syscall. Even more so, since on a cgroup v2 system, the only way to set up device access filtering is to install a BPF program on the cgroup in question and one way of passing data to such program is through BPF maps, which can only be access using the bpf() syscall. One such use case was identified in RHBZ#2025264 related to snap-device-helper, and led to RHBZ#2027627 being filed. Unfortunately there is no finer grained control over what gets passed in the syscall, so just enable bpf() and leave fine grained mediation to other security layers (eg. SELinux). Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2027627 Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
* journal: don't remove the flushed flag when journald is stoppedFranck Bui2021-12-061-1/+0
| | | | | | | | | | | | | | | | | | | Due to the fact that systemd-journal-flush.service has "Requires=systemd-journald.service", this service is stopped too when journald is requested to do so. However stopping systemd-journal-flush.service implies that journald relinquishes /var hence implicitly switching back to the volatile storage mode and removing /run/systemd/journal/flushed. If journald is started afterwards, it will run in volatile storage mode regardless of the value of 'Storage=' as it believes now that /var is not yet ready (because the flushed flag is missing). Because this flag is mainly an indication for journald that the initialization of /var/log/journal (during the boot process) has been done, systemd-journal-flush.service shouldn't be tied to the state of journald itself but to the state of /var/log/journal, hence to the state of the system.
* coredump: analyze object with libdwelf in forked processLuca Boccassi2021-11-301-2/+1
| | | | | | | Parsing objects is risky as data could be malformed or malicious, so avoid doing that from the main systemd-coredump process and instead fork another process, and set it to avoid generating core files itself.
* units: delay binfmt processing until after local-fs.targetZbigniew Jędrzejewski-Szmek2021-11-161-0/+1
| | | | | | | | | Users may use rules that refer to binaries e.g. in /opt or /usr/local, and those directories may be separate mount points. We don't need the binfmt rules in early boot, so let's delay the service so that we can rely on the full local filesystem being visible. Fixes #21178.
* units: relax sandbox so that uidmap stuff can workLennart Poettering2021-11-161-2/+2
| | | | | | | The uidmap suff requires additional caps and userns to work in some cases. Allow it. Follow-up for: 1147c538bbb6a2d3d5ba2e40f1437bcbeb22b33e
* fsck: no emergency.target on nofail mountsScott Lamb2021-11-101-0/+2
| | | | | Also describe failure behavior more precisely in the manpage. Fixes #20237.
* build: preserve correct mode when generating files via jinja2Christian Brauner2021-11-081-2/+1
| | | | | | | | | When using "capture : true" in custom_target()s the mode of the source file is not preserved when the generated file is not installed and so needs to be tweaked manually. Switch from output capture to creating the target file and copy the permissions from the input file. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
* getty: Pass tty to use by agetty via stdinDaan De Meyer2021-11-054-4/+12
| | | | | | | If the tty arg is set to "-", agetty uses the stdin fd as the tty. Let's pass the tty this way so that we keep an fd open to the tty at all times. If all fd's to a tty are closed, the kernel might reset the tty which we want to avoid.
* Merge pull request #20902 from tasleson/integritysetup-generatorLennart Poettering2021-10-156-3/+32
|\ | | | | Add stand-alone dm integrity support
| * Add stand-alone dm-integrity supportTony Asleson2021-10-153-0/+29
| | | | | | | | | | | | | | This adds support for dm integrity targets and an associated /etc/integritytab file which is required as the dm integrity device super block doesn't include all of the required metadata to bring up the device correctly. See integritytab man page for details.
| * dm-verity: Remove usage of integrityTony Asleson2021-10-143-3/+3
| | | | | | | | | | | | There is a difference between dm-verity and dm-integrity. Remove usage of integrity from verity documentation in man pages and target files.
* | unit: networkd does not require AF_ALG anymoreYu Watanabe2021-10-151-1/+1
|/ | | | As khash is retired.
* units: run user service managers at OOM score adjustment 100Lennart Poettering2021-10-041-0/+1
| | | | | | | | | | | | | | | | | | | 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.
* tools: shellcheck-ify tool scriptsFrantisek Sumsal2021-09-301-0/+1
|
* unit: install the systemd-bless-boot.service only if we have gnu-efiFrantisek Sumsal2021-09-221-1/+1
| | | | Follow-up to #20591.
* Merge pull request #20690 from DaanDeMeyer/oomd-user-servicesLuca Boccassi2021-09-213-0/+24
|\ | | | | oom: Support for user services
| * oom: Add support for user unit ManagedOOM property updatesDaan De Meyer2021-09-203-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compared to PID1 where systemd-oomd has to be the client to PID1 because PID1 is a more privileged process than systemd-oomd, systemd-oomd is the more privileged process compared to a user manager so we have user managers be the client whereas systemd-oomd is now the server. The same varlink protocol is used between user managers and systemd-oomd to deliver ManagedOOM property updates. systemd-oomd now sets up a varlink server that user managers connect to to send ManagedOOM property updates. We also add extra validation to make sure that non-root senders don't send updates for cgroups they don't own. The integration test was extended to repeat the chill/bloat test using a user manager instead of PID1.
View Lorry Controller Status