GNOME Bugzilla – Bug 384603
gdm doesn't reread system language settings when they change
Last modified: 2007-02-27 06:54:12 UTC
One problem the red hat internationalization team noticed during RHEL testing is that GDM doesn't react to system language changes after the locale gets updated. I'll attach a patch I came up with. It's rather platform specific, though.
Created attachment 78112 [details] [review] read system locale when slave or greeter are started.
Hey Ray. I have a question about this patch. GDM builds in either verify-pam.c, verify-shadow.c, or verify-crypt.c depending on configure options (and what configure finds). Anyway this patch seems to modify verify-pam.c but not the others. Is this intentional, or will this feature only work with PAM? Should this be coded for all three files so they work the same way. I'd also like to see if you think the new code might break things when crypt/shadow are used? Perhaps that's what you mean by "platform specific". By the way, when would the user expect locale to get updated, perhaps after a system upgrade or update of packages? If so, would it make more sense to add an UPDATE_CONFIG option that would tell GDM to reread stuff? Then packages that change locales could call this command rather than polling all the time for change? This might be better than a solution that only works when verify-pam is used. Thanks.
The only part of the patch that touches verify-pam.c is the part that flushes the hash table of pam messages -> useful translations. That's a fix specific to the pam backend, that the other two parts don't need. The heart of the fix (which works on all three auth backends) is the gdm_reset_locale () calls that query the system for the current locale and reset the locale in the slave and greeter. The locale will only ever get updated when the user manually updates it by modifying /etc/sysconfig/i18n or by running system-config-language. I'm not a big fan of the UPDATE_CONFIG idea, personally. It's an extra step that doesn't seem to add anything. Note gdm already reads i18n files at startup in the /usr/sbin/gdm shell script. I'm not sure which platform that's for (an earlier red hat release maybe?)
What part of the patch is platform specific (as you say in Comment #1)? Is more work needed to make this patch more general? If you think this patch is ready for 2.17, then you can commit.
The platform specific part is the implementation of gdm_reset_locale. It assumes the system configured locale is stored in /etc/sysconfig/i18n. I believe that is specific to Fedora/RHEL and not true in other linux distributions or on solaris. Note, it won't cause any harm on other platforms, but won't do anything either. I'm not sure there is a nice general or standardized way of reading the currently configured system locale apart from checking the environment which doesn't get updated after the program is started.
Created attachment 78176 [details] /etc/default/init file on Solaris I've attached the /etc/default/init file from Solaris where the default language is specified as LANG. If you want to make the patch work for this file also, that would be cool.
It seems to be pretty much the same format as /etc/sysconfig/i18n , so we should just have to check for the alternative filename
Created attachment 78182 [details] [review] make path name configurable by distributor Can you give this patch a try and tell me if it works when you pass --with-lang-file=/etc/default/init ?
Ray, okay I'll test. Could you explain exactly when GDM will notice the locale file has changed and when the users will see the update? Does GDM stop/restart the GUI programs whenever the locale file changes, or does the new locale only get noticed for newly launched GDM GUI's?
it notices when a new greeter or slave is started. So the use case this was designed for is. User logs in User goes to Administration menu and chooses Language User changes language and logs out At this point GDM shows the new language. One way to test this would be to edit /etc/default/init press ctrl-alt-backspace when it comes back up, gdm should be updated
Created attachment 78353 [details] [review] Patch over Patch for id=78182 I have a question. Why do you override LC_ALL by LANG? On Solaris, Asian locales set LANG but European locales set LC_* How about this attachment? Thanks.
I'm not entirely sure. I think I tried LANG at first and it didn't work like I expected it would. I'll test again, and give better feedback. One potential problem with attachment 78353 [details] [review] is that you unset LANG, LC_ALL, and LC_MESSAGES and then call setlocale(LC_ALL, ""). What happens if the lang file doesn't have a language set in it? I don't know what the expected behavior of setlocale(LC_ALL, "") is when none of the environment variables are set, but I guess it's probalby one of 3 things: 1) no-op 2) revert to "C" 3) undefined behavior If 1) is true, the setlocale call seems superfluous. It's equivalent to just not call setlocale at all. On the other hand, doing that seems like a bad idea, beacuse it means that the LC_ environment doesn't match the programs configured locale, so child processes won't be in the same locale as the parent (and will probably get stuck with "C"). If 2) is true, then that's obviously bad. Likewise for 3). Also, you could replace the strncmp (value "=", line->str, strlen (value "=")) with g_str_has_prefix (line->str, value "=") which is a little clearer. Note also, you never call setlocale for the LANG case which means the patch won't work for brian's example or fedora/rhel systems. Maybe what we should be doing instead is 1) call setenv for every environment variable we see in the config file that matches the locale whitelist (LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME, LANG, LANGUAGES) 2) call setlocale(LC_ALL, "") and let it figure things out based on the new environment
Created attachment 78424 [details] [review] Revised patch id=78353 > Note also, you never call setlocale for the LANG case which means the patch won't work for brian's example or fedora/rhel systems. OK, I see your problem. I revised the patch. > If 2) is true, then that's obviously bad. Likewise for 3). You're right. I removed this. Yes, I know the maintainer's concern however my understanding is it's a slight different topic from this bug. I have another question. Why do you need to load the init file? I agree when the system is booted, gdm should load the value of the init file. But when root user restarts gdm, I think gdm would load the value of the current locale of root user instead of the init file? I mean the compatibility with dtlogin.
Takao, the purpose of this patch is so that if the sysadmin modifies the init file, that GDM will start using the new locales when GDM displays new GUI's. Existing GUI's being displayed will not be updated until the user logs in and logs out again (or switches between gdmchooser/gdmsetup/gdmgreeter), causing the GUI to be redisplayed. Takao, have you tested this patch on Solaris to make sure it works? I assume so since you have updated the patch? If so, then I will go ahead and commit when you work out the fine details you are discussing with Ray.
> Existing GUI's being displayed will not be updated until the user logs in and logs out again (or switches between gdmchooser/gdmsetup/gdmgreeter), causing the GUI to be redisplayed. My understanding is the existing GUI depends on the locale of root user instead of init file. Even though user login/logout or invoke gdmsetup, the GUI locale is not changed. If I missed something, please correct me. Yes, the new patch always load the init file. My question is why gdm needs to load init file instead of the current locale? Sysadmin can invoke GUI with any locales. # gdm-stop # env LANG=ja_JP.UTF-8 gdm I thought our aim will be that when the general user choose the language on gdm login dialog, gdm login dialog reloads the locale and show the new localized GUI likes dtlogin. I just want to clarify the current problem and please go ahead to integrate the pathes. Thanks. Yes, I have tested the provided patch and my patch and it works fine.
Hi Takao, The point is the user shouldn't have to restart gdm to change the language.
> The point is the user shouldn't have to restart gdm to change the language. Thanks for the comment. At the moment, I have no idea to change the locale by none-root user so please go ahead to integrate the patches. I'll try to get time to understand gdm's behavior.
Takao, I think you misunderstand. I believe that this patch is intended to make sure the following situation works. 1. The machine is booted up and starts up with default locale X 2. The sysadmin decides that they wish to change the default locale and modifies the /etc/default/init file to specify a different locale. This is done as root (perhaps by logging into a session as root and changing the file by hand). 3. GDM now just starts using the new locale when showing new GDM GUI's without needing the sysadmin to restart GDM. Note that existing GDM GUI's will not be restarted so the change will not be seen until the user causes a new GUI to be displayed (perhaps by logging in and logging out again). I mention this because in some environments (such as multihead or SunRay), there may be multiple GDM GUI's showing at the same time. It is nice to avoid needing to restart GDM because if people are currently logged into some sessions (say in a multihead environment), restarting GDM would cause their sessions to exit and return them to the login screen, causing any unsaved data to be lost, etc. Previously (before this patch), the sysadmin would need to restart GDM in order for the change to take effect, right? So, there is no need for a non-root user to change the default locale. Does this make more sense? It would be nice, Takao, if you could verify that the above patch works as we intend (as described above).
Brian, thanks for your explanation. I think your point is valuable. Especially in multidisplay and sunray. I'm ok with this suggestion. Previously I thought the /etc/default/init should be loaded by /sbin/init only but I checked some man pages again and I noticed there are no such a restriction. I might mislead that point. I had a test with a single display on Solaris and those patches are fine. I was stacked in SunRay solaris11: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6496648 and unfortunatelly gdm on Solaris SunRay seems to be failed. > It is nice to avoid needing to restart GDM because if people are currently logged into some sessions (say in a multihead environment), restarting GDM would cause their sessions to exit and return them to the login screen, causing any unsaved data to be lost, etc. I agreed with this. > Previously (before this patch), the sysadmin would need to restart GDM in order for the change to take effect, right? Yes, you're right. > So, there is no need for a non-root user to change the default locale. Yes, none-root users don't need to change the default locale however we will need to think in the near future when none-root users choose the languages for their login locales on gdm login dialog(gdmgreeter/gdmlogin), gdm also need to show the localized login dialog with the choosed locale. There are many users who use multiple locales. Please go ahead.
Takao, would you explain exactly what problems you are seeing trying to use GDM in a SunRay environment. You say it is failing, but it would be nice if you opened a new GDM bug with the errors you are seeing and we can work through fixing the problem. It would probably be handy if you turned on GDM debug (set Enable=true in the [debug] section of the GDM configuration file), then restart the GDM daemon by running "gdm-restart". Then put any GDM-related debug messages that get appended to the end of the system log (/var/adm/messages) to the bug report. Also if it seems like the GUI programs are crashing, it would be useful to login via CDE login to your session and set the "DOING_GDM_DEVELOPMENT=1" environment variable, then try to run /usr/lib/gdmgreeter or /usr/lib/gdmlogin by hand from a terminal and see if any useful error messages show up on the console. I notice your pointer to the opensolaris bug which seems related to nsswitch. Is the problems you are seeing with GDM related to this bug? Anyway, I have committed this fix to CVS head.
I've updated bug #108820 with my patch to change the locale of gdmgreeter dynamically. The patch slightly modifies gdm_reset_locale(). Thanks.
*** Bug 408773 has been marked as a duplicate of this bug. ***