linux watchdog on raspberrypi 3

[HarryT]

Hi
I use the linux watchdog on my raspberrypi 3 for years without problems. 
Now I build a new fhem installation on top of Trixie / Debian 13.
After about a week my RaspberryPi stops working. FHEM stops and the raspberry won't accept an ssh connection anymore. However the yellow led add the raspberry is still blinking a bit so there seems to be some activity.Strange enough my watchdog doesn't kickin and reboot the raspberry.  However a test with

Code Auswählen Erweitern

 sudo bash -c ':(){ :|:& };:'triggers a reboot. So I guess watchdog is installed correct. 
I used scripted installations and the install for watchdog is:

Code Auswählen Erweitern

sudo apt install watchdog

echo 'watchdog-timeout = 15' | sudo tee -a  /etc/watchdog.conf
echo 'max-load-1 = 24' | sudo tee -a  /etc/watchdog.conf

echo 'dtparam=watchdog=on' | sudo tee -a  /boot/firmware/config.txt

sudo systemctl enable watchdog
sudo systemctl start watchdog

I will change the watchdog config a bit so it will also trigger when a specific fhem file is not updated. That might be enough.
Has anybody an idea why my watchdog  doesn't trigger a reboot yet or even an idea why my raspberry stops responding?
Thanks for any response.

[KölnSolar]

I had a lot of problems setting up a rpi3 with Trixie, which worked with older debian. Main Problem were the USBs which are connected to the ethernet port. Thats possibly the cause not rebooting by the watchdog, because the system is still Running but network isn't working.

With a new rpi5 my problems were gone. The network is separated from the USBs !

Regards
Markus

[HarryT]

I had a lot of problems setting up a rpi3 with Trixie, which worked with older debian.

Me too. Previous updates where easy, but this one....

Main Problem were the USBs which are connected to the ethernet port. Thats possibly the cause not rebooting by the watchdog, because the system is still Running but network isn't working.

With a new rpi5 my problems were gone. The network is separated from the USBs !

Regards
Markus

Might be the reason. I now trigger watchdog on a file which is on an ssd attached over USB. What do you think about that? Could it be enough to trigger the watchdog?

A liitle bit out of time now. I will study the previous threat about this tomorrow. 

Thanks

[KölnSolar]

What do you think about that? Could it be enough to trigger the watchdog?

I think it will not help. FHEM is still running, I assume.

Maybe there is another watchdog option, that reboots the rpi, if LAN isn't accessible ?

Edit: Or check within FHEM with the presence-module and shutdown FHEM if not available. Your watchdog will then work.

[RalfRog]

Just one thing from my side.

Years ago when I changed from SD to USB-SSD I had the problem on RPI-2b that it sometimes was not down - but did not work and was not accessible.
It had no access to the root Filesystem - found it out with keyboard and monitor.
 
For this reason the watchdog checking a file was OK for me.

The reason I found out later were "undervoltage" conditions.
I solved it finally by using a power supply (Meanwell) where the output could be adjusted.

Regards Ralf

[HarryT]

Thanks for the suggestions


In my watchdog.conf I now have

Code Auswählen Erweitern

watchdog-timeout = 15
max-load-1     = 24
interface      = eth0
log-dir        = /media/ssd1/Watchdog
change         = 3600
interval       = 10
logtick        = 3
log-dir        = /var/log/watchdog
/code]

Last night my raspberry rebooted. So I guess watchdog triggered. As the file was changed 5 minutes before the reboot, most likely it was the eth0 connection disappearing.

I hoped to find in the logging why watchdog triggered. But I did not succeed in getting anything in the log-dir. It has 777 rights so that should not be a problem.
I tried the same in Linux mint and also got nothing in my logging.

I searched the internet but didn't find a hint. Anybody an idea how to get the log info saved or in general how to get the info why watchdog triggered?

journald doesn't survive a boot unless the config is changed.

 



[RalfRog]

Do you have in mind for the conf:

verbose = <level>
    This overrides the command line --verbose option. Generally the verbose mode is only enabled for debugging as it creates a lot of syslog chatter, so use this option with consideration. Zero is "normal" operation (quiet), while 1 is typically used for debugging. Values of 2 or more usually generate far too many messages.

An other thing is that the watchdog is like reset. If there is only the eth0 a problem you may harm your filesystem with the watchdog.