The Freifunk watchdog package is actually a rather handy package, since it will monitor any process you want (via periodic cronjob) and restart that service if the active process disappears (aka crashes).  To my knowledge, it doesn't directly start/stop any network interfaces.  But, ff-watchdog does need to be configured to monitor the processes you care about, and to not conflict with any other watchdog-style task.  That conflict may be indirectly causing interfaces to go down or even olsrd to stop in absence of a needed interface.<br>

<br>Its config file is /etc/config/freifunk-watchfog, and here is an example config I've used (for node using coovachilli):<br><br>config process<br>    option process 'dropbear'<br>    option initscript '/etc/init.d/dropbear'<br>
<br>config process<br>    option process 'crond'<br>    option initscript '/etc/init.d/cron'<br>    <br>config process<br>    option process 'olsrd'<br>    option initscript '/etc/init.d/olsrd'<br>
<br>config process<br>    option process 'chilli'<br>    option initscript '/etc/init.d/coovachilli'<br><br>Are you sure you weren't having problems with the ff-gw-check package instead?  I.e. un-installed that package at the same time as un-stinalling ff-watchdog?  I think the gw-check package <i>will muck</i> with default routes and possibly also restart active network interfaces if it can't get a successful ping to <a href="http://freifunk.net" target="_blank">freifunk.net</a> or something.<br>

<br><div class="gmail_quote">On Wed, Apr 24, 2013 at 8:07 AM, Dan Staples <span dir="ltr"><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Moving this discussion to commotion-dev...<br>
<br>
When I was previously setting the wireless interfaces to use channel 9<br>
instead of channel 5, the freifunk watchdog would routinely bring down<br>
the wireless interfaces. And I have no idea why. The only way I got it<br>
to work was uninstalling ff-watchdog. So see if that may be a reason why<br>
wireless interfaces are unavailable...there should be a note about it in<br>
logread.<br>
<br>
I've also noticed that something is killing olsrd on DR1 nodes, without<br>
any clue in the log. The routing table will still have stale routes in<br>
it, indicating that olsrd isn't exiting cleanly. I wonder if it's being<br>
killed by the out-of-memory watchdog. When I was troubleshooting this<br>
before, I wrote a quick script that ran as a cronjob every minute, and<br>
it would pgrep olsrd. If olsrd was running, it would redirect the output<br>
of top into ~/top.out. If olsrd wasn't running, it would move the last<br>
~/top.out as well as logread into a separate directory. That way,<br>
whenever olsrd was killed, there would be a record of top the minute<br>
before it crashed, as well as the log. Would this be useful for<br>
troubleshooting the LTS nodes?<br>
<br></blockquote></div><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br><a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>

</div>