Why won't slapd shutdown (kill -0)?
Michael Johnson
ahze at ahze.net
Wed Nov 17 21:10:28 PST 2004
On Nov 17, 2004, at 11:57 PM, Sean McNeil wrote:
> On Wed, 2004-11-17 at 18:36 -0800, Doug White wrote:
>> On Wed, 17 Nov 2004, Sean McNeil wrote:
>>
>>> On Wed, 2004-11-17 at 10:28 -0800, Doug White wrote:
>>>> On Tue, 16 Nov 2004, Sean McNeil wrote:
>>>>
>>>>> This has been happening for a long time with current and hasn't
>>>>> been
>>>>> resolved. When I start up slapd, I cannot stop it without kill -9
>>>>> ing
>>>>> it. It would appear stuck in kse and probably has something to do
>>>>> with
>>>>> kill -0:
>>>>
>>>> Mind expanding on this? The backtrace looks normal for a pthread
>>>> process.
>>>> kill -0 just tests signal delivery; the process is completely
>>>> unaware that
>>>> the probe occured, though. The process may also be unkillable if
>>>> its
>>>> stuck in some sort of I/O wait.
>>>>
>>>> Is the server busy when you signal it?
>>>
>>> Oh, OK. I didn't look at /usr/local/etc/rc.subr too closely. I have
>>> additional information, though....
>>>
>>> It appears that all the threads are destroyed yet it is still in the
>>> thread processing loop. The process is no longer active at all. I
>>> just
>>> had a similar problem happen with vlc where I closed it yet it is
>>> hanging in the same place as slapd with all the threads gone.
>>
>> Interesting... what scheduler are you using?
>
> 4BSD with PREEMPTION on. -CURRENT as of yesterday. This has been an
> issue for quite some time now, however.
>
>>>
>>> Here is the one from vlc:
>>>
>>> (gdb) bt full
>>> #0 _thr_sched_switch_unlocked (curthread=0x955000) at
>>> pthread_md.h:226
>>
>> I can't find a reference to this in that file. Can you run ldd
>> against
>> your vlc binary? I('m curious what thread library it thinks its
>> running.
>
Is this vlc 0.7.2 or 0.8.1?
> /usr/X11R6/bin/vlc:
> libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800955000)
> libintl.so.6 => /usr/local/lib/libintl.so.6 (0x800b48000)
> libz.so.2 => /lib/libz.so.2 (0x800c52000)
> libxvidcore.so.4 => /usr/local/lib/libxvidcore.so.4
> (0x800d65000)
> libfaad.so.0 => /usr/local/lib/libfaad.so.0 (0x800f3f000)
> libvorbis.so.3 => /usr/local/lib/libvorbis.so.3 (0x801087000)
> libvorbisenc.so.2 => /usr/local/lib/libvorbisenc.so.2
> (0x8011b3000)
> libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x801491000)
> libm.so.3 => /lib/libm.so.3 (0x80162c000)
> liba52.so.0 => /usr/local/lib/liba52.so.0 (0x80174e000)
> libtheora.so.0 => /usr/local/lib/libtheora.so.0 (0x80185a000)
> libogg.so.5 => /usr/local/lib/libogg.so.5 (0x801979000)
> libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x801a7e000)
> libpthread.so.1 => /usr/lib/libpthread.so.1 (0x801c7c000)
> libc.so.6 => /lib/libc.so.6 (0x801da6000)
>
> I just ran it again and had a thread sitting at
> _thr_sched_switch_unlocked. Here is the trace for that thread:
>
> (gdb) bt
> #0 _thr_sched_switch_unlocked (curthread=0x1b38c00) at
> pthread_md.h:226
> #1 0x0000000801c8da8f in _nanosleep (time_to_sleep=0x7fffffe8df50,
> time_remaining=0x0)
> at /usr/src/lib/libpthread/thread/thr_nanosleep.c:71
> #2 0x0000000801c8dbd3 in __nanosleep (time_to_sleep=0x7fffffe8df50,
> time_remaining=0x0)
> at /usr/src/lib/libpthread/thread/thr_nanosleep.c:125
> #3 0x000000000042b1f9 in msleep (delay=34369437808) at
> src/misc/mtime.c:309
> #4 0x0000000806a51e02 in OSSThread (p_aout=0x1b38800) at oss.c:624
> #5 0x0000000801c87139 in thread_start (curthread=0x800940070,
> start_routine=0x94d068, arg=0x800940070)
> at /usr/src/lib/libpthread/thread/thr_create.c:343
> #6 0x0000000801df1ff4 in makectx_wrapper (ucp=0x800940060,
> func=0x6636,
> args=0x1) at /usr/src/lib/libc/amd64/gen/makecontext.c:100
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041118/04b7889e/PGP.bin
More information about the freebsd-current
mailing list