After gdm upgrade no X cliens can be run

[LGB [Gábor Lénárt]]

This is daily upgraded hardy (32 bit).

It seems for me at least that after a gdm upgrade (but probably it's gdm related but something else?) no X programs can be run anymore. For example if I try to run xterm from an already existing terminal window I got:

No protocol specified
xterm Xt error: Can't open display: :0.0

If I try to 'strace' xterm, I see this:

socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0
getpeername(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, [20]) = 0
uname({sys="Linux", node="vega", ...}) = 0
access("/tmp/.gdmVNZW6T", R_OK) = -1 EACCES (Permission denied)

So, I've checked /tmp/.gdmVNZW6T:

-rw------- 1 root root 115 2008-02-28 10:32 /tmp/.gdmVNZW6T

It seems something alters the ownership of this file to root, so it's not surprising I can't open it with this permission as non-root. After chown'ing back to my user, everything works.

lgb@vega:~$ sudo chown lgb:lgb /tmp/.gdmVNZW6T
lgb@vega:~$ ls -la /tmp/.gdmVNZW6T
-rw------- 1 lgb lgb 115 2008-02-28 10:32 /tmp/.gdmVNZW6T

Now, I can run X programs without problem. This issue occurs quite frequently, as far as I remember after upgrades.

gdm version is 2.20.3-0ubuntu5. Please note, that I'm not sure it's caused by gdm or other package though ...

[Sebastien Bacher (seb128)]

Thank you for your bug report. Could you attach your gdm configuration and log to the bug? There should be no file under tmp used, are you sure you are running the ubuntu version?

[LGB [Gábor Lénárt] (lgb)]

As I've mentioned I'm not sure that it's caused by gdm or gdm upgrade but this problem occurs on larger upgrades and at least it seemed for me that gdm can be the reason. However I'm only sure in the symptom: no X clients can be run at one point (as far as I remember after upgrades), trying to strace them indicated that a file in /tmp/ directory can't be opened because of the root ownership, after chown'ing back to my user it works, so I assume that it was owened by me before (since X clients worked before) however something alterted the ownership of that file to root and this is the problem. I'm not sure that gdm upgrade caused this, though, only guessing.

/etc/gdm/gdm.conf is attached. However I'm not sure what king of log should I post here.

[Sebastien Bacher (seb128)]

Could you attach your gdm.conf-custom, .xsession-errors, Xorg.0.log, dmesg, messages and syslog? Is your user directory writable?

[LGB [Gábor Lénárt] (lgb)]

Some files packed into a tgz file is attached. My home directory:

lgb@vega:~$ ls -ld ~
drwxr-xr-x 239 lgb lgb 20480 2008-03-03 09:06 /home/lgb
lgb@vega:~$ whoami
lgb

(note: pidgin segfault can be seen in file 'dmesg' is already reported as #197146 by me, so ignore it here)

Now I've discovered that this bug is easier to reproduce if:

1. lock the screen
2. login from remote via ssh
3. install packages/upgrades (gdm as well?) via apt-get from remote
4. come back to the console
5. try to unlock

It does not work, no password input dialog or shown, only mouse cursor blinks. If I switch to text console and kill gnome-screensaver, then switch back to my X/gnome session, the reported bug occures, no X clients can be run. However I don't remember that ALL similar bugs were got only in this mode ...

[Sebastien Bacher (seb128)]

could you run env and mount and copy the log to a comment? are you sure you have no disk issue? gdm should not be using tmp to store things and other software should not have to stat this one

[LGB [Gábor Lénárt] (lgb)]

Ok, but if it's true that gdm should not using tmp, what's this in the output of strace (it's an example, now I run xterm)?

lgb@vega:~$ strace -o /tmp/L xterm
[...]
access("/tmp/.gdmFV696T", R_OK) = 0
open("/tmp/.gdmFV696T", O_RDONLY) = 4

Since the file has "gdm" in its name (this is the file whose ownership goes to root:root after upgrade it seems), I thought it's a file of gdm. Maybe I'm wrong, as I've written before this is only a guess from me that it's a gdm bug, it can be other, of course. So I could recompose this bugreport as "cannot run X clients after major upgrades from remote ssh session", but I don't know upgrade of which package cause this exactly (well, sorry if my comment seems to be intrusive, but because my English is far from perfect I always worry about others not able to understand me correctly ...). By the way, it seems that env.var. XAUTHORITY has got value of /tmp/.gdmFV696T, exactly this file.

No disk issue, I'm sure.

lgb@vega:~$ mount
/dev/sda2 on / type ext3 (rw,noatime,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.24-11-generic/volatile type tmpfs (rw)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/lgb/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=lgb)

lgb@vega:~$ env
GPG_AGENT_INFO=/tmp/seahorse-5VpTUR/S.gpg-agent:6245:1
SHELL=/bin/bash
TERM=xterm
XDG_SESSION_COOKIE=92ad7e3941d35ab5cf1cb600464d0b30-1204531474.834884-1282338699
CPPFLAGS=-mtune=pentium4 -march=pentium4
GTK_RC_FILES=/etc/gtk/gtkrc:/home/lgb/.gtkrc-1.2-gnome2
WINDOWID=59149577
USER=lgb
LD_LIBRARY_PATH=/home/lgb/.local/lib
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:
SSH_AUTH_SOCK=/tmp/keyring-5FJjf6/ssh
GNOME_KEYRING_SOCKET=/tmp/keyring-5FJjf6/socket
SESSION_MANAG...

[Sebastien Bacher (seb128)]

something makes gdm switch the xauthority there, not sure what, to debug by somebody having the issue

[Sebastien Bacher (seb128)]

switching to new, that doesn't seem to be a bug, something is changing the xauthority location usually that is the case when the user directory is not writable

[LGB [Gábor Lénárt] (lgb)]

I have this issue again and again ... Yesterday I started dist-upgrade and lock the screen to have some coffee. When I returned I had the same issue I couldn't get the unlock password dialog, switching to text terminal I was able to correct the ownership of that /tmp/.gdm* file. After this move I was able to get the unlock dialog and everything works. Please note that there is 'full filesystem' or 'unwritable home' issue here, I checked these, since you had the message that this could cause my problem.

[LGB [Gábor Lénárt] (lgb)]

And happened again! My home directory IS writable, no disk full issue. However I found this:

lgb@vega:~$ sudo stat .Xauthority
  File: `.Xauthority'
  Size: 214 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 6996468 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2008-03-02 22:13:58.000000000 +0100
Modify: 2008-03-02 22:13:58.000000000 +0100
Change: 2008-03-02 22:13:58.000000000 +0100

So, ownership of .Xauthority file in my home directory went to root, I've no idea why. Can it be the reason of switching to /tmp/.gdm* files? Now, I deleted /tmp/.gdm* files, and reown to .Xauthority to myself. However this time, I get this:

Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: :0.0

[LGB [Gábor Lénárt] (lgb)]

And happened again. This time no screen lock just a simple apt-get update / upgrade. Then no X clients could be run. Again. .Xauthority was owned by the root user! After chowin'ing back to my user everything continued to work, it seems.

[Joachim Haga (jobh)]

I have seen the same problem (I do not know if it is related to GDM, but this is with hardy).

At the moment it's particularly bad; .Xauthority reverts to root:root within a second of changing it by hand to user:user.

It seems to be atieventsd which is the trigger of this (but possibly not the cause; I tried strace on it but it didn't seem to call chown itself). When I stop it, .Xauthority stays as user:user.

[Joachim Haga (jobh)]

I forgot to say: This also happened immediately after "aptitude dist-upgrade". A number of packages were updated, including gdm.

[LGB [Gábor Lénárt] (lgb)]

So I've altered the status to confirmed since this problem affects other users too, it seems. For me, dist-upgrade often triggers this bug.

[Joachim Haga (jobh)]

Again today, after dist-upgrade. But this time gdm was not upgraded, although xorg-driver-fglrx (which has atieventsd) was.

I tried to look deeper into this, and it seems that in this case it is caused by atieventsd calling "xauth add/remove -f /home/xxx/.Xauthority" as root, which triggers the ownership change. Do you have this installed (xorg-driver-fglrx)?

In any case, to debug I made a simple shell wrapper for xauth which logs when it is called and who calls it. Let me know if you need this.

[LGB [Gábor Lénárt] (lgb)]

The same for me :) No gdm upgrade but something else, but don't know which package exactly but yes, xorg-driver-fglrx is installed:

lgb@vega:~$ dpkg-query -W xorg-driver-fglrx
xorg-driver-fglrx 1:7.1.0-8-3+2.6.24.12-16.34

So maybe it's not about gdm but package xorg-driver-fglrx ?

[Sebastien Bacher (seb128)]

reassigning to xorg-driver-fglrx

[LGB [Gábor Lénárt] (lgb)]

I usually upgrades distribution and install packages by hand, with 'sudo bash' in a terminal to get a root shell than do the work with 'apt-get'. I guess this can be a problem for some config script in packages running as user root but eg got /home/myuser/ as home directory, or something similar?

[Joachim Haga (jobh)]

No, this sounds like the normal and expected mode of operation (the gui update tools also run under sudo, AFAIK).

I have now found an easy way to reproduce:
/etc/init.d/atieventsd restart

You have to log out to get back to normal operation (or do "/etc/init.d/atieventsd stop; chown $USER:$USER .Xauthority").

After the restart, these operations are triggered about once per second through atieventsd->/etc/ati/authatieventsd.sh->xauth:
Mon Apr 14 10:50:40 CEST 2008 root: xauth -f /var/lib/gdm/:0.Xauth list
Mon Apr 14 10:50:40 CEST 2008 root: xauth -f /home/jobh/.Xauthority add :0 . 3033a32a297b496c426e092bdc7ce746
Mon Apr 14 10:50:40 CEST 2008 root: xauth -f /home/jobh/.Xauthority remove :0

which leaves ~/.Xauthority owned by root.

Before the restart, i.e. when things were working correctly, this was instead the sequence of operations (also once per second, which seems very wasteful since it's the same key that's added/removed every time). Writing was to a temporary file:

Mon Apr 14 10:47:23 CEST 2008 : -f /var/lib/gdm/:0.Xauth list
Mon Apr 14 10:47:23 CEST 2008 : -f /tmp/atievntX.EERLDe add :0 . 3033a32a297b496c426e092bdc7ce746
Mon Apr 14 10:47:23 CEST 2008 : -f /tmp/atievntX.EERLDe remove :0

(note $USER was not set but probably root also here since that's the owner of /tmp/atieventX.EERLDe).

[hackel (hackel)]

Confirmed with xorg-driver-fglrx 1:7.1.0-8-3+2.6.24.12-17.35

I'm so glad I finally found a temporary solution to this other than restarting X, it's been killing my productivity!

It seems that even just *stopping* atieventsd causes this problem. When atieventsd closes, it runs:

/etc/ati/authatieventsd.sh grant :0 /tmp/.gdmLADPAU

And this changes the ownership to root by running (as root, on line 88):

xauth -f /tmp/.gdmLADPAU add :0 . f3a6e5e2c13b85247eb2cc35bc6a36d5

Obviously, the auth file, display name and cookie will be unique for each user.

This does add the correct key for the user to access the X server, but since the file is only readable by root, clients cannot connect. Is the intended behaviour of xauth to change file ownership? If not, then this bug should be transferred to the xauth package.

Another significant question is whether atieventsd needs to be messing with the Xauth file in the first place?

[LGB [Gábor Lénárt] (lgb)]

Still have this bug, quite annoying on upgrades have something about atieventsd ... This is 32 bit hardy, Version of xorg-driver-fglrx is 1:7.1.0-8-3+2.6.24.13-19.42

[Joachim Haga (jobh)]

Another work-around seems to be to unset the environment variable XAUTHORITY when upgrading or restarting atieventsd.

As in "XAUTHORITY= aptitude dist-upgrade".

[Bryce Harrington (bryce)]

Thank you for reporting this issue about a driver from the
linux-restricted-modules package. lrm-2.4.24 was shipped with Ubuntu
8.04 which reached end-of-life for desktop support on May 12th, 2011.

For that reason, this bug report is being closed at this time. I'm
marking it wontfix because what you describe is probably a valid issue,
but there are no plans to work on lrm 2.4.24 bugs further.

The issue may be resolved in a newer version. If not, aside from filing
a new bug report, another angle may be to file it directly with the
driver vendor.