Gerard Beekmans gerard at linuxfromscratch.org
Wed Oct 30 09:29:10 PST 2002

Okay I think all has been said in this thread that can be said (yes I've been 
waiting for it to die down before posting my own comments).

The heart of the problem is that X creates a lock file in /tmp. The only 
reason Ian suggested to clean /tmp is that X will work properly after a 
reboot (and yes I realize how annoying it is when XDM and other *DM's don't 
work at boot time) but to change the bootscripts to accomodate a problem with 
X itself is clearly not the proper solution. The proper solution is to unpack 
X, edit the xc/programs/Xserver/os/utils.c file and change the LOCK_DIR 
variable from /tmp to /var/lock and recompile. Voia, problem solved. X will 
behave as it is supposed to be (according to the FHS recommendation).

I'm not going to debate of the issue whether or not /tmp should be cleared on 
reboots, as we've seen you can discuss it endlessly. That's something for you 
yourself to decide what you consider good practise. I personally like /tmp to 
exist after a powerloss so I don't loose those temp files created by 
programs. For example: mutt writes temp files in /tmp containing the email 
you're sending. I've glad on more than one occasion /tmp isn't cleared on 
boot. It would be hard to recover an email I've been working on when the temp 
file is gone.

And let's not start with "if you know you have something you have to safe, 
then boot with init=/bin/bash". That's just too troublesome.

Anyways, if _you_ want /tmp to be cleared on boot, then go ahead edit the 
cleanfs script and you'll be happy. Other people will be happy that it's not 
done. Whether it's right or wrong: that's highly subjective. And the FHS is 
just a recommendation in my eyes. Not the Linux system admin good practice 

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list