[lug] serious Xauthority/gnome problem

D. Stimits stimits at idcomm.com
Thu Jun 28 15:39:37 MDT 2001


Hugh Brown wrote:
> 
> I usually just move .Xauthority out of the way and let it get regenerated.
> 
> (If I'm wrong, you still have the file).
> 
> Try going in from a startx from run level 3, once that is working add gdm
> to the mix by going back to run level 5.

This did the trick. What surprises me is that prior to this I did try
removing the .Xauthority, but my trek back and forth to X was via init 3
and init 5, I did not use startx. I also tried reboot. Apparently
something with startx was better able to deal with it than going
directly between runlevels via init.

D. Stimits, stimits at idcomm.com

> 
> Hugh
> 
> "D. Stimits"
> >
> > I was booting up, it went normally (RH 7.1), and it was sitting at the
> > standard login prompt for runlevel 5 default, gnome. When I logged in
> > with regular user, it crashed (hard lockup, no ping, magic sysrq dead).
> > When it came back up, my regular user was rejected from login due to
> > .Xauthority it looks like. root could still login normally. And if I
> > used KDE instead of gnome, my regular user could still login (and in
> > fact, that is how I am managing to get to my email program Netscape). I
> > went through and tried to regenerate my .Xauthority, but I am doing
> > something seriously wrong, and I'm getting tired of KDE (my OpenGL
> > programs crash and die there, probably due to sound daemon interaction
> > rather than OpenGL itself). Here is a sample of some log messages after
> > I tried to regenerate .Xauthority (and this was after an older backup
> > version of .Xauthority failed):
> >
> > gdm[5237]: gdm_auth_secure_display: Setting up access for :0
> > gdm[5237]: gdm_auth_secure_display: Setting up socket access
> > gdm[5237]: gdm_auth_secure_display: Setting up network access
> > gdm[5237]: gdm_auth_secure_display: Setting up access for :0 - 2 entries
> > gdm[5645]: gdm_server_start: '/usr/bin/X11/X -auth /var/gdm/:0.Xauth :0'
> > gdm[5237]: gdm_server_usr1_handler: Starting display :0!
> > gdm[5237]: gdm_display_manage: Managing :0
> > gdm[5237]: gdm_display_manage: Forked slave: 5646
> > gdm[5646]: gdm_slave_start: Starting slave process for :0
> > gdm[5646]: gdm_slave_start: Opening display :0
> > kernel: NVRM: AGPGART: Intel i840 chipset
> > kernel: NVRM: AGPGART: aperture: 128M @ 0xf0000000
> > kernel: NVRM: AGPGART: aperture mapped from 0xf0000000 to 0xd5b1c000
> > kernel: NVRM: AGPGART: mode 4x
> > kernel: NVRM: AGPGART: allocated 16 pages
> > gdm[5646]: gdm_slave_greeter: Running greeter on :0
> > gdm[5646]: gdm_slave_greeter: Greeter on pid 5654
> > gdm(pam_unix)[5646]: session opened for user stimits by (uid=0)
> > gdm[5646]: gdm_slave_greeter: Authentication completed. Whacking greeter
> > gdm[5646]: gdm_slave_windows_kill: Killing windows on :0
> > gdm[5646]: gdm_slave_session_start: stimits on :0
> > gdm[5646]: gdm_auth_user_add: Adding cookie for 500
> > gdm[5646]: gdm_auth_user_add: Using /home/home1/stimits/.Xauthority for
> > cookies
> > gdm[5646]: gdm_auth_purge: :0
> > gdm[5646]: gdm_auth_user_add: Done
> >
> > It appears that since it died right in the middle of the login process
> > originally, something it writes during the process has been corrupted.
> > Can anyone give me an idea of how to regenerate the .Xauthority for a
> > regular user? Prior to this I had been getting this all the time, but it
> > had no effect:
> > gdm[3267]: gdm_auth_user_remove: /home/home1/stimits is not owned by uid
> > 0.
> > gdm[3267]: gdm_auth_user_remove: Ignoring suspiciously looking cookie
> > file /home/home1/stimits/.Xauthority
> >
> > Now the odd thing on that is that when I did experiment with the home
> > directory .Xauthority permissions, when I set things as owned by root
> > (uid 0), it then complained that it was not owned by my regular user
> > instead...it couldn't make up its mind.
> >
> > Right now I don't know what is wrong, but I suspect that whatever it is
> > will be on top of a bad .Xauthority. Is this file regenerated each
> > login? Or is it a static file? Since the man page only led me to
> > generate .Xauthority files that gave even more errors with weird
> > statements like "whacking greeter", I need to verify that I am doing it
> > correctly. Can someone tell me a means of correct generation (and file
> > perms) for an individual user's .Xauthority file for gnome sessions?
> > Then I can decide whether some other part of the whole process is dead.
> >
> > D. Stimits, stimits at idcomm.com
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> 
> ------------------------------------
> System Administrator/Unix Consultant
> hugh at vecna.com
> Vecna Technologies, Inc
> 6525 Belcrest Rd, Suite 612
> Hyattsville MD, 20782
> 301.864.7253
> http://www.vecna.com
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug



More information about the LUG mailing list