Description of problem:at boot, splash-screen displays: Failed to start Set time via NTP here are returns of: [root@magaux alain4]# systemctl status ntpdate.service ● ntpdate.service - Set time via NTP Loaded: loaded (/usr/lib/systemd/system/ntpdate.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since lun. 2018-05-07 12:07:43 CEST; 48min ago Process: 6196 ExecStart=/usr/sbin/ntpdate-wrapper (code=exited, status=203/EXEC) Main PID: 6196 (code=exited, status=203/EXEC) mai 07 12:07:43 magaux systemd[1]: Starting Set time via NTP... mai 07 12:07:43 magaux systemd[1]: ntpdate.service: Main process exited, code=exited, status=203/EXEC mai 07 12:07:43 magaux systemd[1]: Failed to start Set time via NTP. mai 07 12:07:43 magaux systemd[1]: ntpdate.service: Unit entered failed state. mai 07 12:07:43 magaux systemd[1]: ntpdate.service: Failed with result 'exit-code'. [root@magaux alain4]# systemctl enable ntpdate.service The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. [root@magaux alain4]# systemctl start ntpdate.service Job for ntpdate.service failed because the control process exited with error code. See "systemctl status ntpdate.service" and "journalctl -xe" for details. [root@magaux alain4]# systemctl status ntpd.service ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: enabled) Active: active (running) since lun. 2018-05-07 12:07:43 CEST; 50min ago Main PID: 6227 (ntpd) CGroup: /system.slice/ntpd.service └─6227 /usr/sbin/ntpd -u ntp:ntp -g mai 07 12:07:43 magaux systemd[1]: Starting Network Time Service... mai 07 12:07:43 magaux systemd[1]: Started Network Time Service. mai 07 12:07:43 magaux ntpd[6227]: proto: precision = 0.053 usec (-24) mai 07 12:07:43 magaux ntpd[6227]: Listen and drop on 0 v4wildcard 0.0.0.0:123 mai 07 12:07:43 magaux ntpd[6227]: Listen normally on 1 lo 127.0.0.1:123 mai 07 12:07:43 magaux ntpd[6227]: Listen normally on 2 eth2 192.168.1.14:123 mai 07 12:07:43 magaux ntpd[6227]: Listening on routing socket on fd #19 for interface updates here attached return of journal -xe Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Created attachment 10134 [details] return of journalctl -xe
Source RPM: (none) => systemd? ntp?CC: (none) => marja11Assignee: bugsquad => basesystem
I have some vague memory that we had ditched ntp in favour of chrony, and Shlomi reminded me that systemd comes with its own tool. Anyway, here in cauldron I have chronyd.service loaded active running NTP client/server systemd-timesyncd.service loaded active running Network Time Synchronization I still see ntpd(ate), too, though, but dead: ● ntpd.service not-found inactive dead ntpd.service ● ntpdate.service not-found inactive dead ntpdate.service Apparently we never really dropped ntp.
Component: Release (media or process) => RPM Packages
I should get myself new memory :-( this is a duplicate of bug 22978 The updated packages (currently still in {core}/updates_testing) should fix it: ntp-4.2.8p11-1.1.mga6 ntpdate-4.2.8p11-1.1.mga6 sntp-4.2.8p11-1.1.mga6 ntp-doc-4.2.8p11-1.1.mga6 ntp-perl-4.2.8p11-1.1.mga6 @ Peter Please test those packages and comment in bug #22978 whether they fix the issue for you. *** This bug has been marked as a duplicate of bug 22978 ***
Resolution: (none) => DUPLICATEStatus: NEW => RESOLVED