After logout Xorg stays stuck in tty_ld

[Gema Gomez]

Precise is not able to restart Xorg after a logout in any of my machines. After I log out, the Xorg process stays stuck in tty_ld. ps shows:

4 0 1258 1187 20 0 0 0 tty_ld Ds+ tty7 0:07 [Xorg]
0 1000 2977 2959 20 0 9396 916 pipe_w S+ tty1 0:00 grep Xorg

Since tty7 remains busy, no new desktop manager and Xorg start up automatically.

Dmesg last line seems to be relevant:
[ 193.702121] tty_ldisc_hangup: waiting (Xorg) for tty7 took too long, but we keep waiting...

It seems that a password prompt for some smb/cifs mounts that are not marked as noauto are causing the issue.

//nasi/data /home/gema/data cifs user,user=gema 0 0

Adding noauto works around the problem,

//nasi/data /home/gema/data cifs noauto,user,user=gema 0 0

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1011986/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[James Hunt (jamesodhunt)]

Can you confirm if mountall and/or mount.cifs are running when the system is in this state?

It does appear that mount.cifs is still attempting to read the CIFS passwords directly from /dev/tty7.

[Gema Gomez (gema)]

Yes, mountall and mount.cifs are running when the system is there:

1 0 314 1 20 0 30552 1484 poll_s S ? 0:00 mountall --daemon
0 0 1174 314 20 0 21936 908 wait S ? 0:00 mount -t cifs -o user,user=gema //nasi/data /home/gema/data
4 0 1177 1174 20 0 8564 404 wait S ? 0:00 /sbin/mount.cifs //nasi/data /home/gema/data -o rw,noexec,nosuid,nodev,user,user=gema
5 0 1179 1177 20 0 10668 740 n_tty_ S ? 0:00 /sbin/mount.cifs //nasi/data /home/gema/data -o rw,noexec,nosuid,nodev,user,user=gema
0 1000 2881 2863 20 0 13388 924 pipe_w S+ tty1 0:00 grep mount

[James Hunt (jamesodhunt)]

Hi Gema,

The problem then is that mountall is left prompting but meantime X has started on the same tty. I don't see how mountall could be changed to deal with this scenario automatically though since the only way to signify that a particular CIFS mount requires a password is via the options specified for that mount point in /etc/fstab. That said, the resultant problem you're observing is clearly something we want to avoid!

We could potentially add a new Upstart job that specifies "start on filesystem", waits for a few seconds (ugh) and then forcibly stops mountall if it is still running along with displaying a message that fstab mount options may be bad. This is ugly, but would atleast give users an indication that recent /etc/fstab changes may cause problems.

So ultimately, this is a configuration error I think. There are a number of ways to work around the problem:

- add "noauto" to mount options in /etc/fstab (as Gema states).
- add "guest" to mount options in /etc/fstab.
- add "bootwait" to mount options in /etc/fstab to make mountall wait until the user has entered the password.
- use the automounter instead ("sudo apt-get install autofs" and add mount details to appropriate /etc/auto.* file)
- use a user mount (gvfs-mount) if the data on the remote FS isn't required until user login.

What would be good is if we could contrive a mntctl option that could be run that would atleast warn if it detected an fstab entry that could block for user input.

[Steve Langasek (vorlon)]

James, it seems to me in this particular case that we could also address this by making the mountall job be 'console log' by default instead of 'console output'. Do you see any reason not to do that?

> What would be good is if we could contrive a mntctl option that could be run that
> would atleast warn if it detected an > fstab entry that could block for user input.

Hmm, my personal impression is that this is poking through too many layers... mounts aren't meant to be interactive at boot time in the first place, I'd rather we just disallow prompting from mountall (and child processes).

[Steve Langasek (vorlon)]

FWIW, I've just changed mountall to use the default 'console log' instead of 'console output' in the upload of 2.50 to Debian unstable (which should be syncable to saucy soon), but didn't catch this bug in the changelog - so closing it manually.