@judd Thanks for the information. Since all indicators point to the likelihood that I’ve been digging the wrong (rabbit) hole, I’m going to mark this solved (which in this case means “closed”). At least I’ve learned something. Thanks to everyone who replied and/or read this topic.
@judd I think my system is using NetworkManager (I say that because it’s always high in the list of processes using CPU resources when I’m running BOINC). If there is a definite disconnect between the networkd daemon and the timesyncd daemon (i.e., timesyncd should work even if networkd isn’t running), I suppose I can mark this topic SOLVED and start a new topic along the lines of Network Time Sync. I’ll wait a little while to see if anyone has more possibilities.
@BlaiseD Thanks for your reply. The only reason I made the connection between the timesyncd daemon and the networkd daemon was a sentence in the Arch Wiki description for systemd-timesyncd (itself a quote from the systemd mailing list) that implies such a dependence. “The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available.”
Even though systemd-networkd isn’t running on my system, I definitely have network connectivity.
So it could be that there is some other problem. I will do some more looking into this – maybe I’m looking at the wrong thing totally (of course, the only reason I’m looking at Network Time Sync is because of a problem in KDE I’m having).
@karasu Thanks so much for your reply.
Here is the output of the first two items (neither showed anything except the message below):
‘’’[[email protected] ~]$ sudo networkctl > 20190209-Terminal-Output.txt
WARNING: systemd-networkd is not running, output will be incomplete.
[[email protected] ~]$ sudo networkctl status >> 20190209-Terminal-Output.txt
WARNING: systemd-networkd is not running, output will be incomplete.’’’
And here is the output of ‘ls -lh’ for ‘/etc/systemd/network’ with specific network information purged:
‘’‘IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback n/a unmanaged
2 enp60s0 ether n/a unmanaged
3 enp0s20f0u5u3 ether n/a unmanaged
4 wlp61s0 wlan n/a unmanaged
5 tun0 none n/a unmanaged ‘’’
SUMMARY: I need help to troubleshoot Network Time Synchronization failure at boot on my Antergos system as well as the failure of the systemd network service. Thanks for any suggestions or insights about where to start looking for a solution
BACKGROUND CONTEXT: I am on a two-week-old install of Antergos (my first experience with an Arch-based system) using Plasma/KDE as a primary environment.
The original problem I was trying to solve was the fact that in the Kontact/KOrganizer application, times associated with To-Do’s (e.g., with a task due date) keep changing from my system time (which is Eastern US) to UTC, which makes any assignment of a date and time useless. (This is the only instance of such behavior – my system time is correct, and the time settings in other contexts works with no problem – e.g., the dates and times of events in the calendar of the same application.)
My original attempt to solve this was to enable the setting in KDE to automatically adjust the time (via NTP or whatever protocol KDE uses for that setting). I went through the motions of enabling this feature, was asked to authenticate the change via password, and every time, it would revert back. Some digging online revealed that this is seemingly a common issue dating back a long time.
By pure coincidence, on a system boot shortly after I began searching for a solution, I noticed a message at boot-time scroll up the screen that indication that starting Network Time Synchronization failed – and this message was displayed several times. I learned that this failure was the repeated attempts of the systemd-timesyncd.service to start at boot. I thought that that might be why the setting in KDE didn’t work, so my focus moved to the systemd-timesyncd problem.
At some point in my search for fixes, I read that systemd-timesyncd is dependent upon systemd-networkd.service, so I looked at that, and discovered that it also failed to start, both at boot-time and subsequently when I would try to start it from a terminal.
So the problem snowballed thusly: KDE auto-time-sync setting --> systemd-timesyncd failure --> systemd-networkd failure
WHAT I HAVE DONE so far (not in the order I did them since I can’t remember) from various possible solutions online:
–> changed permissions from 777 to 700 on /var/lib/private
–> removed NTP (as a separate application – apparently timesyncd implements some version of NTP itself, independently of the NTP application)
–> edited timesyncd.conf (to comment out the “NTP” section to manually choose servers to use)
–> enabled NTP via timedatectl
When I found out that the systemd-networkd.service also wasn’t working, I decided to ask for some help, because (1) there is a evidently a larger problem with systemd on my system and (2) I didn’t want to just try random things without understanding better what the hell I was doing and end up making things worse (which I might have done with my attempts to diagnose and fix the systemd-timesyncd issue, but if so it’s not visible to me yet).
LOGS: portions of the output of
journalctl -xerelative to trying to start systemd-networkd.service. I’m not including anything related to systemd-timesyncd because I need to work on one thing at a time since I’m in this rabbit hole so far.
-- Subject: A start job for unit systemd-networkd.service has begun execution -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit systemd-networkd.service has begun execution. -- -- The job identifier is 3380. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Failed to determine user credentials: No such process Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Failed at step USER spawning /usr/lib/systemd/systemd-networkd: No such process -- Subject: Process /usr/lib/systemd/systemd-networkd could not be executed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The process /usr/lib/systemd/systemd-networkd could not be executed and failed. -- -- The error number returned by this process is ERRNO. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Main process exited, code=exited, status=217/USER -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- An ExecStart= process belonging to unit systemd-networkd.service has exited. -- -- The process' exit code is 'exited' and its exit status is 217. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit systemd-networkd.service has entered the 'failed' state with result 'exit-code'. Feb 08 09:40:45 Area51-Alien systemd: Failed to start Network Service. -- Subject: A start job for unit systemd-networkd.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit systemd-networkd.service has finished with a failure. -- -- The job identifier is 3380 and the job result is failed. Feb 08 09:40:45 Area51-Alien audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-networkd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Service has no hold-off time (RestartSec=0), scheduling restart. Feb 08 09:40:45 Area51-Alien systemd: systemd-networkd.service: Scheduled restart job, restart counter is at 1. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Automatic restarting of the unit systemd-networkd.service has been scheduled, as the result for -- the configured Restart= setting for the unit. Feb 08 09:40:45 Area51-Alien sudo: pam_unix(sudo:session): session closed for user root Feb 08 09:40:45 Area51-Alien systemd: Stopped Network Service. -- Subject: A stop job for unit systemd-networkd.service has finished -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A stop job for unit systemd-networkd.service has finished. -- -- The job identifier is 3386 and the job result is done.```
Hello everyone . . . and thank you to everyone who develops and uses Antergos for being such a welcoming and open community.
The longer-version intro:
Context: I started using Linux with Linux Mandrake back in 2001. I reverted to Windows in 2006 when I got a laptop that I couldn’t get Mandrake to run on.
In 2008, I was able to install Ubuntu on another laptop and used some version of Ubuntu (the latest with the Cinammon desktop which was - and is - a great and stable system) until a few weeks ago.
I first heard about Antergos last year on a podcast that I listen to, and installed it in a VM to see how the rolling-release thing would work. Everything ran smoothly, although I didn’t do very much with it in the VM other than update it to see if it would break. It did a couple of times, but both times, I found a solution in seconds by searching Google or DuckDuckGo.
Installing Antergos: After I decided to take the plunge and install Antergos as my main daily-use system, I didn’t have much luck in the beginning with a straight-forward install using the normal Antergos media. I experienced the commonly-reported errors with booting the live media and/or various problems with the Cnchi installer.
I almost gave up since I wasn’t having any problems with my old Ubuntu setup, but the idea of using an Arch-based rolling-release system was appealing to me.
I finally used an Antergos-derived installer I found referenced on this forum somewhere when I was searching for solutions for my installation issues called “Portergos”. There is an offline-installation option that worked perfectly for me, and I ended up with a working installation I could use to get to the system I wanted (using Plasma and KDE for the first time in years).
It was worth the effort and the time.
Experience so far. I have been using this new Antergos (or Antergos-based) system for a couple of weeks now and loving it. I haven’t even booted into my old Ubuntu system (though it’s still present as an option in grub along with Windows 10 which I use for games I can’t play on Linux yet), and I’m enjoying this latest incarnation of KDE (last time I used it was in the 3.xx series, and it became clunky as hell and unusable after a while).
I have found the Antergos community that I’ve interacted with so far to be welcoming and helpful, as I noted above. I must say that it’s nice to have an alternative to the rather off-putting (or so it seems to me) attitude the Arch Forums seem to have (that’s just from spending a lot of time reading it lately and not from any direct interaction).
If you bothered to read this far, thanks for being here and I’m sure I will be posting some questions as I try to get various things working (but nothing major).