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 343297 - gdm logins should fail if a sourced session script fails
gdm logins should fail if a sourced session script fails
Status: RESOLVED WONTFIX
Product: gdm
Classification: Core
Component: general
2.14.x
Other All
: Normal minor
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-29 14:25 UTC by Sebastien Bacher
Modified: 2013-12-16 18:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
xterm.desktop file (183 bytes, application/octet-stream)
2010-04-19 19:09 UTC, Brian Cameron
Details

Description Sebastien Bacher 2006-05-29 14:25:55 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/gdm/+bug/36177

"When /etc/gdm/Xsession sources various other scripts, logging in will still succeed if a script returns a non-zero exit code. All other login managers have the opposite behaviour - logging in fails - because /etc/X11/Xsession includes "set -e".

This can cause failures to go unseen by developers, if they generally use gdm during development (see Malone #35852 for an example).

I really just want all login managers to have the same behaviour here, so if this bug is rejected, I'll go and hassle the xorg team ;-) But "fail early" sounds like it's more appropriate, IMHO."
Comment 1 Brian Cameron 2006-05-29 23:31:33 UTC
I would be happy to accept a patch to fix the GDM xsession script to work better.  You aren't very clear about which specific "other scripts" need attention.
Comment 2 Richard Neill 2010-04-18 03:19:27 UTC
Ouch! I was just about to report a bug saying the exact opposite. 
At any rate, it should do something more verbose than just loop.

For example:
 1. gdm reads /etc/profile
 2. /etc/profile sources /etc/profile.d/*.sh
 3. One of these might be a a bash-script, with bashisms such as
     "[[".  
    This is perfectly legal in /etc/profile, however, if the
    parser is sh (or dash), it will fail
4. That in turn will cause gdm to fail.
5. The user then gets stuck in a loop, logging in, and seeing what appears
   to be X failing to start.

6. The errors are not anywhere you'd expect to find them (/var/log/Xorg.0.log
 or in /var/log/gdm/*. Instead, they are hiding in ~/.xsession-errors, 
  looking unimportant.
Comment 3 Brian Cameron 2010-04-19 19:08:49 UTC
Richard, this is how GDM has always worked.  GDM was rewritten when GDM 2.22 was released.  GDM 2.20 and ealier provided an "Xterm" session for users to fix such problems.  

Some distros create an xterm.desktop which includes this line to specify the GDM desktop-file extension which causes the Xsession script to not be run:

X-GDM-BypassXsession=true

Setting this extension to true ensures that the Xsession script is not used, and instead xterm is just launched directly.  This way any problems with the user's .profile do not cause GDM to fail to start the xterm session.  Then the user can correct any problems in their $HOME/.profile.

So, I recommend that distros or users that want to support this behavior in GDM provide a similar xterm.desktop file.
Comment 4 Brian Cameron 2010-04-19 19:09:30 UTC
Created attachment 159101 [details]
xterm.desktop file

Here is an xterm.desktop file that you can install to /usr/share/xsessions if you want to have this feature.
Comment 5 Ray Strode [halfline] 2013-12-16 18:30:02 UTC
I think longer term, i'd like to ditch Xsession entirely.  having random shell scripts be an integral part of the login process is a source of fragility and efficiency problems.

Until then, though, I think i'd like to keep things the way they are, since they've been that way for so long.

Feel free to reopen, if you have strong opposing opinions and we can reconsider.
Comment 6 Richard Neill 2013-12-16 18:38:44 UTC
IMHO, it doesn't matter what the policy is, so long as the error messages are loud and explicit.  Please say something verbose in all the relevant log files (including Xorg.0.log and syslog and gdm's logfile.)