[ietf83-tech] Had lost both freeradius processes (.1x was affected)

[Bjoern A. Zeeb]

On Tue, 27 Mar 2012, Morgan Sackett wrote:

> Interesting.  I've seen this before at a few other meetings, though
> never IETF meetings.  In that case it was very intermittent, so I
> thought it was probably a buggy client. I was never able to run a long
> enough diagnostics to verify my suspicion. It may be the same case.
> Do the servers at the meeting have enough disk space and I/O head room
> for a 2-3 day packet capture?  If so, it may be worthwhile to start a
> debug on the inbound DHCP traffic to see if you can find the back
> packet.
>
> Otherwise, write a watchdog script to kick that buggy junk when it hangs.

[skip this as it is a rant]

While we'd have the disk space when adding another disk to not pollute
the services images -- forget that.  We are running freeradius1 still.
The sumamry is that the code is crap.   Ok, I am biased.  I had sent them
6 or 7 patches amgost to fix core dumps a couple of years ago and all were
rejected for NIH.  I had tried it a couple of times again afterwards
with thrilling crashing effects but then not anymore in years.

[/skip this as it is a rant]


Looking at things it seems the SIGHUP after log rotation after 27 days
killed it last night.  So yes it's a code bug in the version we are
running.  We'll hopefully not be affected by that again during this
meeting given it should not happen until in 26.7 days.


For the defense of freeradius - version 2 should be significantly better
I have been told repeatedly.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.