Add option for watchdog service #298
Comments
|
That would be very nice. Post installing this is a little egg ;-) (een eitje) |
|
I've done some testing. It looks like its working as described on the page you referred to. The Arch instructions are the same as for |
|
Do you get an error message? Often |
|
Mmm. While stressing:
Only |
|
But, when I do this: OK, so I do: Then if I stress the Pi it reboots: |
|
I enabled (comment out) Haha! While you added your latest post, I collected the same data 😉 |
|
👍 |
|
We're not the only ones who noticed the not starting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793309 |
|
OK. Let's wait for them to figure this out. I don't think this is a showstopper even for v1.1.x |
|
I'm not really the guy who likes to wait ... 😉 Time to play 😄 |
|
One issue fixed: add |
|
Another one: |
|
What issue is fixed by setting the time-out? I see no differences. |
|
|
|
Fixing |
|
time-out must be <=15 (me thinks) |
|
Correct. It's not that it must be 15, but it can't be bigger then 15. |
|
Anyway, those "fixes" don't work for me. |
|
I've done the following changes and with that, the watchdog service does start up on boot up without errors on my system: diff --git a/lib/systemd/system/watchdog.service.orig b/lib/systemd/system/watchdog.service
index 40d3a72..1dc6694 100644
--- a/lib/systemd/system/watchdog.service.orig
+++ b/lib/systemd/system/watchdog.service
@@ -7,8 +7,9 @@ OnFailure=wd_keepalive.service
[Service]
Type=forking
EnvironmentFile=/etc/default/watchdog
-ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module
+ExecStartPre=/bin/sh -c '[ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module'
ExecStart=/bin/sh -c '[ $run_watchdog != 1 ] || exec /usr/sbin/watchdog $watchdog_options'
ExecStopPost=/bin/sh -c '[ $run_wd_keepalive != 1 ] || false'
[Install]
+WantedBy=multi-user.targetAnd modified diff --git a/etc/watchdog.conf.orig b/etc/watchdog.conf
index 44f7886..0d689c2 100644
--- a/etc/watchdog.conf.orig
+++ b/etc/watchdog.conf
@@ -7,7 +7,7 @@
# Uncomment to enable test. Setting one of these values to '0' disables it.
# These values will hopefully never reboot your machine during normal use
# (if your machine is really hung, the loadavg will go much higher than 25)
-#max-load-1 = 24
+max-load-1 = 24
#max-load-5 = 18
#max-load-15 = 12
@@ -21,7 +21,8 @@
#test-binary =
#test-timeout =
-#watchdog-device = /dev/watchdog
+watchdog-device = /dev/watchdog
+watchdog-timeout = 15
# Defaults compiled into the binary
#temperature-device =After a reboot I get this: |
|
Just informed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798294 (and indirectly #783166) and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793309 about these issues. 'Luckily' there is also a serious (=RC (Release Critical)) FTBFS (Fails to Build from Source) bug and that often results in action on the package 😄 |
|
@diederikdehaas your solution does not work for my R-Pi (Pi1B+; |
|
Good to know 👍 |
|
I can test on wheezy tomorrow. Going to watch "Life of Brian" now 😉 |
|
Have fun, Collaborator 😄 |
|
In the coffee-break I did quickly run a test (couldn't help myself). Then make the changes to
|
LOL
That shouldn't be needed and is a (very) old way of doing things. In most cases it would also start the service automatically, but given the issues in the package and having to modify |
|
I just installed a |
|
@diederikdehaas : Confirmed. For |
|
I found some 'interesting' things in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768168 ... (to be continued) |
|
On a distribution with systemd there is no need for running a watchdog. I setup everything like the following: post-install.txt:: |
uhm... what? 😄 your example set's up the watchdog, and instructs systemd to let it know it's still alive, every 10 seconds |
|
Thats exactly what I am doing ;-). I forgott to mention that I do that in the post-install.txt script. If you need more information, background, or want to bind your services to a software watchdog I can recommend the article at 0pointer. |
|
yes, another piece of software that systemd feels a need to (re)implement (even though this should be the kernels responsibility)... because ... reasons but beside that, relying on systemd to handle your watchdog needs is ... well, it makes me question if you actually understand the benefits a watchdog offers... |
|
and in case someone reads this and asks "ok, how to use it then"... (this is pretty specific to the RPi, other use cases, like servers, might have other needs, of course) if you set up a mission critical system, make sure you reset the watchdogs timer, usually inside your main runloop... this way even if your process hangs (or maybe "hangs" because some callback from a library doesn't get called... which wouldn't be picked up by systemd... actual example), a reboot will be triggered by the watchdog... don't rely on "everything and the kitchen sink" software, as you will have problems tracking down issues... |
|
I just wanted to point out this way so it can be considered if there should be a option for watchdog in raspbian-ui-netinst. Such a option would not make very much sense to use, if you want to give the watchdog in your own applications hand. Another advantage I see in using the systemds watchdog is that you don't rely on a deamon to be started after boot. systemd has to be started anyway and the implementation doesn't seem to be that much of a hassle (if I may refer to L. Poetterings Blog). I hope I was able to clearify how that mechanism works and what it provides. Sorry for not pointing that out earlier. |
you see that as an advantage? oh well 😒 |
|
I am just assuming that you missunderstand that sentence because I didn't care enought on writing that paragraph. So let me clearify that: What I tried to say is, that you do not rely on the watchdog daemon (e.g. watchdog.service) to start in the first place. As you probably aware the this would cause the watchdog never to be activated. Which advantages do you see in using the |
|
Thanks for your info @tvannahl 👍
No, he doesn't. He just hates systemd. |
choice, reliability (do one thing and do that good, systemd is quite the oposite), battleground proven, ... or if we go by the exact wording from the unix philosophy: do one thing and do it well |
|
and it's true... I'm not a fan of systemd... and that would be putting it mildly |
|
@tvannahl backward compatibility. systemd doesn't work on wheezy. |
|
@diederikdehaas Is has been a pleasure. I can understand that you're more attracted to a init independent solution. @Mausy5043 stated a good point in the backward compatibility to wheezy. I do have no need for wheezy anymore since I have everything ported to jessie but there are probably many out there who still require wheezy. |
|
I know that this thread has strayed a bit, but I just wanted to throw in that the build-in Watchdog (part of the processor) has word best from me as is setup below. Everyone sort of seems ot have their own opinion on how to set it up from everything I've read, so I thought I'd throw my ¢2 Uncomment the line: This part is more optional, and is simply to have the system be more careful - it helped me with a couple critical Pi's that would get stuck. I hope this isn't too late to be of use for you in adding a WDT option! |
|
since this issue is marked for the v1.1.x milestone, we need to do something about it... I personally feel that this is something that's very user specific and as such should be left to the individual end-user to decide on, and of course implement in a way that suits their preference... that said, since we're stuck with systemd, I guess we could load the hardware watchdog module, and setting systemd up to make use of it... I would like to have it as an (by default on) option, though 💭 this way anyone, who would like to use a different (better? 😈 ) way of handling the watchdog, can turn the systemd support off and enable the watchdog the way it's suits them... this would include just the following:
this would cause systemd to ping the watchdog every 10 seconds, and the SOC to restart itself after 20 seconds, should the pinging stop... this way, the worst case scenario is that if something goes horribly wrong, the device will reboot itself after 30s thoughts? |
Those upstream bugs have been fixed and I have just requested a backport to stable for those 798294 793309. Hopefully he'll do it (regardless whether we'll use it or not). |
I'm not going to block #390 but if the |
nope... I don't... just wanted to get the ball rolling 😇 |
well... not anymore, that is... I was acting on the assumption that systemd would actually work as "advertised"... 😒 so yeah, if the watchdog package works better, I'm all for it... Just close #390 when you feel it's not needed (for discussions / tests) anymore, and go with the watchdog package 👍 |
Add watchdog functionality. Solves issue #298.
|
Support for a watchdog is added with PR#390. Default setting is disabled. Users may enable the watchdog by adding Closing this issue. Please re-open if you think the issue is not resolved. |
Apparently the Pi has a hardware watchdog timer, see http://blog.ricardoarturocabral.com/2013/01/auto-reboot-hung-raspberry-pi-using-on.html
It could be a nice feature to add.
The text was updated successfully, but these errors were encountered: