Kevin Bonner wrote:
...
> Tested with the CVS head as of this morning and everything looks good to me,
> even the per-client data. I'm hitting a segfault when testing the cases I
> listed in bug#150, but I don't think it is related to the SNMP portion of the
> code. Segfault info is below.
On Monday 16 April 2007 07:52:43 Alan DeKok wrote:
> Kevin Bonner wrote:
> > Try http://bugs.freeradius.org/show_bug.cgi?id=150
> >
> > I doubt that patch will still apply cleanly due to the many recent
> > changes. I'll see if I can test the CVS head later today and submit a
> > newer patch.
>
>
Milan Holub wrote:
> ==> well, I've done the tests with 32 reHUPs and I'm getting
> segmentation fault during the promised cleanup:
> ...when 32nd HUP received:
Ok... after some work with valgrind, the problem should be fixed. The
server shouldn't use more memory after a HUP, and it shouldn't c
Hi Alan,
On Mon, Apr 16, 2007 at 04:39:16PM +0200, Alan DeKok wrote:
> Try 32 HUPs. The memory will increase, but won't grow after that.
>
> At some point in the future, it can be fixed to do more cleanups after
> HUP.
==> well, I've done the tests with 32 reHUPs and I'm getting
segmentatio
Hi Alan,
On Mon, Apr 16, 2007 at 04:49:37PM +0200, Alan DeKok wrote:
> Ok, try now. After some fighting with getting SNMPD to work, I can
> now see the counters incrementing when I query it via snmpwalk.
==> I can confirm with latest cvs head snmp is working after
reload(either via HUP or snmp
Milan Holub wrote:
> ==> I've tested latest cvs head:
> - snmp works until 1st reload(HUP or snmp-write)
> - then it behaves the same as with Kevin's old patch (described in this
> thread) == snmp not working after reload
Ok, try now. After some fighting with getting SNMPD to work, I can
now
Milan Holub wrote:
> Hi Alan,
>
> On Mon, Apr 16, 2007 at 03:18:24PM +0200, Alan DeKok wrote:
>> That memory will be cleaned up after a few more HUPs.
> ==> Are you sure about that?
Yes.
> After 10 HUPs:
> for i in `seq 10`; do echo HUP $i; kill -HUP 16235; sleep 1; done
Try 32 HUPs. The
Hi Alan,
On Mon, Apr 16, 2007 at 03:18:24PM +0200, Alan DeKok wrote:
> That memory will be cleaned up after a few more HUPs.
==> Are you sure about that?
ps axu | grep rad:
freerad 16235 2.2 1.9 9448 4916 pts/0S15:31 0:00
freeradius -X
==> initially we have 9448kb of memory used
Milan Holub wrote:
> - snmp works until 1st reload(HUP or snmp-write)
> - then it behaves the same as with Kevin's old patch (described in this
> thread) == snmp not working after reload
Hmm... OK.
> - debug flags survive reload (good!)
> - with my config each reload eats additional 620k of m
Hi Alan,
On Mon, Apr 16, 2007 at 01:52:43PM +0200, Alan DeKok wrote:
> Kevin Bonner wrote:
> > Try http://bugs.freeradius.org/show_bug.cgi?id=150
> >
> > I doubt that patch will still apply cleanly due to the many recent changes.
> >
> > I'll see if I can test the CVS head later today and subm
Kevin Bonner wrote:
> Try http://bugs.freeradius.org/show_bug.cgi?id=150
>
> I doubt that patch will still apply cleanly due to the many recent changes.
> I'll see if I can test the CVS head later today and submit a newer patch.
Please try the latest CVS. I've added a patch based on yours.
Hi Kevin,
On Thu, Apr 12, 2007 at 06:19:14PM -0400, Kevin Bonner wrote:
> > Try http://bugs.freeradius.org/show_bug.cgi?id=150
> >
> > I doubt that patch will still apply cleanly due to the many recent changes.
> > I'll see if I can test the CVS head later today and submit a newer patch.
>
> It s
Kevin Bonner wrote:
> It surprises me that it still applies cleanly (just offset) with the current
> CVS head.
The SMUX code hasn't changed much. It should probably be replaced
with AgentX code, but that can be done later...
> Feel free to test the patch and report results in the bug or on
On Thursday 12 April 2007 10:32:18 Kevin Bonner wrote:
> On Thursday 12 April 2007 04:40:47 Milan Holub wrote:
> > Radius itself seems to react on radius packets; only snmp is ignored
> > after the snmp-write query. Completely same behaviour is observed when
> > doing reload via HUP signal(using my
On Thursday 12 April 2007 04:40:47 Milan Holub wrote:
> - when trying to force reload using snmp:
> `snmpset -m /devel/freeradius/cvs/radiusd/mibs/RADIUS-AUTH-SERVER-MIB.txt
> -c verysecret localhost radiusAuthServConfigReset.0 i 2`
> then 1st reload is OK but after then when trying to either run t
Milan Holub wrote:
> - when query the radiusAcc and radiusAuth everything works fine(no
> segmentation faults); multiple queries give correct result
Thanks.
> - when trying to force reload using snmp:
> `snmpset -m /devel/freeradius/cvs/radiusd/mibs/RADIUS-AUTH-SERVER-MIB.txt
> -c verysecret
Hi Alan,
On Wed, Apr 11, 2007 at 05:51:16PM +0200, Alan DeKok wrote:
> Milan Holub wrote:
> > Hi all,
> >
> > when I've compiled in snmp support (--with-snmp) on current cvs head I got
> > following segmentation fault(does not matter whether NAS are stored in DB
> > or in clients.conf):
>
>
Milan Holub wrote:
> Hi all,
>
> when I've compiled in snmp support (--with-snmp) on current cvs head I got
> following segmentation fault(does not matter whether NAS are stored in DB or
> in clients.conf):
I just committed fixes for SNMP. I haven't tested it, but the code
that was obviously
Hi all,
when I've compiled in snmp support (--with-snmp) on current cvs head I got
following segmentation fault(does not matter whether NAS are stored in DB or in
clients.conf):
>>>DEBUG OUTPUT START
...
Ready to process requests.
Nothing to do. Sleeping until we see a request.
SMUX read start
19 matches
Mail list logo
