Clock stoped

I am using Openhabian in a RPi4 and already had 2 “peculiar situations”, where time base based rules stopped.
After logging in the RPi, using a SSH a connection, that was fully operational, when I issued a “date” command, I confirmed time was stuck a few hours in the past and “frozen” there.
The same situation happened in 2 different occasions, weeks apart.
Any hints?

OH gets it’s time from the operating system. If the date command on the command prompt tells you time has stopped, it’s an OS problem and you are likely to find the best help on a Raspberry Pi OS forum. RPis don’t have a hardware clock but simulate that with a “fake hardware clock” which I think is driven by systemd. It might be that service stopped, or an NTP client on the machine stopped or something like that.

Can you suggest a way, within OH, to check and solve this situation? Possibly a “sudo reboot”.

I doubt that it would be wise to try to work around the source of this problem. I would rather go and check the system logs to see why the time service has stopped running or why time synchronisation fails (or if it is even turned on). If this really is a failing systemd service it should be easy enough to fix this directly with some config changes in systemd. Instead of rebooting the whole machine you could just restart the service.

If you don’t want to dig deeper you could also just try if systemctl reset-failed fixes your time Problem when it happens again. This is also just a pretty wild guess but still better than rebooting the whole machine :slight_smile:

1 Like

The RPi is only running OH. The impact of a reboot will be minimal, but having the system “frozen” for hours (even minutes) is not acceptable.

If that’s not acceptable, then you need to solve the root problem. Rebooting whenever you notice that it’s not working won’t prevent that from occurring, and setting up openHAB to monitor specifically for this will likely take more effort with less chance of 100% success.

I suggest putting a fresh openHABian on a new SD card and seeing if the problem persists. If if returns, it’s a hardware problem. If it goes away, you’ve fixed it permanently.

If you really feel that rebooting is your only option:

I’m not even certain it’s possible for OH to monitor for this. You would have to periodically check for something but to do that you need to schedule something and that schedule depends on the system clock to drive it. It’s a catch-22. You need a working clock to periodically check to see if the clock is still working.

In a industrial system, I would use a watchdog device to monitor the system, using some periodic activity that could be monitored.
In case of malfunction, I would log the event and force a system reset.
I am looking of a similar approach since having a fault once every month is acceptable, as soon as I detect the failure with a limited delay.

I am not an expert on Linux but I find it peculiar that I can access the RPi using SSH when the clock is “frozen”

An RPi isn’t an industrial system. If it were it’d have a hardware clock and there wouldn’t be a problem. In fact you can get a hardware clock HAT for an RPi if you need one. But if there’s no clock then you can’t schedule a cron job to periodically check because cron is driven by the clock. A watch dog from systemd would have the same problem. With an advancing clock there isn’t a way for the machine to self monitor and take corrective action.

There is nothing about SSH that requires a clock so I’m not sure why you’d find that peculiar. There are other types of handshakes that require a clock but SSH just checks the certificates. The clock stopped, not the CPU.

I’ve been using RPis since the beginning though and this is the first I’ve ever heard of the clock stopping. But what ever is causing it, as I said, you are more likely to find a solution on an RPi forum than here. It’s not an OH problem. You need to go where the RPi experts are.

Is the pi connected via ethernet or via wifi ?

Ethernet.

I would switch to systemd-timesyncd - so at least you can check the status of the service. You can find a quick guide here: