systemd.timesyncd fails on boot [Solved]

jasonwryan · 2014-10-30 21:34:11

Upgraded systemd to 217-1 and now each boot sees timesyncd fail:

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: failed (Result: start-limit) since Fri 2014-10-31 10:25:59 NZDT; 5min ago
     Docs: man:systemd-timesyncd.service(8)
  Process: 303 ExecStart=/usr/lib/systemd/systemd-timesyncd (code=exited, status=1/FAILURE)
 Main PID: 303 (code=exited, status=1/FAILURE)
   Status: "Shutting down..."

Oct 31 10:25:59 Shiv systemd[1]: Failed to start Network Time Synchronization.
Oct 31 10:25:59 Shiv systemd[1]: Unit systemd-timesyncd.service entered failed state.
Oct 31 10:25:59 Shiv systemd[1]: systemd-timesyncd.service failed.
Oct 31 10:25:59 Shiv systemd[1]: start request repeated too quickly for systemd-timesyncd.service
Oct 31 10:25:59 Shiv systemd[1]: Failed to start Network Time Synchronization.
Oct 31 10:25:59 Shiv systemd[1]: Unit systemd-timesyncd.service entered failed state.
Oct 31 10:25:59 Shiv systemd[1]: systemd-timesyncd.service failed.

Once I log in, I am able to restart the service without any complaint.

Anyone else seeing this?

# edit: perhaps related to this fixed(?) bug: http://lists.freedesktop.org/archives/s … 03199.html

figue · 2014-10-31 20:52:53

Same here.

csn · 2014-11-01 22:05:00

tl;dr answer:

# sed -i 's/ remote-fs.target$//' /usr/lib/systemd/system/systemd-journal-flush.service

Long answer:

In systemd 217 a few changes were made with regard to ordering of early boot units, resulting in certain setups which used to work with systemd 216 to make problems with systemd 217. The fix above was also applied in systemd upstream by this commit:

commit 919699ec301ea507edce4a619141ed22e789ac0d
Author: Lennart Poettering <lennart@poettering.net>
Date:   Fri Oct 31 16:22:36 2014 +0100

    units: don't order journal flushing afte remote-fs.target
    
    Instead, only depend on the actual file systems we need.
    
    This should solve dep loops on setups where remote-fs.target is moved
    into late boot.

For example, in my case, connman.service explicitly requests to be ordered before remote-fs.target, leading to all kinds of fun:

systemd[1]: Found ordering cycle on basic.target/start
systemd[1]: Found dependency on sysinit.target/start
systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start
systemd[1]: Found dependency on systemd-journal-flush.service/start
systemd[1]: Found dependency on remote-fs.target/start
systemd[1]: Found dependency on connman.service/start
systemd[1]: Found dependency on basic.target/start
systemd[1]: Breaking ordering cycle by deleting job systemd-tmpfiles-setup.service/start
[...]
systemd-timesyncd[201]: Failed to allocate manager: No such file or directory
systemd[1]: systemd-timesyncd.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Network Time Synchronization.
systemd[1]: Unit systemd-timesyncd.service entered failed state.
systemd[1]: systemd-timesyncd.service failed.

Explanation:

systemd-journal-flush.service wants to be ordered after remote-fs.target whereas connman.service wants to be ordered before remote-fs.target. Additionally, connman.service requires basic.target. (This is implicit behavior for units which don't declare "DefaultDependencies=no".) This is why basic.target ends up getting pulled in so early in the first place.

Furthermore, systemd-timesyncd.service relies on properly initialized runtime directories in order to work, so it wants to be ordered after systemd-tmpfiles-setup.service.

In order to be able to start basic.target, systemd breaks the ordering cycle by taking systemd-tmpfiles-setup.service out of the transaction, thereby preventing systemd-timesyncd.service from starting up correctly.

Last edited by csn (2014-11-01 22:18:37)

jasonwryan · 2014-11-01 22:29:08

csn wrote:

Long answer...

Thank you for the detailed explanation (and the fix). This now seems a bug in the journal-flush service file.

Arch Linux

#1 2014-10-30 21:34:11

systemd.timesyncd fails on boot [Solved]

#2 2014-10-31 20:52:53

Re: systemd.timesyncd fails on boot [Solved]

#3 2014-11-01 22:05:00

Re: systemd.timesyncd fails on boot [Solved]

#4 2014-11-01 22:29:08

Re: systemd.timesyncd fails on boot [Solved]

Board footer