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
-*- 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