Comment # 12 on bug 1016313 from
(In reply to Michael Woski from comment #11)
> (In reply to Franck Bui from comment #10)
> 
> I think I did everything correctly regarding the service setup. As I said,
> it looks like timesyncd doesn't get started in the first place.

Hmm according to the log you provided in comment #3:

 Dec 20 17:23:45 linux01.mic.e-concepts.de systemd[31307]:
systemd-timesyncd.service: Executing: /usr/lib/systemd/systemd-timesyncd

which indicates that systemd has at least executed the binary. But it looks
like the (new) process fails very early.

Could you try to create a dumb service by duplicating systemd-timesyncd one and
then try:

 1/ to replace:

    ExecStart=/usr/lib/systemd/systemd-timesyncd

    with

    ExecStart=/usr/lib/systemd/sleep 10000

    You'll need to copy /usr/bin/sleep to /usr/lib/systemd/

 2/ if 1/ doesn't exhibit the probleme restore
ExecStart=/usr/lib/systemd/systemd-timesyncd

 3/ make the service as simple as possible by removing all fields in [Service]
section that are not needed to reproduce the issue.

 4/ show the output of "strace -c <content of ExecStart>"

Also it might be interesting to see what happens if you add
"SystemCallErrorNumber=EPERM", I meant if the debug log show something more
interesting.

> 
> I have openSUSE with systemd 232 running in a few virtual machines without
> that particular issue.

BTW could you describe your affected setup ? is it a virtual machine ? which
arch ?


You are receiving this mail because: