I reported this problem a few OS versions back... pre-6. I'm on FreeBSD-6-STABLE, and I've found the dhclient once again "wedged" in a mode that was eating a lot of CPU. The solution is to kill it, and restart. I'm on Comcast's network, so I don't really know if their DHCP server is doing something that FreeBSD's stock dhclient doesn't like; however, I wonder if someone else has noticed this problem, etc. _F
On Sun, Jan 22, 2006 at 02:52:44AM -0500, Forrest Aldrich wrote:> > I reported this problem a few OS versions back... pre-6. I'm on > FreeBSD-6-STABLE, and I've found the dhclient once again "wedged" in a > mode that was eating a lot of CPU. > > The solution is to kill it, and restart. > > I'm on Comcast's network, so I don't really know if their DHCP server is > doing something that FreeBSD's stock dhclient doesn't like; however, I > wonder if someone else has noticed this problem, etc. >Yes, I've also had the same problem (6.0-RELEASE), on Comcast also. I installed isc-dhcp3-client-3.0.3_1 from ports and haven't had a problem since. (crossing fingers ;=) -- Kelly D. Grills kdgrills@the-grills.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 243 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060122/d5ea2839/attachment.bin
On Tue, 2006-Jan-31 15:38:53 -0500, Lodewijk Vge wrote:>On 31-jan-2006, at 14:13, Brooks Davis wrote: > >>At the very least I need a coredump and your executable so I can >>look at variables >>in receive_packet. > >I accidentally killed it with my attempts to make it dump a core >file. so, what should I do the next time it happens to make it dump >core?"kill -QUIT ..." is the generic answer. sigaction(2) provides the definitive list of which signals default to dumping core. -- Peter Jeremy
I've been having a same sort of issue that others have reported. After
dhclient has been running for a random length of time, it suddenly
starts consuming a large amount of CPU. Unfortunately for me, the
longest it tends to run is 48 hours before acting up.
I did get it rebuilt with debug symbols, and got a stack trace from it,
while it was acting up. Hopefully, it will be useful.
Attaching to program: /sbin/dhclient, process 2248
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
0x08051a0d in receive_packet (interface=0x8071000,
buf=0xbfbfdc20 "\002\001\006", len=4096, from=0xbfbfec70,
hfrom=0xbfbfec50)
at /usr/src/sbin/dhclient/bpf.c:308
308 memcpy(&hdr,
&interface->rbuf[interface->rbuf_offset],
(gdb) bt
#0 0x08051a0d in receive_packet (interface=0x8071000,
buf=0xbfbfdc20 "\002\001\006", len=4096, from=0xbfbfec70,
hfrom=0xbfbfec50)
at /usr/src/sbin/dhclient/bpf.c:308
#1 0x08050dc1 in got_one (l=0x80741b0)
at /usr/src/sbin/dhclient/dispatch.c:256
#2 0x08050d58 in dispatch () at /usr/src/sbin/dhclient/dispatch.c:228
#3 0x0804a0d0 in main (argc=1, argv=0xbfbfed3c)
at /usr/src/sbin/dhclient/dhclient.c:429
BTW: For reference I'm running 6.0-RELEASE-p4.
Thanks,
John