You are not logged in.
I have a new Arch installation. (It was not upgraded from systemd version 239.) I am seeing a consistent failure of systemd-timesyncd.service on every boot up. The only error I have found so far is "Error: 13 (Permission denied)" from systemctl status systemd-timesyncd.service. I have not been able to find any other threads related to this error. Does anyone have a link?
Here are some of the things I have looked at so far:
systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
* systemd-timesyncd.service loaded failed failed Network Time Synchronization
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed.I'm using the simple systemd NTP daemon, activated like this:
timedatectl set-ntp trueThe logs for this boot up start at Nov 02 17:42:06.
systemctl status systemd-timesyncd.service
* systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2020-11-02 17:42:09 EST; 2h 5min ago
Docs: man:systemd-timesyncd.service(8)
Process: 597 ExecStart=/usr/lib/systemd/systemd-timesyncd (code=exited, status=1/FAILURE)
Main PID: 597 (code=exited, status=1/FAILURE)
Status: "Idle."
Error: 13 (Permission denied)
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Main process exited, code=exited, status=1/FAILURE
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Nov 02 17:42:09 laptop systemd[1]: Failed to start Network Time Synchronization.
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Scheduled restart job, restart counter is at 5.
Nov 02 17:42:09 laptop systemd[1]: Stopped Network Time Synchronization.
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Start request repeated too quickly.
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Nov 02 17:42:09 laptop systemd[1]: Failed to start Network Time Synchronization.journalctl -b
Nov 02 17:42:09 laptop systemd[1]: Starting Network Time Synchronization...
Nov 02 17:42:09 laptop systemd-timesyncd[581]: Failed to connect to bus: Permission denied
Nov 02 17:42:09 laptop systemd-timesyncd[581]: Could not connect to bus: Permission denied
Nov 02 17:42:09 laptop audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-timesyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Nov 02 17:42:09 laptop audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-timesyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 02 17:42:09 laptop audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-timesyncd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Main process exited, code=exited, status=1/FAILURE
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Failed with result 'exit-code'.
Nov 02 17:42:09 laptop systemd[1]: Failed to start Network Time Synchronization.
Nov 02 17:42:09 laptop systemd[1]: systemd-timesyncd.service: Scheduled restart job, restart counter is at 4.
Nov 02 17:42:09 laptop systemd[1]: Stopped Network Time Synchronization.EDIT: the issue seems to have been due to the permissions on the root ("/") directory. I had them set to 751, but changing to the more standard 755 resolved the issue.
Last edited by MountainX (2020-11-03 02:44:16)
Offline
Out of curiosity, what did you think 751 would accomplish?
Offline
Out of curiosity, what did you think 751 would accomplish?
I guess you know, but what that does is prevent "others" from reading but allows everyone to traverse the directory. Personally, I prefer more restrictive permissions. I use 755 as rarely as possible. I'm surprised 751 didn't work...
Offline
Interesting. Do you have anything fancy in / going on, that could be a security problem? I think the only anomaly I have on my server is an Android style /storage folder.
Offline
Did you adjust the permissions on all subdirectories of / owned root:root which were 755 and also make them 751? Otherwise systemd may have detected an unsafe path transition.
Offline
Did you adjust the permissions on all subdirectories of / owned root:root which were 755 and also make them 751? Otherwise systemd may have detected an unsafe path transition.
I did not, but I like the idea. I will try it soon. Thanks.
Offline