After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745286 - gdm should not fallback to LANG=C when accountservice has no language set and when a locale was already configured
gdm should not fallback to LANG=C when accountservice has no language set and...
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
3.14.x
Other Linux
: Normal major
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-27 14:09 UTC by Raphael Hertzog
Modified: 2015-02-27 19:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDM log proving that GDM_LANG/LANG gets set to C (31.95 KB, text/plain)
2015-02-27 15:51 UTC, Raphael Hertzog
  Details
systemd: import language into daemon environment (2.60 KB, patch)
2015-02-27 18:40 UTC, Ray Strode [halfline]
none Details | Review

Description Raphael Hertzog 2015-02-27 14:09:19 UTC
On my system (based on a customized Debian Jessie) gdm 3.14 seems to always set LANG=C on a fresh live system even though the system wide PAM setting sets LANG=en_US.UTF-8.

When I tried to debug, I saw that AccountService always returns Language="" and Session="" and in this situation gdm will fallback to set LANG=C. This doesn't look very bad at first look but it has a nasty consequence: C is not an UTF-8 locale and thus gnome-terminal refuses to start.

A better behaviour would thus be to leave LANG unmodified in that situation... so that the system wide setting prevails over the (bad) non-answer of AccountService.

(FTR this is on a kali system so the user we use to login is actually root)

accountsservice 0.6.37-3+b1
gdm3 3.14.1-3
Comment 1 Ray Strode [halfline] 2015-02-27 14:31:14 UTC
i don't believe we do fallback to LANG=C in GDM.
Comment 2 Raphael Hertzog 2015-02-27 15:35:36 UTC
Well, it might not an explicit fallback but it's still the end-result.

I can assure you that:
- gdm-session-worker had LANG=en_US.UTF-8 (checked in /proc/<pid>/environ) inherited from the system wide setting
- the launched session had GDM_LANG=C and LANG=C

I'm not familiar with the gdm code base to be able to explain it from a cursory look, although I have the feeling that it might be related to the fact that the language returned by AccountService is an empty string (and not NULL).
Comment 3 Ray Strode [halfline] 2015-02-27 15:44:13 UTC
so we end up running:

setlocale (LC_MESSAGES, NULL);

to get the default language in the case one isn't set.  What does /proc/<pid>/environ say for the main daemon process?
Comment 4 Raphael Hertzog 2015-02-27 15:51:08 UTC
Created attachment 298096 [details]
GDM log proving that GDM_LANG/LANG gets set to C

And just to give more useful data, I attach the output of journalctl when I start gdm3 (in autologin mode, but the result is similar with a subsequent login).

And the relevant lines:

GdmSessionSettings: saved session is
GdmSessionWorker: Saved session is
GdmSessionSettings: saved language is
GdmSessionWorker: Saved language is
[...]
GdmSessionWorker: Set PAM environment variable: 'GDM_LANG=C'
[...]
GdmSessionWorker: Set PAM environment variable: 'LANG=C'
Comment 5 Raphael Hertzog 2015-02-27 16:07:56 UTC
Short summary: the main daemon process only has PATH set in its environment (matching systemd's default environment), for the the gdm-session-worker the result do vary between autologin/launch-environment where the LANG is not set and a normal (non-autologin) session where LANG=en_US.UTF-8:

After gdm started and connected the user in autologin mode:
root@kali:~# ps x|grep gdm
 1268 ?        Ssl    0:00 /usr/sbin/gdm3
 1284 ?        Sl     0:00 gdm-session-worker [pam/gdm-autologin]
 1682 pts/1    S+     0:00 grep gdm
root@kali:~# cat /proc/1268/environ 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binroot@kali:~# 
root@kali:~# cat /proc/1284/environ 
GDM_SESSION_DBUS_ADDRESS=unix:abstract=/tmp/dbus-Oo5YgCsaPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binWINDOWPATH=7

I log out, then I get this:
root@kali:~# ps x|grep gdm
 1268 ?        Ssl    0:00 /usr/sbin/gdm3
 1725 ?        Sl     0:00 gdm-session-worker [pam/gdm-launch-environment]
 1809 pts/1    S+     0:00 grep gdm
root@kali:~# cat /proc/1725/environ 
GDM_SESSION_DBUS_ADDRESS=unix:abstract=/tmp/dbus-8dcMuO1dPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binWINDOWPATH=7:7

I login manually and I get this:
root@kali:~# ps x|grep gdm
 1268 ?        Ssl    0:00 /usr/sbin/gdm3
 1823 ?        Sl     0:00 gdm-session-worker [pam/gdm-password]
 2136 pts/1    S+     0:00 grep gdm
root@kali:~# cat /proc/1823/environ 
LANG=en_US.UTF-8GDM_SESSION_DBUS_ADDRESS=unix:abstract=/tmp/dbus-B9LIoOgcPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binWINDOWPATH=7:7

Since the PAM configuration might have an impact, I put it here too:
root@kali:~# cat /etc/pam.d/gdm-autologin
#%PAM-1.0
# This is kali-root-login's version of /etc/pam.d/gdm-autologin
auth    requisite       pam_nologin.so
auth    required        pam_permit.so
@include common-account
# SELinux needs to be the first session rule. This ensures that any 
# lingering context has been cleared. Without this it is possible 
# that a module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close
session required        pam_loginuid.so
# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open
session optional        pam_keyinit.so force revoke
session required        pam_limits.so
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 envfile=/etc/default/locale
@include common-session
@include common-password
root@kali:~# cat /etc/pam.d/gdm-launch-environment 
#%PAM-1.0
auth    requisite       pam_nologin.so
auth    required        pam_permit.so
@include common-account
session optional        pam_keyinit.so force revoke
session required        pam_limits.so
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 envfile=/etc/default/locale
@include common-session
@include common-password
root@kali:~# cat /etc/pam.d/gdm-password
#%PAM-1.0
# This is kali-root-login's version of /etc/pam.d/gdm-password
auth    requisite       pam_nologin.so
@include common-auth
auth    optional        pam_gnome_keyring.so
@include common-account
# SELinux needs to be the first session rule. This ensures that any 
# lingering context has been cleared. Without this it is possible 
# that a module could execute code in the wrong domain.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close
session required        pam_loginuid.so
# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open
session optional        pam_keyinit.so force revoke
session required        pam_limits.so
session required        pam_env.so readenv=1
session required        pam_env.so readenv=1 envfile=/etc/default/locale
@include common-session
session optional        pam_gnome_keyring.so auto_start
@include common-password

(kali changes those files only to drop the test that forbids root to login, otherwise they are exactly like they are in Debian's package)
Comment 6 Ray Strode [halfline] 2015-02-27 18:40:59 UTC
Created attachment 298113 [details] [review]
systemd: import language into daemon environment

By default GDM is started with a pretty blank environment.

This commit makes sure that the default locale for the
system is used.
Comment 7 Ray Strode [halfline] 2015-02-27 18:41:22 UTC
mind giving that patch a try and reporting back?
Comment 8 Raphael Hertzog 2015-02-27 19:38:34 UTC
Thanks, it's working correctly with the patch.
Comment 9 Ray Strode [halfline] 2015-02-27 19:42:36 UTC
Attachment 298113 [details] pushed as fbb922c - systemd: import language into daemon environment