/tmp/.ICE-unix

Bruce Dubbs bdubbs at swbell.net
Tue Apr 29 19:02:11 PDT 2003


Gerard Beekmans wrote:

>Hey guys,
>
>If you haven't seen the thread on lfs-chat yet maybe do so. Ian Molton started 
>it as "Pay attention to warnings..." and starts here:
>
>http://archive.linuxfromscratch.org/mail-archives/lfs-chat/2003/04/2055.html
>
>I don't know if this is already part of the BLFS book's X section, can't check 
>right this second, but here's the gist of it:
>
>when running "startx" as a normal user, /tmp/.ICE-unix directory gets created 
>and owned by the user who started it. However, if you start X and pipe the 
>output to a log file (to capture it all before scrolling off the screen) 
>you'll see there's a warning that /tmp/.ICE-unix should be owned by root and 
>not the user. The result of this improper permission is that X is slower in 
>starting apps than it should be.
>
Wouldn't running XFree86 as root once (or after cleaning out /tmp) 
automatically take care of this.  I didn't
do anything special other than that and my system has /tmp/.ICE-unix as 
root.root with 1777 permissions.

Perhaps a note explaining the problem and the fix would be appropriate. 

>gnome-session takes a few seconds (about 5) to even start its splash screen. 
>KDE's "Initializing Peripherals" component during startup takes about 6 more 
>seconds than it should take.
>
>So a chown root.root of that dir will cut window manager startup time by a few 
>seconds. But it doesn't end there either. OpenOffice starts quicker now, all 
>already slow KDE apps start much quicker now. The improper permissions don't 
>show up as warning boxes but they apparently do slow down due to some kind of 
>timeout inside X itself.
>
>If you clean out /tmp on boot, people better create a bootscript to create 
>that dir as 'root.root' with permission 1777 before X is started (either by 
>xdm/kdm/gdm or something, or by manually startx).
>

  -- Bruce

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list