[Commotion-dev] [OTI-Tech] LTS Testing Update

Wed Apr 24 22:49:54 UTC 2013

A few notes to consider after some testing today with LTS and at the office:

- Collectd "stalled" one of the nodes at LTS (where collectd is still
enabled)

- Stations seem to lose their mind w.r.t IBSS RSN and authorization. I'm
watching debugging output from wpa_supplicant on one of the nodes in the
office to see if I can determine the problem. Of course, it's working
great now :-)

- luci_splash got itself into a nice "wedge" on one of the LTS nodes. I
am going to do my best to get it unstuck. If we continue to see the
problem, we'll have to take a hard look at pushing the splash rewrite to
a higher priority.

Will

On 04/24/2013 04:26 PM, Ben West wrote:
> Hi Will,
> 
> 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:
> 
> #* * * * *      /usr/sbin/ff_olsr_test_gw.sh
> #*/5 * * * *    /usr/sbin/ff_olsr_watchdog
> 
> So, be on the lookout for ff packages that deploy these scripts,
> although unfortunately it's not clear /which/ package includes these
> particular files.  Maybe freifunk-common?
> 
> On Wed, Apr 24, 2013 at 2:28 PM, Will Hawkins
> <hawkinsw at opentechinstitute.org <mailto:hawkinsw at opentechinstitute.org>>
> wrote:
> 
>     Thanks for your response, Ben. We just recompiled an image w/o most of
>     the ff software. We are now testing that image to see if things are any
>     better. We will definitely note how ff-watchdog may be useful and how
>     ff-gw-check is the likely culprit ;-)
> 
>     Will
> 
>     On 04/24/2013 02:17 PM, Ben West wrote:
>     > 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.
>     >
>     > Its config file is /etc/config/freifunk-watchfog, and here is an
>     example
>     > config I've used (for node using coovachilli):
>     >
>     > config process
>     >     option process 'dropbear'
>     >     option initscript '/etc/init.d/dropbear'
>     >
>     > config process
>     >     option process 'crond'
>     >     option initscript '/etc/init.d/cron'
>     >
>     > config process
>     >     option process 'olsrd'
>     >     option initscript '/etc/init.d/olsrd'
>     >
>     > config process
>     >     option process 'chilli'
>     >     option initscript '/etc/init.d/coovachilli'
>     >
>     > 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 /will muck/
>     > with default routes and possibly also restart active network
>     interfaces
>     > if it can't get a successful ping to freifunk.net
>     <http://freifunk.net> <http://freifunk.net>
>     > or something.
>     >
>     > On Wed, Apr 24, 2013 at 8:07 AM, Dan Staples
>     > <danstaples at opentechinstitute.org
>     <mailto:danstaples at opentechinstitute.org>
>     > <mailto:danstaples at opentechinstitute.org
>     <mailto:danstaples at opentechinstitute.org>>> wrote:
>     >
>     >     Moving this discussion to commotion-dev...
>     >
>     >     When I was previously setting the wireless interfaces to use
>     channel 9
>     >     instead of channel 5, the freifunk watchdog would routinely
>     bring down
>     >     the wireless interfaces. And I have no idea why. The only way
>     I got it
>     >     to work was uninstalling ff-watchdog. So see if that may be a
>     reason why
>     >     wireless interfaces are unavailable...there should be a note
>     about it in
>     >     logread.
>     >
>     >     I've also noticed that something is killing olsrd on DR1
>     nodes, without
>     >     any clue in the log. The routing table will still have stale
>     routes in
>     >     it, indicating that olsrd isn't exiting cleanly. I wonder if
>     it's being
>     >     killed by the out-of-memory watchdog. When I was
>     troubleshooting this
>     >     before, I wrote a quick script that ran as a cronjob every
>     minute, and
>     >     it would pgrep olsrd. If olsrd was running, it would redirect
>     the output
>     >     of top into ~/top.out. If olsrd wasn't running, it would move
>     the last
>     >     ~/top.out as well as logread into a separate directory. That way,
>     >     whenever olsrd was killed, there would be a record of top the
>     minute
>     >     before it crashed, as well as the log. Would this be useful for
>     >     troubleshooting the LTS nodes?
>     >
>     >
>     >
>     > --
>     > Ben West
>     > http://gowasabi.net
>     > ben at gowasabi.net <mailto:ben at gowasabi.net>
>     <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
>     > 314-246-9434 <tel:314-246-9434> <tel:314-246-9434 <tel:314-246-9434>>
>     >
>     >
>     > _______________________________________________
>     > Commotion-dev mailing list
>     > Commotion-dev at lists.chambana.net
>     <mailto:Commotion-dev at lists.chambana.net>
>     > https://lists.chambana.net/mailman/listinfo/commotion-dev
>     >
>     _______________________________________________
>     Commotion-dev mailing list
>     Commotion-dev at lists.chambana.net
>     <mailto:Commotion-dev at lists.chambana.net>
>     https://lists.chambana.net/mailman/listinfo/commotion-dev
> 
> 
> 
> 
> -- 
> Ben West
> http://gowasabi.net
> ben at gowasabi.net <mailto:ben at gowasabi.net>
> 314-246-9434