systemd/units/systemd-tmpfiles-setup.service.in

#  SPDX-License-Identifier: LGPL-2.1+
#
#  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]
Description=Create Volatile Files and Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=local-fs.target systemd-sysusers.service systemd-journald.service
Before=sysinit.target shutdown.target
RefuseManualStop=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=@rootbindir@/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
SuccessExitStatus=65 73
Add SPDX license headers to unit files 2017-11-18 19:35:03 +03:00			`# SPDX-License-Identifier: LGPL-2.1+`
			`#`
units: ship unit file for systemd-tmpfiles by default 2010-09-29 03:30:41 +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`
units: ship unit file for systemd-tmpfiles by default 2010-09-29 03:30:41 +04:00			`# (at your option) any later version.`

			`[Unit]`
tmpfiles: introduce the concept of unsafe operations Various operations done by systemd-tmpfiles may only be safely done at boot (e.g. removal of X lockfiles in /tmp, creation of /run/nologin). Other operations may be done at any point in time (e.g. setting the ownership on /{run,var}/log/journal). This distinction is largely orthogonal to the type of operation. A new switch --unsafe is added, and operations which should only be executed during bootup are marked with an exclamation mark in the configuration files. systemd-tmpfiles.service is modified to use this switch, and guards are added so it is hard to re-start it by mistake. If we install a new version of systemd, we actually want to enforce some changes to tmpfiles configuration immediately. This should now be possible to do safely, so distribution packages can be modified to execute the "safe" subset at package installation time. /run/nologin creation is split out into a separate service, to make it easy to override. https://bugzilla.redhat.com/show_bug.cgi?id=1043212 https://bugzilla.redhat.com/show_bug.cgi?id=1045849 2013-12-21 05:25:39 +04:00			`Description=Create Volatile Files and Directories`
man: link systemd-tmpfiles-setup-dev.service 2013-04-23 11:56:32 +04:00			`Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)`
units: ship unit file for systemd-tmpfiles by default 2010-09-29 03:30:41 +04:00			`DefaultDependencies=no`
units: rework systemd-random-seed-{load,save}.service to be a single service That way ordering it with MountsRequiredFor= works properly, as this no longer results in mount units start requests to be added to the shutdown transaction that conflict with stop requests for the same unit. 2013-05-16 00:38:51 +04:00			`Conflicts=shutdown.target`
tmpfiles: Order tmpfiles-setup after journald systemd-tmpfiles-setup.service needs to be ordered after systemd-journald.service, so entries in /run/log/journal are already created when systemd-tmpfiles tries to adjust its permissions. This is specially problematic for setups using a volatile journal where the initrd does not ship a machine-id (i.e. OSTree-based systems), where logs from the initrd will be inaccessible for users in the systemd-journal group. It also has a side effect of `journalctl --user` failing with "No journal files were opened due to insufficient permissions". Fixes #10128. 2018-09-19 01:03:54 +03:00			`After=local-fs.target systemd-sysusers.service systemd-journald.service`
units: move a couple of units from base.target to sysinit.target 2010-11-19 18:24:21 +03:00			`Before=sysinit.target shutdown.target`
tmpfiles: introduce the concept of unsafe operations Various operations done by systemd-tmpfiles may only be safely done at boot (e.g. removal of X lockfiles in /tmp, creation of /run/nologin). Other operations may be done at any point in time (e.g. setting the ownership on /{run,var}/log/journal). This distinction is largely orthogonal to the type of operation. A new switch --unsafe is added, and operations which should only be executed during bootup are marked with an exclamation mark in the configuration files. systemd-tmpfiles.service is modified to use this switch, and guards are added so it is hard to re-start it by mistake. If we install a new version of systemd, we actually want to enforce some changes to tmpfiles configuration immediately. This should now be possible to do safely, so distribution packages can be modified to execute the "safe" subset at package installation time. /run/nologin creation is split out into a separate service, to make it easy to override. https://bugzilla.redhat.com/show_bug.cgi?id=1043212 https://bugzilla.redhat.com/show_bug.cgi?id=1045849 2013-12-21 05:25:39 +04:00			`RefuseManualStop=yes`
units: ship unit file for systemd-tmpfiles by default 2010-09-29 03:30:41 +04:00
			`[Service]`
			`Type=oneshot`
			`RemainAfterExit=yes`
tmpfiles: rename --unsafe to --boot As suggested by Kay, it is better to describe what is done, not what might happen. 2013-12-30 22:00:38 +04:00			`ExecStart=@rootbindir@/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev`
tmpfiles: ignore "operational" errors during setup We still get the errors logged, but we don't fail the service. This is better for users because rerunning tmpfiles-setup.service a second time is dangerous (c.f. cd9f5b68ce08375eb1d68a4ddaa7a24a5092d7ba). Note that this only touches sd-tmpfiles-setup.service and sd-tmpfiles-setup-dev.service. sd-tmpfiles-clean.service is as before. https://bugzilla.redhat.com/show_bug.cgi?id=1539341 2018-03-29 17:37:21 +03:00			`SuccessExitStatus=65 73`