ntp.service not getting started on bootup

16,548

As of Ubuntu 16.04, the ntp service has been replaced by a native systemd service named systemd-timesyncd (or prefer-timesyncd) and it is running by default.

If you just want an NTP-synced clock, leave ntp.service disabled and use timedatectl status to check status:

lar@rv-server:~$ timedatectl status
      Local time: Fri 2018-11-09 14:16:52 PST
  Universal time: Fri 2018-11-09 22:16:52 UTC
        RTC time: n/a
       Time zone: America/Los_Angeles (PST, -0800)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

If NTP is not synchronized, use sudo timedatectl set-ntp on to turn it on.


For an NTP server (not just client), you will either need to replace timedatectl with ntpd or install chrony (recommended).

Read more here: https://help.ubuntu.com/lts/serverguide/NTP.html

Share:
16,548

Related videos on Youtube

Tasdik Rahman
Author by

Tasdik Rahman

Updated on September 18, 2022

Comments

  • Tasdik Rahman
    Tasdik Rahman over 1 year

    I am upgrading my system from 14.04 to 16.04, I am facing this issue of ntp.service not getting started on bootup.

    $ sudo systemctl status ntp.service
    ● ntp.service - LSB: Start NTP daemon
       Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
       Active: active (exited) since Mon 2017-09-11 12:29:11 UTC; 26min ago
         Docs: man:systemd-sysv-generator(8)
        Tasks: 0
       Memory: 0B
          CPU: 0
    
    Sep 11 12:29:11 ip-10-1-1-20 systemd[1]: Starting LSB: Start NTP daemon...
    Sep 11 12:29:11 ip-10-1-1-20 ntp[1254]:  * Starting NTP server ntpd
    Sep 11 12:29:11 ip-10-1-1-20 ntp[1254]:    ...done.
    Sep 11 12:29:11 ip-10-1-1-20 systemd[1]: Started LSB: Start NTP daemon.
    Sep 11 12:29:11 ip-10-1-1-20 ntpd[1372]: proto: precision = 0.222 usec (-22)
    

    The contents of the ntp.service file is being generated by sysv services if I am not wrong. Content of which is

    $ sudo systemctl cat ntp.service
    # /run/systemd/generator.late/ntp.service
    # Automatically generated by systemd-sysv-generator
    
    [Unit]
    Documentation=man:systemd-sysv-generator(8)
    SourcePath=/etc/init.d/ntp
    Description=LSB: Start NTP daemon
    Before=multi-user.target
    Before=multi-user.target
    Before=multi-user.target
    Before=graphical.target
    After=network-online.target
    After=remote-fs.target
    After=systemd-journald-dev-log.socket
    Wants=network-online.target
    
    [Service]
    Type=forking
    Restart=no
    TimeoutSec=5min
    IgnoreSIGPIPE=no
    KillMode=process
    GuessMainPID=no
    RemainAfterExit=yes
    ExecStart=/etc/init.d/ntp start
    ExecStop=/etc/init.d/ntp stop
    

    Relevant bug files:

    I asked around in the IRC's and they said, the system generated file from the init service to a systemd service file is sometimes's buggy and asked me to replace it from one of the upstream versions of ntp.service.

    Right now, the fix I have been able to come up with is that I have to manually start and stop the ntpd service

    $ sudo systemctl stop ntp.service
    $ sudo systemctl start ntp.service
    

    But this defeats the purpose of the automatic start of the ntp.service at boot time

    Would appreciate any help on this.

    • Boris Hamanov
      Boris Hamanov over 6 years
      Are you running on a SSD? Once the network is up, don't you find that ntp starts itself properly? Check the syslog to confirm.
    • Tasdik Rahman
      Tasdik Rahman over 6 years
      I am running on a SSD. This is an ec2 instance, > Check the syslog to confirm. But the status of the service is shown as exited right? Wouldn't it be already down
    • Boris Hamanov
      Boris Hamanov over 6 years
      Typically if a service doesn't start properly, but you can start it properly manually, and you're booting from an SSD, it's because the machine boots too fast, and not all services have fully started by the time other services need them. It's a timing issue. It looks like your ntp.service file has the required network-online.target that tell it to wait until the network is up. You might grep -i ntp /var/log/syslog* and see if there's any more clues.