Since upgrading to X.org 6.8.0, I've been getting problems logging into KDE. I'm using KDE's display manager, and have my system set up with a standard user account (stuartl) for day to day tasks. When logging in initially, KDE begins to fire up but then bombs out. Running it via the 'failsafe' shell, it gives various warnings about /tmp/.ICE-unix not being owned by 'root'. The startup script then bombs out. Upon inspecting the /tmp directory, .ICE-unix is indeed owned by stuartl:users. If I change the ownership of /tmp/.ICE-unix to root, I'm able to log in without any troubles. Reproducible: Always Steps to Reproduce: 1. Select 'failsafe' as the session type 2. Log in as a standard user via 'kdm' 3. At the prompt, type /usr/kde/3.3/bin/startkde (or just 'startkde' if in $PATH) -- KDE begins to fire up, then dies -- 4. Exec: sudo chown root:root /tmp/.ICE-unix (or su -c if you don't have sudo) 5. Retry running 'startkde' ... It should start successfully. Actual Results: Session initialisation creates .ICE-unix with ownership $USER:$GROUP. Expected Results: Session initialisation should create .ICE-unix with ownership root:root.
This was covered in the X.org release notes: http://wiki.x.org/X11R6.8.0/doc/RELNOTES5.html#39 If you think the default startup script for kde should handle this situation differently, a wish should be filed at http://bugs.kde.org ... but this was already done: http://bugs.kde.org/show_bug.cgi?id=90978 you can vote/comment on that bug.
Ahh right, thanks for that. Is there a particular init script this should be placed in? I'll certainly have a poke through the various scripts, I've tried sticking the commands in /etc/init.d/xfs to no avail, my next idea is to perhaps try one of the ones in /usr/kde/3.3/share/config/kdm/*. (Xstartup looks a likely candidate) The issue, although it's starting to bug me, isn't a biggie by any stretch of the imagination though, just an annoyance. I'll keep an eye on that bug listing and see what happens for now. :-)
Well, I've found that the code is already there, in /etc/init.d/bootmisc rm -f /tmp/.X*-lock /tmp/esrv* /tmp/kio* /tmp/jpsock.* /tmp/.fam* &>/dev/null rm -rf /tmp/.esd* /tmp/orbit-* /tmp/ssh-* /tmp/ksocket-* /tmp/.*-unix &>/dev/null # Make sure our X11 stuff have the correct permissions mkdir -p /tmp/.{ICE,X11}-unix &>/dev/null # chown root.root /tmp/.{ICE,X11}-unix &>/dev/null chmod 1777 /tmp/.{ICE,X11}-unix &>/dev/null (Notice that the chown command is commented, but that's not relevant, see bug 28861) In fact you're the only one reporting this issue, it seems that code worked well for everyone else...
I am seeing this as well, since I have tmpwatch cleaning my /tmp of any files not accessed the last two weeks (looking at atimes, yes i have atimes turned on for that partition) Should I tell tmpwatch to exclude the /tmp/.ICE-unix directory from the cleaning, or what is the best solution? After all /tmp is just a directory for temporary files and applications shouldn't expect files to linger around forever...
(In reply to comment #4) > Should I tell tmpwatch to exclude the /tmp/.ICE-unix directory from the > cleaning, or what is the best solution? Yes, you should let the init script manage /tmp/.ICE-unix and set the correct permissions (btw see also bug 56592).
