Bjørn Mork wrote:
George Chelidze <[EMAIL PROTECTED]> writes:
as soon as I send accounting stop packet to radius, test.pl executes and
becomes a zombie. (I tried bash script, c program with the same result.)
3890 ? Ss 0:00 /usr/local/freeradius/sbin/radiusd
3893 ? Z 0:00 \_ [test.pl] <defunct>
As far as I know, this should have been fixed in 1.0.3 and I doubt it's
debian specific, as I know 0.93 works on another RH 7.3 without a
problem (In fact zombie is listed there as well but disappears after
several seconds).
Any ideas/suggestions?
Is it replaced by a new zombie the next time you send an accounting
packet, or do the zombies add up?
Zombies add up even when I recompile without --without-threads option.
The way I read rad_fork(), it will call reap_children() every time it
is called. But there's not necessarily anything calling
reap_children() inbetween. This means that zombies will only live
forever on servers without traffic.
You should probably read the comment in front of reap_children() in
src/main/threads.c. I believe it explains why this design was chosen.
If I understood things correctly, if I compile radius without threads
support reap_children() won't be called and zombies will add up? I am
not against compiling it with threads support, but unfortunately I get
something like this:
18439 ? Ss 0:00 /usr/local/freeradius/sbin/radiusd
18440 ? S 0:00 \_ /usr/local/freeradius/sbin/radiusd
18441 ? S 0:00 \_ /usr/local/freeradius/sbin/radiusd
18460 ? Z 0:00 | \_ [test.pl] <defunct>
18492 ? Z 0:00 | \_ [test.pl] <defunct>
18442 ? S 0:00 \_ /usr/local/freeradius/sbin/radiusd
18480 ? Z 0:00 | \_ [test.pl] <defunct>
18443 ? S 0:00 \_ /usr/local/freeradius/sbin/radiusd
18483 ? Z 0:00 | \_ [test.pl] <defunct>
18444 ? S 0:00 \_ /usr/local/freeradius/sbin/radiusd
18486 ? Z 0:00 | \_ [test.pl] <defunct>
18445 ? S 0:00 \_ /usr/local/freeradius/sbin/radiusd
18489 ? Z 0:00 \_ [test.pl] <defunct>
Bjørn
Thanks a lot for your reply
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
