I am not too experienced eitherš
There are probably other and better ways to deactivate services and make sure they are never being loaded again.
For me it was easier to simply delete these files.
Yes, because dbus-org.freedesktop.timedate1.service is an alias to systemd-timesyncd.
I meant deleting any files or directories related to dbus.
If you do not want to delete them you can move them into your home directory
Please double-validate that first!
Is there really another instance running?
Use systemctl list-units to display all services and systemctl list-units --state failed to see those that failed.
Watch for more processes with sync in their name (note that if you donāt spot any they can be stopped at times and started in intervals so keep repeating checking).
I just checked a fresh openHABian install, there is no dbus timesync or other second time daemon there but systemd-timesyncd is also reported to have stopped as failed. I was able to start it again and it has been running since but itās not long enough to tell if thatās permanent.
NEVER DELETE ANY DIRECTORIES. You can delete (better: rename) FILES in either /etc/systemd/system/ or /lib/systemd/system and issue systemctl daemon-daemon to uninstall a (stopped and disabled !) service but the proper way is to use systemctl mask. systemctl will create/remove the right links for you.
You must not intervene manually or you have a high risk of trashing your system !
You can disable services with systemctl disable --nowservice and avoid permanently that it could indirectly or accidently be re-enabled by using systemctl mask service.
To check it worked try systemctl enableservice after masking, it should refuse to.
Yes, of course. I was sharing a rebuttal hypothesis as I try to work through this problem. I appreciate your advice. I only see one instance running:
openhabian@openhab-midway:~ $ systemctl list-units | grep sync
ifupdown-pre.service loaded active exited Helper to synchronize boot up for ifupdown
systemd-timesyncd.service loaded active running Network Time Synchronization
time-sync.target loaded active active System Time Synchronized
sdrsync.timer loaded active waiting Run SD rsync daily except semiannually (when a raw dump is made)
I look forward to hearing how your experiment works out!
I donāt have any news but the problem might be that there has been some change inside Raspi OS in the past and itās now firing up another instance of timesyncd or a competing demon or whatever.
As youāre apparently really willing to help with development, you can create your own openHABian image to experiment with adding or removing parts of its configuration, hereās how.
Itās really simple, just a little time consuming (net time then again isnāt much, just compilation times).
Just clone the sources from Github, edit your local copy then push it back to Github. It will respond with that you donāt have write access etc pp and tell you a link to create a PR (pull request), enter that one.
When you upload, itāll build an image that you can download and flash to your local (test) box.
Thereās a function setup_ntp() in functions/system.bash Iād start with.
Try to omit installation of timesyncd for a first attempt. Insert some status outputting code (/bin/date or ps -ef|grep -i ntp or whatever) instead to see NTP/date status of the box.
Maybe thatās providing us some more insight.
Good luck.
Thanks for the ideas. I will give it a try and report back. It will be awhile, as we are going to be traveling most of the next month, and the spare Pi that I have is currently on loan to a friend, so I will need to get it back and give it a try.
Thanks for sharing your experience. The more people who report a problem, the more interest there will be in fixing it. Or perhaps better said, the better the chance that someone with the needed background and skills will take it on.
As the OP on this thread, I hoping to explore the ideas that were suggested above. I should be getting my spare Pi back the end of the month. The suggestions are way beyond me, but Iām happy to learn.
But your comment about Actions gave me an idea of where to look. I clicked on Actions and got this message: āWorkflows arenāt being run on this forked repository
Because this repository contained workflow files when it was forked, we have disabled them from running on this fork. Make sure you understand the configured workflows and their expected usage before enabling Actions on this repository.ā Once I accepted this, I clicked Actions again and under Workflows ran the build action, which queued and than ran, with errors: Build Ā· BigGeorgeTx/openhabian@9c28990 Ā· GitHub
Do I need to sync the fork before building?
Not having heard anything, I decided to try it. It took several days for the fork sync to complete running, but once it did, when I ran the workflow for the build action, it completed successfully, with 45 minutes elapsed time.
Now I need to download and flash to my text box.
On the GitHub code page for my fork, I clicked on CODE then Download ZIP.
Created the image on the SD card using Raspberry Piās imager.
Put in Pi and booted. The ethernet connection shows lots of activity, but I canāt connect to it via SSH.
Turns out the SD card was bad. Will try again with a new card and report back
I thinking I missing something to create the SD card image from the GitHub code. I tried downloading is as a zip file, but when I write that to the SD card using Rasperry Pi Imager, it doesnāt create a bootable SD card. Iām not sure how to the create the .img file it appears to be looing for. Help, please.
Not sure if you have downloaded the correct file. Reading ādownloaded zip fileā either you downloaded the wrong file or just used the wrong term in your statement.
The image is not a zip ( .zip ) file but xz-compressed ( .xz ).
Would you like to use the prebuild image ? Then you need to download it from Releases Ā· openhab/openhabian Ā· GitHub .
In case you would like to apply some fixes then you most probably do not want to download the prebuild image but would like to create your own image ?
I appreciate the suggestion. Iām trying to follow @mstormi 's guidance to troubleshoot the issue I and others have with NTP service, and Iām stuck at this point. It is a bit beyond my current knowledge, but Iām happy to learn.
Itās a .xz file (although sometimes shown as .zip) that in turn has another .xz pack of the image inside.
So open the download with WinRAR or whatever and unpack it. That .xz the Raspi imager should be able to read.
Guess I should modify the openhabian build process to eliminate that inner compression.