Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Like the summary says. If I log in from the command line, and run startx, then all is well. If I log in from the GUI in init state 5, it ignores the contents of ~/.Xclients Version-Release number of selected component (if applicable): xorg-x11-xinit-1.0.7-6.fc9.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install F9 2. Log in from the GUI in init state 5 3. Actual results: Default GNOME session appears Expected results: The apps in ~/.Xclients to be started, as was the case in previous versions of Fedora. Additional info: Not sure if this should be logged against xorg-x11-xinit or whatever the graphical login screen is these days.
I have the same problem on the current RawHide. Digging through some of the xinit scripts (like (/etc/X11/xinit/Xsession) reveals that only in the event that no window managers can be started that it bothers to look at ~/.xsession and ~/.Xclients how is a user supposed to run scripts on X startup this way? I have some xset and xvattr commands to run on X startup and would like to do so in a window manager agnostic way. xorg-x11-xinit-1.0.9-4.fc10.i386
I too just ran into this. This behavior deviates from the expected behavior of X and should be added to the /etc/X11/xinit/Xsession file that is executed by gdm on login.
Seen on FC10 also. After upgrading my fc7 to fc10 and re-logging in, my .Xclients is no longer touched; I get gnome regardless. (my .Xclients normally runs startkde) It looks like a change to /etc/X11/xinit/Xsession recently where gnome-session was put into the case for gnome is causing this; the code to run .Xclients is below that but now never gets called. ($1 is "gnome-session" it seems). Related, the /etc/gdm/custom.conf in fc10 is basically empty; previously it was full of stuff, notably this was in there by default: DefaultSession=default.desktop which, if worked would cause /usr/share/gdm/BuiltInSessions/default.desktop to be used, and Exec=default is in there which would cause Xsession to run .Xclients. However in FC10, /usr/share/gdm/BuiltInSessions/default.desktop doesn't exist (that I can find in any package) and even putting the FC7 one back doesn't seem to work with the above DefaultSession. So without hacking the system, I can't see a general way for .Xclients to be run anymore. I've tried putting DISPLAYMANAGER=KDM in /etc/sysconfig/desktop but that only affects which dm is used by prefdm, and setting DESKTOP=KDE in there would theoretically make all sessions use KDE; not quite what I want, but it doesn't work anyway; I still end up with gnome. Adding set -- default to the top of Xsession fixes it, but it shouldn't be necessary to do that; as Xsession is not a system config file.
You need to install xorg-x11-xinit-session to use .Xclients. See the release notes for Fedora 9 for details.
I installed xorg-x11-xinit-session but that makes no difference. It supplies /usr/share/xsessions/xinit-compat.desktop which seems to provide some of the hooks needed (replacing default.desktop in fc7) However as $1 to /etc/gdm/Xsession is "gnome-session", it doesn't get used. What controls args given to Xsession? ie: where does "gnome-session" come from and how do you override it sensibly? custom.conf entry? (where is custom.conf documented nowadays?) Also I can't find the section in the FC9 release notes you are referring to. Can you post a link please.
After installing the package, you need to make a change in the UI to say "use my .Xclients file". First, click on your username, then at the bottom panel of the screen you'll see a drop down menu that says Session:. From there choose "User Script" and then on your .Xclients file will be honored. The release notes are here: http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Desktop.html#sn-GNOMEDisplayManager
You are supposed to be able to set this as the DefaultSession key in /etc/gdm/custom.conf, but that method doesn't work under F9 (I haven't tried it under F10). http://projects.gnome.org/gdm/docs/2.14/configuration.html I think that this behavior is 'broken', in that it deviates from how X has worked for years. It certainly makes it more difficult to automate execution of .Xclients than it used to be.
In response to Ray's comments, selecting "User Script" does indeed cause .Xclients to run, but only for the *one* session. This is not acceptable to our environment, either for me or our call center users ... so it looks like I have to hack /etc/gdm/Xsession in kickstart until something proper is done about this.
Hi Ian, It should remember which selection each user chooses permanently (until that user changes it the next time).
I still think that there should be a system-wide option somewhere in the system to run .Xclients if it exists without the user having to remember to do it. However I'm guessing that this preference is stored in ~/.dmrc, and if so then we can just create that file for all our users and put it in our user setup template. As for persistance, I think the problem I'm seeing is that .dmrc can't be updated on my system due to some selinux interference This seems to match the behaviour mentioned in http://forums.fedoraforum.org/showthread.php?t=205773 as I'm seeing gdm-session-worker complaining about permissions Jan 17 09:14:22 palace kernel: type=1400 audit(1232144062.604:20): avc: denied { write } for pid=6205 comm="gdm-session-wor" name="iand" dev=sda5 ino=3366913 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system _u:object_r:user_home_t:s0 tclass=dir Jan 17 09:14:22 palace kernel: type=1400 audit(1232144062.606:21): avc: denied { write } for pid=6205 comm="gdm-session-wor" name="iand" dev=sda5 ino=3366913 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system _u:object_r:user_home_t:s0 tclass=dir Jan 17 09:14:22 palace kernel: type=1400 audit(1232144062.606:22): avc: denied { write } for pid=6205 comm="gdm-session-wor" name="iand" dev=sda5 ino=3366913 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system _u:object_r:user_home_t:s0 tclass=dir Jan 17 09:14:22 palace gdm-session-worker[6205]: WARNING: unable to log session Jan 17 09:14:22 palace kernel: type=1400 audit(1232144062.607:23): avc: denied { write } for pid=6205 comm="gdm-session-wor" name="iand" dev=sda5 ino=3366913 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system _u:object_r:user_home_t:s0 tclass=dir Jan 17 09:14:22 palace gdm-session-worker[6205]: WARNING: could not save session and language settings: Failed to create file '/iand/.dmrc.M0J5NU': Permission denied Although the label on my home directory seems ok... drwx------ iand tech system_u:object_r:user_home_t /iand (its not in /home as its a laptop and I auto-mount /home when in the office)
oh, and I did change things a little to accommodate my odd home dir place... semanage fcontext -a -t user_home_t '/iand(/.*)?' restorecon -R /iand just so sshd would let me login.
On my system the context is user_home_dir_t not user_home_t Maybe that's your problem? If not, would you mind filing a bug report against selinux-policy? Dan will know what's going on right away.
You are correct, my mistake. semanage fcontext -a -t user_home_dir_t '/iand' restorecon /iand fixed that, and now .dmrc and the preference sticks across logins.