Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Oct 2011 21:02:17 +0200
From:      Michael Bushkov <bushman@freebsd.org>
To:        Artem Belevich <art@freebsd.org>
Cc:        =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= <des@des.no>, hackers@freebsd.org, =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no>
Subject:   Re: Does anyone use nscd?
Message-ID:  <CANkaO_F%2BeenvB-GSSJ-iZf8Lzu3TV0pLEokw_OjM-wNRXvHR3Q@mail.gmail.com>
In-Reply-To: <CAFqOu6gf9LW2cRHAerTy5d29WN6y8mcWgUHwbKeAEBPXNwVz-w@mail.gmail.com>
References:  <86sjn84wco.fsf@ds4.des.no> <alpine.BSF.2.00.1110041800290.18373@mail.fig.ol.no> <86obxw4s4w.fsf@ds4.des.no> <CAFqOu6iw12BbvmS9NH3fNzWqQR1YvYrqyM6JFrYDfs2=HQ3w_w@mail.gmail.com> <86fwj84p8i.fsf@ds4.des.no> <CAFqOu6gf9LW2cRHAerTy5d29WN6y8mcWgUHwbKeAEBPXNwVz-w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
There are probably 2 things here:
1. There's some error in nsswitch<->nscd communication protocol that
causes nsswitch to write into the closed socket. This is not trivial
to investigate and will require analyzing nscd and client process logs
side by side (and possibly adding some more logging).
2. Consequences of the aforementioned problem can probably be
corrected by using _setsockopt(..., SO_NOSIGPIPE) in
__open_cached_connection() in nscachedcli.c
(http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/nscachedcli.c?rev=
=3D1.3).

I have no access to FreeBSD desktop at the moment - Artem, it would be
cool if you can try the second solution.

Cheers,
Michael

2011/10/5 Artem Belevich <art@freebsd.org>:
> 2011/10/4 Dag-Erling Sm=F8rgrav <des@des.no>:
>> Any chance of getting a backtrace from an unpatched nscd? =A0Ideally wit=
h
>> the change described here:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/136073#reply1
>>
>> To test, stop nscd, then run it from the command line like so:
>>
>> $ su -
>> # cd /tmp
>> # ulimit -c 0
>> # /usr/sbin/nscd -nst
>> (do something in another terminal that causes it to crash)
>> # echo backtrace | gdb -batch -x /dev/stdin /usr/sbin/nscd nscd.core
>>
>> and send me the output from both nscd and gdb once it crashes.
>
> In my case it's top that dies with SIGPIPE. nscd keeps running just
> fine. So, there's no backtrace from nscd.
>
> top receives SIGPIPE after it tries to write to the socket with nscd
> on the other end. Apparently nscd closes connection on its end.
> Running ktrace on top I see that before the write to nscd socket,
> there's a read that returned 0 bytes.
>
> Here's top's backtrace. Alas I don't have libc with debug symbols handy:
>
> Program received signal SIGPIPE, Broken pipe.
> 0x0000000800abe8cc in write () from /lib/libc.so.7
> (gdb) where
> #0 =A00x0000000800abe8cc in write () from /lib/libc.so.7
> #1 =A00x0000000800aa3f44 in ftell () from /lib/libc.so.7
> #2 =A00x0000000800aa415f in ftell () from /lib/libc.so.7
> #3 =A00x0000000800aa2031 in __h_errno () from /lib/libc.so.7
> #4 =A00x0000000800a98311 in nsdispatch () from /lib/libc.so.7
> #5 =A00x0000000800a84d95 in getpwent_r () from /lib/libc.so.7
> #6 =A00x0000000800a84911 in acl_get_brand_np () from /lib/libc.so.7
> #7 =A00x0000000000404f7b in machine_init (statics=3D0x7fffffffe770,
> do_unames=3D1 '\001') at /usr/srcdir/src.git/usr.bin/top/machine.c:258
> #8 =A00x000000000040a9ab in main (argc=3D1, argv=3D0x7fffffffe8c8) at
> /usr/srcdir/src.git/usr.bin/top/../../contrib/top/top.c:464
>
> --Artem
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"
>
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANkaO_F%2BeenvB-GSSJ-iZf8Lzu3TV0pLEokw_OjM-wNRXvHR3Q>