picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Systemd/units/systemd-timesyncd.service.in

57 lines
1.5 KiB
SYSTEMD
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 05:23:58 +01:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Add SPDX license headers to unit files
2017-11-18 17:35:03 +01:00
#
timesyncd: add unit and man page
2014-04-29 08:57:51 +02:00
# 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=Network Time Synchronization
Documentation=man:systemd-timesyncd.service(8)
ConditionCapability=CAP_SYS_TIME
timesyncd: enable timesyncd in virtual machines On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau <michael.marineau@coreos.com> wrote: > Currently systemd-timesyncd.service includes > ConditionVirtualization=no, disabling it in both containers and > virtual machines. Each VM platform tends to deal with or ignore the > time problem in their own special ways, KVM/QEMU has the kernel time > source kvm-clock, Xen has had different schemes over the years, VMware > expects a userspace daemon sync the clock, and other platforms are > content to drift with the wind as far as I can tell. > > I don't know of a robust way to know if a platform needs a little > extra help from userspace to keep the clock sane or not but it seems > generally safer to try than to risk drifting. Does anyone know of a > reason to leave timesyncd off by default? Otherwise switching to > ConditionVirtualization=!container should be reasonable.
2015-03-15 19:44:59 +01:00
ConditionVirtualization=!container
units: minor cleanups
2014-06-17 02:18:33 +02:00
DefaultDependencies=no
units: drop systemd-remount-fs.service dependency from more services All services using StateDirectory= don't need the explicit dep anymore, let's hence drop it everywhere.
2020-04-08 16:24:23 +02:00
After=systemd-sysusers.service
units: add time-set.target time-sync.target is supposed to indicate system clock is synchronized with a remote clock, but as used through 241 it only provided a system clock that was updated based on a locally-maintained timestamp. Systems that are powered off for extended periods would not come up with accurate time. Retain the existing behavior using a new time-set.target leaving time-sync.target for cases where accuracy is required. Closes #8861
2018-04-30 14:05:29 +02:00
Before=time-set.target sysinit.target shutdown.target
timesyncd: save clock to disk everytime we get an NTP fix, and bump clock at boot using this This is useful to make sure the system clock stays monotonic even on systems that lack an RTC. Also, why we are at it, also use the systemd release time for bumping the clock, since it's a slightly less bad than starting with jan 1st, 1970. This also moves timesyncd into the early bootphase, in order to make sure this initial bump is guaranteed to have finished by the time we start real daemons which might write to the file systemd and thus shouldn't leave 1970's timestamps all over the place...
2014-05-20 17:04:11 +02:00
Conflicts=shutdown.target
units: add time-set.target time-sync.target is supposed to indicate system clock is synchronized with a remote clock, but as used through 241 it only provided a system clock that was updated based on a locally-maintained timestamp. Systems that are powered off for extended periods would not come up with accurate time. Retain the existing behavior using a new time-set.target leaving time-sync.target for cases where accuracy is required. Closes #8861
2018-04-30 14:05:29 +02:00
Wants=time-set.target time-sync.target
timesyncd: add unit and man page
2014-04-29 08:57:51 +02:00
[Service]
units: make use of !! ExecStart= prefix in systemd-timesyncd.service Let's make use of !! to run timesyncd with ambient capabilities on systems supporting them.
2017-08-10 09:07:08 +02:00
AmbientCapabilities=CAP_SYS_TIME
unit: declare BusName= in all our units that are on the bus, event if they don't use Type=dbus This information is always useful, so let's always declare it, particular in the light of #16976.
2020-09-11 10:56:06 +02:00
BusName=org.freedesktop.timesync1
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
CapabilityBoundingSet=CAP_SYS_TIME
ExecStart=!!@rootlibexecdir@/systemd-timesyncd
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
timesyncd: run timesyncd as unpriviliged user "systemd-timesync" (but still with CAP_SYS_TIME)
2014-05-17 20:33:47 +02:00
PrivateDevices=yes
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
PrivateTmp=yes
units: turn on ProtectProc= wherever suitable
2020-08-06 14:50:38 +02:00
ProtectProc=invisible
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 13:23:27 +02:00
ProtectControlGroups=yes
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
ProtectHome=yes
units: enable ProtectHostname=yes
2019-02-18 23:30:12 +01:00
ProtectHostname=yes
units: turn on ProtectProc= wherever suitable
2020-08-06 14:50:38 +02:00
ProtectKernelLogs=yes
units: turn on ProtectKernelModules= for most long-running services
2017-02-09 11:09:50 +01:00
ProtectKernelModules=yes
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
ProtectKernelTunables=yes
ProtectSystem=strict
Restart=always
RestartSec=0
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 13:23:27 +02:00
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
RestrictNamespaces=yes
RestrictRealtime=yes
units: turn on RestrictSUIDSGID= in most of our long-running daemons
2019-03-20 19:52:20 +01:00
RestrictSUIDSGID=yes
time-wait-sync: use watchfile to coordinate with timesyncd 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
2018-04-09 20:39:16 +02:00
RuntimeDirectory=systemd/timesync
timesync: move stamp file to /var/lib/systemd/timesync/clock
2017-08-30 08:59:57 +02:00
StateDirectory=systemd/timesync
units: set NoNewPrivileges= for all long-running services Previously, setting this option by default was problematic due to SELinux (as this would also prohibit the transition from PID1's label to the service's label). However, this restriction has since been lifted, hence let's start making use of this universally in our services. On SELinux system this change should be synchronized with a policy update that ensures that NNP-ful transitions from init_t to service labels is permitted. An while we are at it: sort the settings in the unit files this touches. This might increase the size of the change in this case, but hopefully should result in stabler patches later on. Fixes: #1219
2018-11-12 17:19:48 +01:00
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service @clock
Type=notify
User=systemd-timesync
meson: allow WatchdogSec= in services to be configured 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
2019-10-25 12:17:24 +02:00
@SERVICE_WATCHDOG@
timesyncd: add unit and man page
2014-04-29 08:57:51 +02:00
[Install]
timesyncd: save clock to disk everytime we get an NTP fix, and bump clock at boot using this This is useful to make sure the system clock stays monotonic even on systems that lack an RTC. Also, why we are at it, also use the systemd release time for bumping the clock, since it's a slightly less bad than starting with jan 1st, 1970. This also moves timesyncd into the early bootphase, in order to make sure this initial bump is guaranteed to have finished by the time we start real daemons which might write to the file systemd and thus shouldn't leave 1970's timestamps all over the place...
2014-05-20 17:04:11 +02:00
WantedBy=sysinit.target
timesync: expose manager properties on bus
2018-04-30 16:02:09 +02:00
Alias=dbus-org.freedesktop.timesync1.service