Description of problem: systemd-timesyncd.service in Fedora 28 fails to start. Note that with SELinux enabled it already fails during dynamic user creation, I reported this in bug 1559281. But it still fails differently with SELinux off. Version-Release number of selected component (if applicable): systemd-238-4.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. setenforce 0 2. systemctl start systemd-timesyncd Actual results: ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2018-03- 22 03:57:51 EDT; 3min 49s ago Docs: man:systemd-timesyncd.service(8) Process: 1541 ExecStart=/usr/lib/systemd/systemd-timesyncd (code=exited, status=238/STATE_DIRECTORY) Main PID: 1541 (code=exited, status=238/STATE_DIRECTORY) Expected results: service starts successfully
Corresponding journal entries: systemd[1541]: systemd-timesyncd.service: Failed to set up special execution directory in /var/lib: File exists systemd[1541]: systemd-timesyncd.service: Failed at step STATE_DIRECTORY spawning /usr/lib/systemd/systemd-timesyncd: File exists The pid is a bit weird, shoudln't that be pid 1? This is all happening as root against the system systemd, no --user involved.
Same issue here on Fedora 28.
Working fix is here: https://github.com/systemd/systemd/issues/7659#issuecomment-352724406 It's permission issue in Fedora package.
Here is what I get: sctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2018-05-08 15:50:13 EDT; 8min ago Docs: man:systemd-timesyncd.service(8) Process: 15931 ExecStart=/usr/lib/systemd/systemd-timesyncd (code=exited, status=238/STATE_DIRECTORY) Main PID: 15931 (code=exited, status=238/STATE_DIRECTORY) May 08 15:50:13 delldm51 systemd[1]: Starting Network Time Synchronization... May 08 15:50:13 delldm51 systemd[1]: systemd-timesyncd.service: Main process exited, code=exited, status=238/STATE_DIRECTORY May 08 15:50:13 delldm51 systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'. May 08 15:50:13 delldm51 systemd[1]: Failed to start Network Time Synchronization. May 08 15:50:13 delldm51 systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. May 08 15:50:13 delldm51 systemd[1]: systemd-timesyncd.service: Scheduled restart job, restart counter is at 5. May 08 15:50:13 delldm51 systemd[1]: Stopped Network Time Synchronization. May 08 15:50:13 delldm51 systemd[1]: systemd-timesyncd.service: Start request repeated too quickly. May 08 15:50:13 delldm51 systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'. May 08 15:50:13 delldm51 systemd[1]: Failed to start Network Time Synchronization. What's chances of getting a fix in Fedora updates or updates-testing? I hate red messages when I am booting.
I tried the following (with selinux permissive) # chmod 700 /var/lib/private # systemctl start systemd-timesyncd And the service started correctly.
The source would be this file https://src.fedoraproject.org/rpms/systemd/blob/f28/f/systemd.spec ? Where can we know or follow the progress on this? systemd mailing list ? or Fedora package ?? Thanks
(In reply to Bruno Vernay from comment #6) I made a very simple test to see if both bugs are resolved https://gitlab.com/BrunoVernay/dynustat Is there a way to help on this one?
The chmod did the trick for me, how did you find that guys?
Yes, the chmod worked for me as well.
Any progress on fixing this? I'd provide a pull request, but the file list in this spec is generated and I don't fully follow that mechanism. This affects also Qubes OS VMs: https://github.com/QubesOS/qubes-issues/issues/3983
With SELinux permissive, chmod worked for me. With SELinux enforcing: type=AVC msg=audit(1539792068.272:3600): avc: denied { setattr } for pid=9937 comm="(imesyncd)" name="timesync" dev="dm-1" ino=1336413 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0 This is on F29: # rpm -qf /usr/lib/systemd/systemd-timesyncd systemd-udev-239-3.fc29.x86_64
We don't see this failure any more since the beginning of March, so it seems this got fixed.