Hi Will,<br><br>I just checked config on a node again (running Attitude Adjustment circa r35xxx), and I found these lines in /etc/crontabs/root which had been commented out:<br><br>#* * * * * /usr/sbin/ff_olsr_test_gw.sh<br>
#*/5 * * * * /usr/sbin/ff_olsr_watchdog<br><br>So, be on the lookout for ff packages that deploy these scripts, although unfortunately it's not clear <i>which</i> package includes these particular files. Maybe freifunk-common?<br>
<br><div class="gmail_quote">On Wed, Apr 24, 2013 at 2:28 PM, Will Hawkins <span dir="ltr"><<a href="mailto:hawkinsw@opentechinstitute.org" target="_blank">hawkinsw@opentechinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for your response, Ben. We just recompiled an image w/o most of<br>
the ff software. We are now testing that image to see if things are any<br>
better. We will definitely note how ff-watchdog may be useful and how<br>
ff-gw-check is the likely culprit ;-)<br>
<br>
Will<br>
<div><div class="h5"><br>
On 04/24/2013 02:17 PM, Ben West wrote:<br>
> The Freifunk watchdog package is actually a rather handy package, since<br>
> it will monitor any process you want (via periodic cronjob) and restart<br>
> that service if the active process disappears (aka crashes). To my<br>
> knowledge, it doesn't directly start/stop any network interfaces. But,<br>
> ff-watchdog does need to be configured to monitor the processes you care<br>
> about, and to not conflict with any other watchdog-style task. That<br>
> conflict may be indirectly causing interfaces to go down or even olsrd<br>
> to stop in absence of a needed interface.<br>
><br>
> Its config file is /etc/config/freifunk-watchfog, and here is an example<br>
> 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<br>
> instead? I.e. un-installed that package at the same time as<br>
</div></div>> un-stinalling ff-watchdog? I think the gw-check package /will muck/<br>
<div class="im">> with default routes and possibly also restart active network interfaces<br>
</div>> if it can't get a successful ping to <a href="http://freifunk.net" target="_blank">freifunk.net</a> <<a href="http://freifunk.net" target="_blank">http://freifunk.net</a>><br>
<div class="im">> or something.<br>
><br>
> On Wed, Apr 24, 2013 at 8:07 AM, Dan Staples<br>
> <<a href="mailto:danstaples@opentechinstitute.org">danstaples@opentechinstitute.org</a><br>
</div><div class="im">> <mailto:<a href="mailto:danstaples@opentechinstitute.org">danstaples@opentechinstitute.org</a>>> wrote:<br>
><br>
> 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>
><br>
><br>
> --<br>
> Ben West<br>
> <a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
</div>> <a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net">ben@gowasabi.net</a>><br>
> <a href="tel:314-246-9434" value="+13142469434">314-246-9434</a> <tel:<a href="tel:314-246-9434" value="+13142469434">314-246-9434</a>><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> _______________________________________________<br>
> Commotion-dev mailing list<br>
> <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
> <a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
><br>
_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
</div></div></blockquote></div><br><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>
314-246-9434<br></div>