On 10/19/2015 04:21 PM, Lukas Slebodnik wrote:
On (19/10/15 16:03), Michal Židek wrote:
> Hi,
>
> attached is patch to fix ticket:
>
https://fedorahosted.org/sssd/ticket/2785
>
> And one additional patch to add DEBUG message.
>
> Michal
>From 3227027c3680b4503477135608969ca904e491c7 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek(a)redhat.com>
> Date: Mon, 19 Oct 2015 15:38:08 +0200
> Subject: [PATCH 1/2] util: Continue if setlocale fails
>
> Fixes:
>
https://fedorahosted.org/sssd/ticket/2785
>
> setlocale needs some environment variables
> to be set in order to work. These variables
> are not present in some special cases. We
> should not fail completely in these cases
> but continue with the compatible C locale.
> ---
> src/sss_client/ssh/sss_ssh_client.c | 4 +++-
> src/tools/tools_util.c | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/sss_client/ssh/sss_ssh_client.c
b/src/sss_client/ssh/sss_ssh_client.c
> index 0d206ef..ea7a1cc 100644
> --- a/src/sss_client/ssh/sss_ssh_client.c
> +++ b/src/sss_client/ssh/sss_ssh_client.c
> @@ -50,7 +50,9 @@ int set_locale(void)
>
> c = setlocale(LC_ALL, "");
> if (c == NULL) {
> - return EIO;
> + /* If setlocale fails, continue with the compatible
> + * C locale. */
I'm not sure wehter "compatible" is the best explanation.
I think that "continue with the default" would suit better.
BTW: man setlocale(3) says:
On startup of the main program, the portable "C" locale is selected
as
default. A program may be made portable to all locales by calling:
setlocale(LC_ALL, "");
Would you also mind to write integration test?
I can test on command line with:
[root@host ~]# LC_ALL="adasd" sss_cache -E
Error setting the locale
[root@host ~]# echo $?
5
LS
Thank you Lukas!
I added the integration test for this. I added
new file for tests that require LOCAL domain
only (no LDAP). I plan to add more tests here
later.
As we already discussed offline. I temporarily
worked around the issue with failing memcache
test by not removing the memcache files.
Nick asked me to provide some explanation on the
issue so I put it here, please correct me if I
say something wrong.
The problem seems to be that the nss client code only
checks validity of the memcache when the
memcache context is created. Long living
application only check the validity once and
then use file descriptor to manipulate the
cache until they are finished. Pytest is
one such application. If we use the python
pwd and grp wrappers, we initialize memcache
context in Pytest. If we later remove
the memcache files as part of teardown
and create new memcache files for new
tests, Pytest still uses the old file descriptors
so calls to pwd and grp wrappers will
work with the deleted memcache files.
See the attached patches.
Thanks!
Michal