summaryrefslogtreecommitdiffstats
path: root/units (follow)
Commit message (Collapse)AuthorAgeFilesLines
* units: drop OnFailure= from .target unitsZbigniew Jędrzejewski-Szmek2020-02-055-10/+0
| | | | | | See c80a9a33d04fb4381327a69ce929c94a9f1d0e6c, target units can't fail. I guess we need to figure out some replacement functionality, but at least let's avoid the warning from systemd for now.
* Merge pull request #14398 from poettering/mount-prepZbigniew Jędrzejewski-Szmek2020-02-042-0/+14
|\
| * units: introduce blockdev@.target for properly ordering mounts/swaps against ↵Lennart Poettering2020-01-212-0/+14
| | | | | | | | | | | | | | | | | | cryptsetup Let's hook it into both cryptsetup-generator and gpt-auto-generator with a shared implementation in generator.c Fixes: #8472
* | units: define RuntimeDirectory= in systemd-journald.serviceLennart Poettering2020-01-311-0/+2
| | | | | | | | | | It doesn't get us much, but makes the differences between the templated and non-templated versions a bit smaller.
* | units: sort settings in systemd-journald.service againLennart Poettering2020-01-311-1/+1
| |
* | journald: add ability to activate by varlink socketLennart Poettering2020-01-313-2/+21
| | | | | | | | | | | | | | | | | | If we have exit on idle, then operations such as "journalctl --namespace=foo --rotate" should work even if the journal daemon is currently not running. (Note that we don't do activation by varlink for the main instance of journald, I am not sure the deadlocks it might introduce are worth it)
* | journald: add exit on idleLennart Poettering2020-01-311-2/+0
| |
* | units: add unit files for instantiated journal daemonsLennart Poettering2020-01-313-0/+72
| |
* | home: add new systemd-homed service that can manage LUKS homesLennart Poettering2020-01-282-0/+38
| | | | | | | | Fixes more or less: https://bugs.freedesktop.org/show_bug.cgi?id=67474
* | unit: add AF_ALG to systemd-networkd.serviceYu Watanabe2020-01-281-1/+1
| | | | | | | | networkd uses khash, and khash requires AF_ALG.
* | units: add unit file for systemd-repart to automatically run at bootLennart Poettering2020-01-202-0/+27
|/
* units: drop full paths for utilities in $PATHZbigniew Jędrzejewski-Szmek2020-01-2026-77/+65
| | | | | | | This makes things a bit simpler and the build a bit faster, because we don't have to rewrite files to do the trivial substitution. @rootbindir@ is always in our internal $PATH that we use for non-absolute paths, so there should be no functional change.
* userdbd: add new service that can merge userdb queries from multiple clientsLennart Poettering2020-01-153-0/+63
|
* units: tweaks to modprobe@.serviceLennart Poettering2020-01-071-1/+4
| | | | | | | | | | | | Let's use uppercase wording in the description string, like we usually do. Let's allow using this service in early boot. If it's pulled into the initial transaction it's better to finish loading this before sysinit.target. Don't bother with this in containers that lack CAP_SYS_MODULE
* units: Split modprobing out into a separate service unitIain Lane2020-01-074-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | Devices referred to by `DeviceAllow=` sandboxing are resolved into their corresponding major numbers when the unit is loaded by looking at `/proc/devices`. If a reference is made to a device which is not yet available, the `DeviceAllow` is ignored and the unit's processes cannot access that device. In both logind and nspawn, we have `DeviceAllow=` lines, and `modprobe` in `ExecStartPre=` to load some kernel modules. Those kernel modules cause device nodes to become available when they are loaded: the device nodes may not exist when the unit itself is loaded. This means that the unit's processes will not be able to access the device since the `DeviceAllow=` will have been resolved earlier and denied it. One way to fix this would be to re-evaluate the available devices and re-apply the policy to the cgroup, but this cannot work atomically on cgroupsv1. So we fall back to a second approach: instead of running `modprobe` via `ExecStartPre`, we move this out to a separate unit and order it before the units which want the module. Closes #14322. Fixes: #13943.
* network: bump netlink receive buffer size to 128MYu Watanabe2020-01-021-1/+1
| | | | Prompted by #14417.
* Revert "Drop dbus activation stub service"Lennart Poettering2019-12-201-0/+3
| | | | | | | | | | | | | | | This reverts commit 07125d24eedb71693b3bf2b1f0730cd01aaac2dd. In contrast to what is claimed in #13396 dbus-broker apparently does care for the service file to be around, and otherwise will claim "Service Not Activatable" in the time between systemd starting up the broker and connecting to it, which the stub service file is supposed to make go away. Reverting this makes the integration test suite pass again on host with dbus-broker (i.e. current Fedora desktop). Tested with dbus-broker-21-6.fc31.x86_64.
* Revert "cryptsetup: umount encrypted devices before detaching it during ↵Zbigniew Jędrzejewski-Szmek2019-12-192-2/+0
| | | | | | | | | | | | | shutdown" This reverts commit 362c378291e85df3e00aaad491d1e08233ad127f. This commit introduced an ordering loop: remote-cryptsetup.target was both before and after remote-fs-pre.target. It also globally ordered all cryptsetup volumes before all mounts. Such global ordering is problematic if people have stacked storage. Let's look for a different solution. See https://github.com/systemd/systemd/pull/14378#discussion_r359460109.
* initrd: make udev cleanup service confict trigger and settle tooDimitri John Ledkov2019-12-171-2/+2
| | | | | | | | Otherwise, systemd-udev-trigger|settle.service that ran in the initrd may ramain active, and never re-run again from the system root. This is observed by forexample examining ESP with udevadm info, which in the initrd has all the ID_* variables, and none of them in fully booted system.
* cryptsetup: umount encrypted devices before detaching it during shutdownFranck Bui2019-12-052-0/+2
| | | | | | | This is done by ordering local-fs-pre.target and remote-fs-pre.target after cryptsetup.target and remote-cryptsetup.target respectively. Fixes: #8472
* crypsetup: introduce x-initrd.attach optionFranck Bui2019-12-052-0/+14
| | | | | | | | | | | | | | | | | This option is an indication for PID1 that the entry in crypttab is handled by initrd only and therefore it shouldn't interfer during the usual start-up and shutdown process. It should be primarily used with the encrypted device containing the root FS as we want to keep it (and thus its encrypted device) until the very end of the shutdown process, i.e. when initrd takes over. This option is the counterpart of "x-initrd.mount" used in fstab. Note that the slice containing the cryptsetup services also needs to drop the usual shutdown dependencies as it's required by the cryptsetup services. Fixes: #14224
* systemd-tmpfiles: don't install timer when service isn't installed eitherPascal de Bruijn2019-11-221-1/+1
| | | | | Fixes: systemd-tmpfiles-clean.timer: Refusing to start, unit systemd-tmpfiles-clean.service to trigger not loaded.
* bootctl: make 'random-seed' handle inability to write system token EFI ↵Lennart Poettering2019-11-211-1/+1
| | | | | | | | | | | | | | | | | variable gracefully Apparently some firmwares don't allow us to write this token, and refuse it with EINVAL. We should normally consider that a fatal error, but not really in the case of "bootctl random-seed" when called from the systemd-boot-system-token.service since it's called as "best effort" service after boot on various systems, and hence we shouldn't fail loudly. Similar, when we cannot find the ESP don't fail either, since there are systems (arch install ISOs) that carry a boot loader capable of the random seed logic but don't mount it after boot. Fixes: #13603
* units: set ProtectKernelLogs=yes on relevant unitsKevin Kuehler2019-11-1513-0/+13
| | | | | | We set ProtectKernelLogs=yes on all long running services except for udevd, since it accesses /dev/kmsg, and journald, since it calls syslog and accesses /dev/kmsg.
* meson: allow WatchdogSec= in services to be configuredZbigniew Jędrzejewski-Szmek2019-10-2515-15/+15
| | | | | | | | | | | | | | | | As discussed on systemd-devel [1], in Fedora we get lots of abrt reports about the watchdog firing [2], but 100% of them seem to be caused by resource starvation in the machine, and never actual deadlocks in the services being monitored. Killing the services not only does not improve anything, but it makes the resource starvation worse, because the service needs cycles to restart, and coredump processing is also fairly expensive. This adds a configuration option to allow the value to be changed. If the setting is not set, there is no change. My plan is to set it to some ridiculusly high value, maybe 1h, to catch cases where a service is actually hanging. [1] https://lists.freedesktop.org/archives/systemd-devel/2019-October/043618.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1300212
* networkd: use SIGUSR2 to do a restartZbigniew Jędrzejewski-Szmek2019-10-021-0/+1
| | | | | | | The code supports SIGTERM and SIGINT to termiante the process. It would be possible to reporpose one of those signals for the restart operation, but I think it's better to use a completely different signal to avoid misunderstandings.
* units: make systemd-binfmt.service easier to work with no autofsZbigniew Jędrzejewski-Szmek2019-09-252-0/+4
| | | | | | | | | | | | | | | | See https://bugzilla.redhat.com/show_bug.cgi?id=1731772: when autofs4 is disabled in the kernel, proc-sys-fs-binfmt_misc.automount is not started, so the binfmt_misc module is never loaded. If we added a dependency on proc-sys-fs-binfmt_misc.mount to systemd-binfmt.service, things would work even if autofs4 was disabled, but we would unconditionally pull in the module and mount, which we don't want to do. (Right now we ony load the module if some binfmt is configured.) But let's make it easier to handle this case by doing two changes: 1. order systemd-binfmt.service after the .mount unit (so that the .service can count on the mount if both units are pulled in, even if .automount is skipped) 2. add [Install] section to the service unit. This way the user can do 'systemctl enable proc-sys-fs-binfmt_misc.mount' to get the appropriate behaviour.
* unit: add ExecReload= in systemd-udevd.serviceYu Watanabe2019-09-171-0/+1
|
* Drop dbus activation stub serviceMichael Biebl2019-08-301-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | This fixes the following problem: > At the very end of the boot, just after the first user logs in > (usually using sddm / X) I get the following messages in my logs: > Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 > Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 These messages are caused by the "stub" service files that systemd installs. It installed them because early versions of systemd activation required them to exist. Since dbus 1.11.0, a dbus-daemon that is run with --systemd-activation automatically assumes that o.fd.systemd1 is an activatable service. As a result, with a new enough dbus version, /usr/share/dbus-1/services/org.freedesktop.systemd1.service and /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service should become unnecessary, and they can be removed. dbus 1.11.0 was released 2015-12-02. Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914015
* journald: slightly bump OOM adjust for journald (#13366)Lennart Poettering2019-08-222-0/+2
| | | | | | | | | | | | | | If logging disappears issues are hard to debug, hence let's give journald a slight edge over other services when the OOM killer hits. Here are the special adjustments we now make: systemd-coredump@.service.in OOMScoreAdjust=500 systemd-journald.service.in OOMScoreAdjust=-250 systemd-udevd.service.in OOMScoreAdjust=-1000 (i.e. the coredump processing is made more likely to be killed on OOM, and udevd and journald are less likely to be killed)
* Rename tmpfiles.d/kmod.conf to static-nodes.confZbigniew Jędrzejewski-Szmek2019-08-191-2/+2
| | | | | It is generated using kmod, but apart from that doesn't have much to do with kmod.
* unit: drop Before=sysinit.target from systemd-random-seed.serviceYu Watanabe2019-08-051-1/+1
| | | | | | | | | | | | | Follow-up for 26ded55709947d936634f1de0f43dcf88f594621. The commit says, > Note that with this change sysinit.target (and thus early boot) is NOT systematically delayed until the entropy pool is initialized, But the dependency was not dropped. This was found by David Seifert (@SoapGentoo).
* unit: make logind can access ESPYu Watanabe2019-08-031-0/+1
| | | | | | | Fixes the following error: ``` logind[601]: Failed to open file system "/dev/block/259:1": Operation not permitted ```
* unit: rename initrd-network-generator.service -> ↵Yu Watanabe2019-07-292-2/+5
| | | | systemd-network-generator.service
* units: use symbolic exit code namesZbigniew Jędrzejewski-Szmek2019-07-295-5/+5
| | | | | (nspawn uses 133 which doesn't have a name. That's reasonable, because there's less chance of conflict with a return value from the payload.)
* random-seed: rework systemd-random-seed.service substantiallyLennart Poettering2019-07-251-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes two major changes to the way systemd-random-seed operates: 1. We now optionally credit entropy if this is configured (via an env var). Previously we never would do that, with this change we still don't by default, but it's possible to enable this if people acknowledge that they shouldn't replicate an image with a contained random seed to multiple systems. Note that in this patch crediting entropy is a boolean thing (unlike in previous attempts such as #1062), where only a relative amount of bits was credited. The simpler scheme implemented here should be OK though as the random seeds saved to disk are now written only with data from the kernel's entropy pool retrieved after the pool is fully initialized. Specifically: 2. This makes systemd-random-seed.service a synchronization point for kernel entropy pool initialization. It was already used like this, for example by systemd-cryptsetup-generator's /dev/urandom passphrase handling, with this change it explicitly operates like that (at least systems which provide getrandom(), where we can support this). This means services that rely on an initialized random pool should now place After=systemd-random-seed.service and everything should be fine. Note that with this change sysinit.target (and thus early boot) is NOT systematically delayed until the entropy pool is initialized, i.e. regular services need to add explicit ordering deps on this service if they require an initialized random pool. Fixes: #4271 Replaces: #10621 #4513
* units: automatically initialize the system token if that makes senseLennart Poettering2019-07-252-0/+36
|
* Merge pull request #13144 from poettering/nspawn-modprobeZbigniew Jędrzejewski-Szmek2019-07-252-0/+4
|\ | | | | nspawn modprobe fixes
| * units: make sure logind can properly reference drm char classLennart Poettering2019-07-231-0/+2
| | | | | | | | Similar to the previous fix.
| * nspawn: explicitly load units beforehand so that DeviceAllow= syntax worksLennart Poettering2019-07-231-0/+2
| | | | | | | | | | | | Yuck, but I don't see any prettier solution. Fixes: #13130
* | units: add initrd-network-generator.serviceYu Watanabe2019-07-252-0/+18
| |
* | Revert "timesyncd: add Conflicts for ntpd and chronyd"Lennart Poettering2019-07-241-1/+0
| | | | | | | | | | | | | | | | | | This reverts commit 971a7a1526a6c1d5cb439a8a41dc65ccd4e3a66f. These unit names are typically different on distributions, let's not hardcode those. Stuff like this should probably live in the distro RPM/.deb, but not upstream, where we should be distro agnostic and agnostic to other higher level packages like this.
* | timesyncd: add Conflicts for ntpd and chronydZbigniew Jędrzejewski-Szmek2019-07-221-0/+1
|/ | | | | | | | Users might end up with more than one of those service enabled, through admin mistake, or broken installation scriptlets, or whatever. On my machine, I had both chronyd and timesyncd happilly running at the same time. If more than one is enabled, it's better to have just one running. Adding Conflicts will make the issue more visible in logs too.
* pstore: run only when /sys/fs/pstore is not emptyYu Watanabe2019-07-221-0/+1
|
* pstore: Tool to archive contents of pstoreEric DeVolder2019-07-192-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
* units: add SystemCallErrorNumber=EPERM to systemd-portabled.serviceLennart Poettering2019-07-081-0/+1
| | | | | | We use that on all other services, and hence should here too. Otherwise the service will be killed with SIGSYS when doing something not whitelisted, which is a bit crass.
* units: deny access to block devicesTopi Miettinen2019-06-204-0/+8
| | | | | | While the need for access to character devices can be tricky to determine for the general case, it's obvious that most of our services have no need to access block devices. For logind and timedated this can be tightened further.
* Merge pull request #12424 from poettering/logind-brightnessZbigniew Jędrzejewski-Szmek2019-06-121-0/+1
|\ | | | | logind: add SetBrightness() bus call as minimal API for setting "leds" and "backlight" kernel class device brightness
| * logind: make sure the service gets access to the linger directoryLennart Poettering2019-05-241-0/+1
| | | | | | | | Fixes: #12401
* | Drop no longer needed halt-local.service.inMichael Biebl2019-06-051-22/+0
|/ | | | Follow-up for commit 44508946534eee032927c263b79464832656dd6e.