gdm can't login to any session when /bin/sh is symlinked to bash

[kenjo]

Binary package hint: gdm

Description: Ubuntu 10.04 LTS
Release: 10.04

After the last system update I no longer can login to the system using the gdm login screen.
gnome-session failsafe kde or even xterm all have the same effect that after I press the login button I simply en up back at the login prompt.

I can login using the console.
If I start xinit then gnome-session it looks to be working have not used it that much so I'm not sure if there is any ill effects of doing it this way.

I have not found any information in any logs I know about and have failed to find any way to make more information available.

I did modify the gdm.conf to strace everything but I'm not sure how it's supposed to work so it do not help me to find out where the problem is.

[kenjo (ken-kenjo)]

That line wrap made the execve log completely unreadable. here is a file instead.

[kenjo (ken-kenjo)]

I now know what is happening. I had a large build system that failed if /bin/sh pointed to dash so I set it to point to /bin/bash instead. That is what makes the login fail. starting xinit then "/etc/gdm/Xsession gnome-session" produces the following error

/etc/gdm/Xsession: Beginning session setup...
/etc/bash_completion.d/apport_completion: line 128: `_apport-bug': not a valid identifier

setting back the /bin/sh link to dash makes it work and I can also login from the normal gdm login screen.

So this bug should be moved to apport or maybe bash ?? but I do not know how to do that

[Sebastien Bacher (seb128)]

reassigning to apport according to the previous comment

[Philip Muškovac (yofel)]

Can you give us a bit more details about your setup?
I tried to reproduce this by creating a fresh Ubuntu VM, linked sh to bash, made sure that bash_completion is enabled in .bashrc, run xinit, then /etc/gdm/Xsession gnome-session and got a fully functional gnome login, and I can login from gdm just fine.

[Philip Muškovac (yofel)]

Here's the terminal log from my attempt.

[kenjo (ken-kenjo)]

I was about to take another stab at this problem but now it works.

So something has changed on the system and I have no idea of what. But since its no longer present I'm goin to close this issue.

[kenjo (ken-kenjo)]

ARRGGHH!!

No it did not work it was the link change that did not work so /bin/sh pointed still to dash. When I now change it I have the same problem but now I have no time to look in to it for the moment.

[Philip Muškovac (yofel)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. However, if the issue still exists please feel free to reopen with the requested information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Christian Holtje (docwhat)]

Hello!

I'll happily answer any questions about this.

I can reproduce the problem on my box.

Just to re-iterate how to reproduce:
 * sudo ln -sf bash /bin/sh
 * Make sure you have bash script or two in "Startup Applications"
 * Have your .bash_profile stupidly source /etc/bash_completion (in my case by sourcing ~/.bashrc).
 * Log out.
 * Try to log back in.

It just kicks you right out and the following lines appear in the ~/.xsession-errors file:
/etc/gdm/Xsession: Beginning session setup...
/etc/bash_completion.d/apport_completion: line 128: `_apport-bug': not a valid identifier

This is a some-what pathological setup, because of the .bash_profile sourcing .bashrc, but a lot of people thrash around wrt to which file does what in bash.

A fix for this is to wrap all of bash_completion in an if [[ ! shopt -oq posix ]]; then .. fi block.

[Christian Holtje (docwhat)]

Actually, it looks like you can just add this to the top of bash_completion:

# Only run if shell is interactive.
if [[ $- != *i* ]] ; then
    return
fi

Ciao!

[Rolf Leggewie (r0lf)]

Christian, thank you. I can confirm that your comment 10 fixed the same problem as I reported it already in bug 408804.

Somebody please test if this affects release later than lucid. bug 588811 looks similar and was reported against Maverick, but might have been a Maverick-only problem.

[Elliot Glaysher (glaysher)]

I can confirm that this is still an issue in Precise.