Implement time-sync.target

1st Official Post

    Extract from systemd.special

    <quote>
    time-sync.target

    Services responsible for synchronizing the system clock from a remote source (such as NTP client implementations) should pull in this target and order themselves before it. All services where correct time is essential should be ordered after this unit, but not pull it in. systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$time" facility.
    </quote>

    LE currently has Kodi depend on network-online.target, but there can be a variable delay before the clock is sync'd. Implementing time-sync.target and having Kodi depend on it would would avoid problems with e.g. mounting network shares.

    • Official Post

    Correct time is a good thing but is also cosmetic to the Kodi GUI so there is no reason to make Kodi start depend upon it. From a support perspective this would make things worse given that some routers act as bad/misconfigured NTP servers, users have a habit of adding typos to their input, and some ISP's blocking port 123 (lord knows why, but it happens).

    As 99% of NTP issues are seen on Raspberry Pi .. the cure is adding an RTC card not adding workarounds to the OS.

    Quote from chewitt


    Correct time is a good thing but is also cosmetic to the Kodi GUI so there is no reason to make Kodi start depend upon it. From a support perspective this would make things worse given that some routers act as bad/misconfigured NTP servers, users have a habit of adding typos to their input, and some ISP's blocking port 123 (lord knows why, but it happens).

    As 99% of NTP issues are seen on Raspberry Pi .. the cure is adding an RTC card not adding workarounds to the OS.

    Hmmm. It may be 'cosmetic' to you...but if Kodi starts before the clock is in sync, my network mounts fail.
    Interestingly, OSMC doesn't exhibit the problem - only difference being that I do the network mounts via /etc/fstab, rather than systemd [although I understand systemd handles fstab under the covers].
    Perhaps make it possible to configure whether Kodi uses time-sync.target or does what it currently does?
    This would mean actually implementing time-sync.target though, which you appear reluctant to support.

    PS I am aware there are workarounds for the mount failures. I have to use them :-}
    PPS I don't think my proposal is a workaround, rather a solution...
    [hr]
    chewitt
    I just reread my last reply, I wasn't being snarky, honest :-}
    [hr]
    Since LE already has an option "wait for network" in the LibreELEC settings add-on, perhaps
    another option "wait for clock synchronised" could be added, so people who don't care
    about the functionality needn't specify it.

    Edited once, last by agb (October 2, 2016 at 5:17 PM).

    A good reason for the original suggestion is that cron daemon does not automatically sync to the actual time it syncs to the kernel build time.

    My Pi 1B does have ntp set up and the system time zone is correct and it is connected to a wired network and displays the correct time. But "systemctrl status cron" returns:

    [0;1;32m●[0m cron.service - Cron daemon
    Loaded: loaded (/usr/lib/systemd/system/cron.service; disabled; vendor preset: disabled)
    Active: [0;1;32mactive (running)[0m since Thu 2016-09-29 16:28:34 EDT; 1 day 17h ago
    Process: 249 ExecStartPre=/bin/mkdir -p /storage/.cache/cron/crontabs (code=exited, status=0/SUCCESS)
    Main PID: 265 (crond)
    CGroup: /system.slice/cron.service
    └─265 /sbin/crond -f -S

    Sep 29 16:28:33 LibreELEC systemd[1]: Starting Cron daemon...
    Sep 29 16:28:34 LibreELEC systemd[1]: Started Cron daemon.
    Oct 01 10:22:33 LibreELEC crond[265]: [0;1;31mtime disparity of 2513 minutes detected[0m


    the time that the kernel was compiled as not agreeing with the system time. I had do "systemctl restart cron" to get cron to work, after that it continues working after reboot.

    That has happened at least twice on fresh installs and after many reboots over several weeks.

    I suppose that makes it a Linux problem not a Kodi problem, but it is annoying that nobody has noticed it besides myself.

    Edited once, last by donbrew (October 12, 2016 at 6:47 PM).