Time service

Was looking into replacing ntp with systemd-timesyncd on Vero V but apparently the system doesn’t like that as it wants to uninstall:

The following packages were automatically installed and are no longer required:
armv7-bluez-osmc armv7-bluezalsa-osmc armv7-connman-osmc cifs-utils curl iptables libbluetooth3
libfdk-aac2 libip6tc2 libnetfilter-conntrack3 libnfnetlink0 libnftnl11 libnl-3-200 libnl-genl-3-200
libnl-route-3-200 libnss-myhostname libopts25 libpcsclite1 libpkcs11-helper1 libsbc1 net-tools
openvpn wget wpasupplicant

I’m thinking those packages are neccesary :slight_smile: Same issue if I attempt to use chrony instead of ntp.
Would like the ability to switch.

Is there a specific reason you want to switch?

We used crony before but didn’t find it very reliable.

I might look at the systemd option in the future. If I do, I’ll probably do it for new installs only and won’t directly deprecate it on existing installations.

I believe I have some notes on this.

You could just disable ntp and enable systemd implementation rather than removing the package.

I was going to try that but as systemd-timesyncd was masked I attempted to unmask it and that procedure deleted the systemd-timesyncd.service file and that’s when I attempted to reinstall and was presented with the noted issue.

Can you let me know the exact commands you ran?


Should help

systemctl unmask systemd-timesyncd

Debian dependencies only allow for one of ntp, systemd-timesyncd or chrony (maybe others). Attemping to install one causes the removal of the current one installed.
As armv7-network-osmc has a hard depend on ntp, an attempt to install systemd-timesyncd or chrony triggers a removal of ntp which therefore triggers the removal of armv7-network-osmc as well as vero5-device-osmc as it depends on armv7-network-osmc .

I could possibly change the dependency to systemd-timesyncd || ntp but would then need to think of where we introduce the NTP package.

I will give it some thought.

thank you

Thanks for your patience.

I’ve looked in to this further and don’t think we should move to systemd-timesyncd over NTP.

However, I don’t see a problem with you installing systemd-timesyncd instead.

I’ve made this change possible as follows:

You can test accordingly:

  1. Login via the command line
  2. Run the following command to add the staging repository:
    echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list
  3. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  4. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you remove /etc/apt/sources.list.d/osmc-devel.list after updating.

This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.

Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.

Could you clarify why you wish to use systemd-timesyncd over NTP? I can’t really see a convincing use case… Please note this is compile tested. I have not tested the efficacy of this replacement service on OSMC personally.

I didn’t adjust for Chrony because my experiments with that in 2013-2014 weren’t great. But that may have been init based (Upstart at the time) issues. Every time you change the time setup, you change dependencies in the init system which isn’t ideal. At least with systemd-timesyncd you may have something closely coupled.


Actually I’ve been running with systemd-timesyncd instead of ntp for a few weeks now. Found that I could edit /var/lib/dpkg/status and edit the depends for the armv7-network-osmc package, replacing ntp with systemd-timesyncd | ntp, only drawback was that an apt update would sense the difference and want to update (which I didn’t do).
At any rate, no ill effects as systemd-timesyncd works just fine on all of my 'nix systems.
Main reason to switch is that systemd-timesyncd is less resource intensive and just fine for this purpose whereas ntp is like using a sledgehammer when you just need a ballpeen hammer.
Also I notice that there must not be a CMOS battery in the Vero V as the unit, when powered down, always comes up with the wrong time for a few seconds (same as before I made the switch).
And it looked some startup script was setting the time from the osmc site (unless I read the packet sniffing wrong). And this was completely unnecessary with timedatectl and timesyncd - I tested by blocking access to the osmc site on startup - and the time was promptly set properly.

Thanks much!

We’ve found that NTP port is sometimes blocked, so we try and set a base time over HTTP first.

The Vero V doesn’t have an RTC. I’ve considered adding one but I’m not keen on people opening the device to change the battery.

The change I’ve made to the packaging should let you update without issues going forward.

The update from the dev branch went OK with a minor hitch - probably due to my local changes. The systemd-timesyncd service was masked after the reboot. Unmasking caused the service file to be deleted. But upon an apt reinstall of the service all was fine, even after removing the dev sources from apt.
Thanks much again!

As to Chrony (a bit off-topic), my only experience with that is that it’s useful if you need to run a time server in a container (example: a Samba AD DC running in the container) as it can be started with the -x switch: This option disables the control of the system clock. chronyd will not try to make any adjustments of the clock. As the container will already have the same time as the host and by default (typically) the container will not have the capabilities of adjusting the host clock anyway.
I don’t know of another NTP server that has this feature.