On 10.04.2019 11:21, Vincent Lefevre wrote:
> On 2019-04-10 04:06:08 +0200, Branko Čibej wrote:
>> On 10.04.2019 03:29, Vincent Lefevre wrote:
>>> On 2019-04-09 20:09:26 +0200, Branko Čibej wrote:
>>>> The only problem with that idea is that svnseve doesn't use unscd at
>>>> all, or any kind of LDAP access.
>>> Are you so sure about that? A "strace svnserve -t"[*] shows it
>>> reads the /etc/nsswitch.conf file. With "ltrace", I can see that
>>> svn_user_get_name is called, and I'm wondering whether this is
>>> the cause.
>>
>> That just calls apr_uid_name_get(), so the call chain is
>> svnserve->APR->glibc. The latter's implementation would look at
>> nsswitch.conf. That suggests that is is related to user configuration
>> somehow. But I don't know much about that topic.
>>
>> The name caching daemon is something glibc would use directly, most likely.
> Yes, what happens to get the user name depends on the nsswitch.conf.
> The user name is not stored on this machine, so I assume that the
> glibc function yields a connection to this daemon. Then I don't know
> whether the hang occurs there or an error is reported but somewhere
> the error makes the process hang.
I think that svnserve would only use that function to find the current
user's home directory, to locate the config files. And that seems wrong
because svnserve has no business looking at the client's config area ...
Still, I don't see from the code how it could hang. The homedir is
either found or not, and if it's not, it's ignored.
-- Brane
Received on 2019-04-11 04:22:33 CEST