Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454657 - ~/.Xclients ignored by graphical login process
Summary: ~/.Xclients ignored by graphical login process
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-09 15:16 UTC by Tethys
Modified: 2009-01-17 13:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-05 16:25:12 UTC


Attachments (Terms of Use)

Description Tethys 2008-07-09 15:16:24 UTC
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.

Comment 1 Robert de Rooy 2008-09-07 20:38:03 UTC
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

Comment 2 Brian C. Lane 2008-12-11 20:18:37 UTC
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.

Comment 3 Ian Donaldson 2009-01-04 05:04:02 UTC
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.

Comment 4 Ray Strode [halfline] 2009-01-05 16:25:12 UTC
You need to install xorg-x11-xinit-session to use .Xclients.

See the release notes for Fedora 9 for details.

Comment 5 Ian Donaldson 2009-01-14 05:59:19 UTC
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.

Comment 6 Ray Strode [halfline] 2009-01-14 14:34:17 UTC
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

Comment 7 Brian C. Lane 2009-01-14 16:36:25 UTC
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.

Comment 8 Ian Donaldson 2009-01-15 02:32:17 UTC
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.

Comment 9 Ray Strode [halfline] 2009-01-15 14:12:11 UTC
Hi Ian,

It should remember which selection each user chooses permanently (until that user changes it the next time).

Comment 10 Ian Donaldson 2009-01-16 11:22:50 UTC
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)

Comment 11 Ian Donaldson 2009-01-16 11:34:59 UTC
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.

Comment 12 Ray Strode [halfline] 2009-01-16 14:51:42 UTC
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.

Comment 13 Ian Donaldson 2009-01-17 13:25:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.