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
segmentation
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
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.
Please try
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.
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 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 submit a newer
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
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 by
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 memory
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 see
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 surprises
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):
I just
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
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 the
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
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
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
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
18 matches
Mail list logo
