Jaunty won't source .xsession

Bug #355721 reported by Miguel Branco on 2009-04-05
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xinit (Ubuntu)
Low
Unassigned
xorg (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: xinit

Apparently .xinitrc is not sourced at session startup. Could notice that as a gamma correction by monicarc was not called and the screen is extremely bluish.

In fact, ownership of .xinitrc after install was root:root. Even after changing to user:user the problem remains. In .xsession-errors no mention to any .xinitrc sourcing error.

Worked in Intrepid, of course.

Miguel Branco (mpbbranco) wrote :

Ok, so GDM is not meant to source .xinitrc.

Notwithstanding this, it worked in Ibex. Was there a link from .xsession to .xinitrc ?

I have a few xsession errors (like xmodmap), could this cause somme breakage in the sourcing or simply some rule is being enforced that .xinitrc is no more sourced (as despite all, it was ).

Miguel Branco (mpbbranco) wrote :

Actually created .xsession and linked to .xinitrc to no avail.

Am I really the only one experiencing this ? Please let me know if it is a non-issue.

Attached my xsession-errors

summary: - Jaunty won't source xinitrc
+ Jaunty won't source .xsession
Miguel Branco (mpbbranco) wrote :

Hi anyone

Seriously, am I really the only to have this or having noticed it ?

Would believe that such an issue would cause greater feedback, seems pretty serious if true.

affects: xinit (Ubuntu) → xorg (Ubuntu)
oleoleole (ole-gidderikke) wrote :

Won't read $HOME/.xsession here either.

It even ignores the .xsession file when I link it to the Autostart folder for KDE. .xsession file is executable (thoug do other things in this folder start as it should).

Running the .xsession file manually does the trick, but it's annoying.

Bryce Harrington (bryce) wrote :

[No need to have this double-filed against xorg as well]

Changed in xorg (Ubuntu):
status: New → Invalid
Miguel Branco (mpbbranco) wrote :

Ok, didn't notice that the filing against xinit was maintained when changing package.

Will restablish as the issue seems broader than xinit and has received at least one confirmation above,
and cancel the xinit one.

Changed in xorg (Ubuntu):
status: Invalid → New
Changed in xinit (Ubuntu):
status: New → Invalid
Changed in xorg (Ubuntu):
status: New → Confirmed
Bryce Harrington (bryce) wrote :

xinit manages the .xsession file, not xorg

Changed in xorg (Ubuntu):
status: Confirmed → Invalid
Changed in xinit (Ubuntu):
status: Invalid → Confirmed
importance: Undecided → Low

I don't believe that this bug is valid. My read of the scripts in Xsession.d is that .xsessionrc will be sourced no matter what session you choose, not .xsession or .xinitrc.

I don't know why your .xinitrc was being sourced in previous releases, because the scripts look the same to me, at least back through Hardy. However, it should work if you rename .xinitrc to .xessionrc, I think.

Miguel Branco (mpbbranco) wrote :

I disagree. Can´t see since when .xsessionrc is the default sourced file, this would be against a lot of legacy.

Yes it was so if the scripts look the same the issue is elsewhere, that´s exactly the point. Maybe a permission issue. And in the scripts if you read all of them you will find that usexsession and altusersession should be sourced. Maybe these are not being correctly set.

I have tried on Hardy, Intrepid, and Jaunty, and they are all consistent in their behavior where .xsession is concerned. The only way to have .xsession executed is to select the 'Run Xclient script'
session type in gdm. Note that .xsession is not "sourced" in any of these releases, but executed, and when executed, it is responsible for handling all session startup, perhaps by running gnome-session (for example) after performing some additional startup.

All three releases are consistent in their handling of .xsessionrc, too. The purpose of .xsessionrc in all three releases is to handle common session initialization tasks. This file is indeed sourced, if it exists. The same is true of .xprofile. This file is used no matter which gdm session type you choose.

The purpose of .xinitrc is the same as .xsession, except that .xinitrc applies when you run startx (or just xinit) from the command line after a console login, which .xsession is used when you login using a graphical interface like gdm or xdm.

So, if you want a file to be sourced, that file is .xsessionrc, not .xsession. If, on the other hand, you want a script to be executed to startup your X session for you, then you should use .xsession and you should select the 'Run Xclient script' session type.

Please be more clear about exactly what you are doing. Are you logging in through gdm? Are you starting X from within a console login session? And if you are logging in with gdm, which session type did you select? Also, are you expecting the script to be sourced or executed?

Miguel Branco (mpbbranco) wrote :

Well, actually linking .xsessionrc to .xinitrc breaks my system ... No login (some xrdb error message).

But manifestly in this case it was sourced. So is having my login broken the correct behaviour ? Will search about this xrdb error.

I' m an average user step-upgrading since 6.04 if 'm not wrong and running standard gdm logins. Actually I've only noticed that I hadn't an .xsession file when this bug ocurred and because i recently installed monica to adjust my yellowish/blueish screen which installs in .xinitrc (which definitely worked well under ibex but can't tell before because I'm not sure I had already monica under hardy).

Bryce Harrington (bryce) on 2009-09-02
tags: added: jaunty
Miguel Branco (mpbbranco) wrote :

I would propose to close this bug as no one really cares and most probably will never get assigned and eventually fixed.
It seems like xsessionrc is the one config file to use, i guess if one wants xsession too it has only to change that in /etc/X11/Xsession.d/40x11-common_xsessionrc

Miguel Branco (mpbbranco) wrote :

Well Jaunty is quite over and better to close this

Changed in xinit (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers