summaryrefslogtreecommitdiff
path: root/units
Commit message (Collapse)AuthorAgeFilesLines
* units: set RestrictNamespaces=yes to networkd and resolvedYu Watanabe2018-05-102-0/+2
| | | | Closes #8949.
* meson: generate m4 preprocessor from config.h (#8914)Yu Watanabe2018-05-071-1/+1
|
* timesync: expose manager properties on busYu Watanabe2018-05-031-0/+1
|
* unit: tighten sandboxing for logindYu Watanabe2018-04-271-2/+2
|
* logind: split %t directory creation to a helper unitZbigniew Jędrzejewski-Szmek2018-04-253-0/+20
| | | | | | | | | | | | | | | 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.
* Use a dash-truncated drop-in for user-%j.slice configurationZbigniew Jędrzejewski-Szmek2018-04-252-0/+18
| | | | | | | | | | | | | | | | | | | This removes the UserTasksMax= setting in logind.conf. Instead, the generic TasksMax= setting on the slice should be used. Instead of a transient unit we use a drop-in to tweak the default definition of a .slice. It's better to use the normal unit mechanisms instead of creating units on the fly. This will also make it easier to start user@.service independently of logind, or set additional settings like MemoryMax= for user slices. The setting in logind is removed, because otherwise we would have two sources of "truth": the slice on disk and the logind config. Instead of trying to coordinate those two sources of configuration (and maintainer overrides to both), let's just convert to the new one fully. Right now now automatic transition mechanism is provided. logind will emit a hint when it encounters the setting, but otherwise it will be ignored. Fixes #2556.
* unit,meson: drop .in suffix if no substitution is required (#8740)Yu Watanabe2018-04-174-17/+3
|
* time-wait-sync: use watchfile to coordinate with timesyncdPeter A. Bigot2018-04-141-0/+1
| | | | | | | | | | | Systems that have an accurate real-time clock may have an initial unsynchronized time that is close enough to the synchronized time that the final adjustment doesn't trigger a waking "clock set" event. Have timesyncd touch a file in its runtime directory as a secondary signal for synchronization. Continue to support the timerfd-based trigger as a sufficient condition when the watchfile is not present. Closes issue #8683
* units: leave systemd-time-wait-sync disabled by defaultPeter A. Bigot2018-04-141-2/+1
| | | | Also mark its presence conditional on ENABLE_TIMESYNCD.
* fix url for binfmt documentation (#8720)guixxx2018-04-141-1/+2
| | | this file went unnoticed in PR #6223
* tree-wide: drop license boilerplateZbigniew Jędrzejewski-Szmek2018-04-062-26/+0
| | | | | | | | | | Files which are installed as-is (any .service and other unit files, .conf files, .policy files, etc), are left as is. My assumption is that SPDX identifiers are not yet that well known, so it's better to retain the extended header to avoid any doubt. I also kept any copyright lines. We can probably remove them, but it'd nice to obtain explicit acks from all involved authors before doing that.
* Merge pull request #8617 from keszybz/tmpfiles-relaxLennart Poettering2018-04-052-2/+2
|\ | | | | Do not exit with error when systemd-tmpfiles --boot fails
| * tmpfiles: ignore "operational" errors during setupZbigniew Jędrzejewski-Szmek2018-04-052-2/+2
| | | | | | | | | | | | | | | | | | | | 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
* | units: use `systemctl exit` to kill the user manager (#8648)Filipe Brandenburger2018-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | Use `systemctl --user --force exit` to implement the systemd-exit user service. This removes our dependence on an external `kill` binary and the concerns about whether they recognize SIGRTMIN+n by name or what their interpretation of SIGRTMIN is. Tested: `systemctl --user start systemd-exit.service` kills the `systemd --user` instance for my user.
* | units: initctl: move the fifo to /run/initctl to match sysvinitMike Gilbert2018-03-302-3/+3
|/ | | | | | The fifo location was moved in sysvinit-2.89. http://git.savannah.nongnu.org/cgit/sysvinit.git/commit/?id=80dbcf3de3c1b83aeaa713a8fe5b8d35d8649af2
* Fix description on suspend-then-hibernate units.Mario Limonciello2018-03-282-2/+2
| | | | Suspend; Idle into hibernate didn't make sense.
* Rename suspend-to-hibernate to suspend-then-hibernateMario Limonciello2018-03-283-5/+5
| | | | | Per some discussion with Gnome folks, they would prefer this name as it's more descriptive of what's happening.
* units: document why systemd-time-wait-sync.service conditions on ↵Lennart Poettering2018-03-221-0/+9
| | | | | CAP_SYS_TIME (#8555) As requested by @evverx in https://github.com/systemd/systemd/pull/8537#issuecomment-375122615
* units: disable systemd-time-sync-wait inside containers (#8537)Peter A. Bigot2018-03-221-0/+2
| | | Fixes #8535
* time-sync-wait: add service (#8494)Peter A. Bigot2018-03-212-0/+27
| | | | This one-shot service waits until the kernel time has been set to synchronized.
* units: Fix SuccessAction that belongs to [Unit] section not [Service] ↵Karol Augustin2018-03-181-1/+1
| | | | section (#8478)
* Introduce suspend-to-hibernate (#8274)Mario Limonciello2018-03-083-0/+37
| | | | | | | | | | | | | | Suspend to Hibernate is a new sleep method that invokes suspend for a predefined period of time before automatically waking up and hibernating the system. It's similar to HybridSleep however there isn't a performance impact on every suspend cycle. It's intended to use with systems that may have a higher power drain in their supported suspend states to prevent battery and data loss over an extended suspend cycle. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
* units: use SuccessAction=reboot where appropriate (#8335)Lennart Poettering2018-03-021-1/+1
| | | We should really use our own native concepts for rebooting.
* units: delegate "memory" instead of "cpu" by default for user instances (#8320)Franck Bui2018-03-011-1/+1
| | | | | | | | CPU accounting has a too bad impact on performance to be enabled by default. Therefore we should not delegate "cpu" for now. OTOH since commit e0c46a736412b79b94a21f8512a769b9212b9adf, memory accounting has been turned on for all units by default so it makes sense to delegate this controller by default.
* slice: system.slice should be perpetual like -.mountAlan Jenkins2018-02-042-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `-.mount` is placed in `system.slice`, and hence depends on it. `-.mount` is always active and can never be stopped. Therefore the same should be true of `system.slice`. Synthesize it as perpetual (unless systemd is running as a user manager). Notice we also drop `Before=slices.target` as unnecessary. AFAICS the justification for `perpetual` is to provide extra protection against unintentionally stopping every single service. So adding system.slice to the perpetual units is perfectly consistent. I don't expect this will (or can) fix any other problem. And the `perpetual` protection probably isn't formal enough to spend much time thinking about. I've just noticed this a couple of times, as something that looks strange. Might be a bit surprising that we have user.slice on-disk but not system.slice, but I think it's ok. `systemctl status system.slice` will still point you towards `man systemd.special`. The only detail is that the system slice disables `DefaultDependencies`. If you're worrying about how system shutdown works when you read `man systemd.slice`, I think it is not too hard to guess that system.slice might do this: > Only slice units involved with early boot > or late system shutdown should disable this option (Docs are great. I really appreciate the systemd ones).
* resolved.service: set DefaultDependencies=noDimitri John Ledkov2018-01-111-2/+4
| | | | | | | | | | | | | | On systems that only use resolved for name resolution, there are usecases that require resolved to be started before sysinit target, such that network name resolution is available before network-online/sysinit targets. For example, cloud-init for some datasources hooks into the boot process ahead of sysinit target and may need network name resolution at that point already. systemd-resolved already starts pretty early in the process, thus starting it slightly earlier should not have negative side effects. However, this depends on resolved ability to connect to system DBus once that is up.
* units: link up debug-generator documentation from debug-shell.serviceLennart Poettering2017-12-261-0/+1
|
* man: add a systemd-rc-local-generator(8) man pageLennart Poettering2017-12-261-0/+1
| | | | | | | Most importantly, let's highlight the differences to the rc-local behaviour in SysV. Fixes: #7703
* separate flags from shebangbleep_blop2017-12-251-1/+2
|
* nspawn: turn on watchdog logic for nspawn tooLennart Poettering2017-12-071-0/+1
| | | | It's a long-running daemon, and it's easy to enable, hence do it.
* units: delegate only "cpu" and "pids" controllers by default (#7564)Lennart Poettering2017-12-071-1/+1
| | | | | | | Now that we can configure which controllers to delegate precisely, let's limit wht we delegate to the user session: only "cpu" and "pids" as a minimal baseline. Fixes: #1715
* Hook up systemd-tmpfiles as user unitsZbigniew Jędrzejewski-Szmek2017-12-064-0/+68
| | | | | | | | | | | | | An explicit --user switch is necessary because for the user@0.service instance systemd-tmpfiles is running as root, and we need to distinguish that from systemd-tmpfiles running in systemd-tmpfiles*.service. Fixes #2208. v2: - restore "systemd-" prefix - add systemd-tmpfiles-clean.{service,timer}, systemd-setup.service to systemd-tmpfiles(8)
* units: use SuccessExitStatus to ignore syntax errors in tmpfilesZbigniew Jędrzejewski-Szmek2017-12-013-0/+3
| | | | | | | | | | | | | | | | | | | | | This makes sense from the point of view of the whole distribution: if there are some specific files that have syntax problems, or unknown users or groups, or use unsupported features, failing the whole service is not useful. In particular, services with tmpfiles --boot should not be started after boot. The premise of --boot is that there are actions which are only safe to do once during boot, because the state evolves later through other means and re-running the boot-time setup would destroy it. If services with --boot fail in the initial transaction, they would be re-run later on when a unit which (indirectly) depends on them is started, causing problems. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1507501. (If we had a mode where a service would at most run once, and would not be started in subsequent transactions, that'd be a good additional safeguard. Using ExecStart=-... is a bit like that, but it causes all failure to be ignored, which is too big of a hammer.)
* Add license headers and SPDX identifiers to meson.build filesZbigniew Jędrzejewski-Szmek2017-11-192-0/+34
| | | | | | | So far I avoided adding license headers to meson files, but they are pretty big and important and should carry license headers like everything else. I added my own copyright, even though other people modified those files too. But this is mostly symbolic, so I hope that's OK.
* Add SPDX license headers to unit filesZbigniew Jędrzejewski-Szmek2017-11-19159-0/+318
|
* core: make "tmpfs" dependencies on swapfs a "default" dep, not an "implicit"Lennart Poettering2017-11-101-0/+1
| | | | | | | | | | | | There should be a way to turn this logic of, and DefaultDependencies= appears to be the right option for that, hence let's downgrade this dependency type from "implicit" to "default, and thus honour DefaultDependencies=. This also drops mount_get_fstype() as we only have a single user needing this now. A follow-up for #7076.
* meson: do not create systemd-user-sessions.service if PAM is disabledYu Watanabe2017-10-311-1/+1
| | | | Fixes #7227.
* Merge pull request #7078 from keszybz/cryptsetup-netdev-fixesLennart Poettering2017-10-183-16/+6
|\ | | | | Cryptsetup _netdev fixes
| * units: make remote-cryptsetup.target also after cryptsetup-pre.targetZbigniew Jędrzejewski-Szmek2017-10-181-1/+1
| | | | | | | | | | This way people can order units before cryptsetup-pre.target and have them run before any cryptsetup-related stuff.
| * units: replace remote-cryptsetup-pre.target with remote-fs-pre.targetZbigniew Jędrzejewski-Szmek2017-10-173-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remote-cryptsetup-pre.target was designed as an active unit (that pulls in network-online.target), the opposite of remote-fs-pre.target (a passive unit, with individual provider services ordering itself before it and pulling it in, for example iscsi.service and nfs-client.target). To make remote-cryptsetup-pre.target really work, those services should be ordered before it too. But this would require updates to all those services, not just changes from systemd side. But the requirements for remote-fs-pre.target and remote-cryptset-pre.target are fairly similar (e.g. iscsi devices can certainly be used for both), so let's reuse remote-fs-pre.target also for remote cryptsetup units. This loses a bit of flexibility, but does away with the requirement for various provider services to know about remote-cryptsetup-pre.target.
| * units: add [Install] section to remote-cryptsetup.targetZbigniew Jędrzejewski-Szmek2017-10-131-0/+6
| | | | | | | | | | | | | | | | This makes this target the same as remote-fs.target in this regard. In practice it probably doesn't make that much difference, because all encrypted devices that are part of remote-fs.target (marked with _netdev) will be used for mount points, so they will be pulled in anyway individually, but with this change any such device will be configured, even if it is not pulled by any other unit.
* | mount: make sure we unmount tmpfs mounts before we deactivate swaps (#7076)Michal Sekletar2017-10-161-1/+0
|/ | | | | | | | In the past we introduced this property just for tmp.mount. However on todays systems usually there are many more tmpfs mounts. Most notably mounts backing XDG_RUNTIME_DIR for each user. Let's generalize what we already have for tmp.mount and implement the ordering After=swap.target for all tmpfs based mounts.
* unit: enable DynamicUser= for journal-uploadYu Watanabe2017-10-061-2/+1
|
* timesyncd: enable DynamicUser=Yu Watanabe2017-10-061-2/+1
|
* Merge pull request #6909 from sourcejedi/unitsLennart Poettering2017-10-057-9/+9
|\ | | | | Unit dependency fixes (and cleanups)
| * units: DefaultDependencies already implies conflict with shutdown.targetAlan Jenkins2017-09-301-2/+0
| | | | | | | | (and system-update.target does not have DefaultDependencies=no)
| * units: add missing Before=shutdown.target for units which it ConflictsAlan Jenkins2017-09-303-2/+2
| | | | | | | | | | | | | | There's a few services missing this ordering. Also remove a duplicate Conflicts=shutdown.target from systemd-volatile-root.service.
| * units: add missing ordering deps for Conflicts= of emergency.serviceAlan Jenkins2017-09-292-0/+2
| | | | | | | | | | | | | | | | | | | | | | 1. If we exited emergency mode immediately, we don't want to have an irreversible stop job still running for syslog.socket. I _suspect_ that can't happen, but let's not waste effort working out exactly why it's impossible and not just very improbable. 2. Similarly, it seems undesirable to have rescue.service and emergency.service both running with an open FD of /dev/console, for however short a period.
| * units: express Conflict in syslog.socket instead of emergency.serviceAlan Jenkins2017-09-292-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note this commit only changes how the code is expressed; it does not change the existence of any dependency. The `Conflicts=` was added in 3136ec90, "Stop syslog.socket when entering emergency mode". The discussion in the issue #266 raised concerns that this might be needed for other units, but failed to point out why syslog.socket is special. The reason is that syslog.socket has DefaultDepedencies=no, so it does not get Requires=sysinit.target like other socket units do. But syslog.service does require sysinit.target, among other things. We don't have many socket, path, or timer units with DefaultDependencies=no, and I don't think any of the triggered services have such additional hard dependencies as syslog.service does. It is much less confusing if we keep this `Conflicts=` in the same file as the `DefaultDependencies=no` which made it necessary.
| * units: do not kill rescue shell when machines.target is startedAlan Jenkins2017-09-291-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original aim of this commit is that starting machines.target from the rescue shell would not kill the rescue shell and lock you out of the system. This is similar to commit 6579a622, for the conflict between sysinit.target and the _emergency_ shell. That particular commit introduced an ordering cycle and will need to be reverted and/or fixed. This one does not, because it does not need to introduce any new dependencies. The reason why this commit is allowable also has it's own merit: machines.target was not marked as AllowIsolate. Also, the point of containers is to not escape them... I don't think we want to promote machines.target as a default target or similar; you would generally want some system service to allow you to shut down the machine, for example. I don't see this approach used in CoreOS, nor in Fedora Atomic Host; we are missing any positive examples of its utility. Requires=basic.target / After=basic.target can be removed for the same reason.