Mark Knecht wrote:
Hi Paul,
Yes, ls -al shown nothing is there.
Actually, I think the root cause of this is a little different than
I expected. /tmp/jack is actually something that's mounted:
lightning ~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
<SNIP>
none 508016 0 508016 0% /tmp/jack
and the root cause of that is that it's in my fstab file:
lightning ~ # cat /etc/fstab | grep jack
none /tmp/jack tmpfs defaults 0 0
lightning ~ #
So, there are three directions to go:
1) Remove it from fstab and figure out what the repercussions of that
action might be.
Well, it's a tmpfs, so it gets wiped on shutdown anyway. Anything that
needs the /tmp/jack directory will write to there whether a tmpfs is
mounted or not, so removing the fstab line wont have any consequences by
itself. If /tmp/jack gets removed by a boot script, and is actually
needed, the directory will most likely be recreated by whatever program
needs it. If not, you can always "mkdir /tmp/jack" long enough to fix
the program in question.
2) Understand why the Gentoo boot process want to wipe mounted
directories in /tmp since it won't work.
I suspect the gentoo script is something simple like "if WIPE_TMP=YES,
then rm /tmp/*".
FHS recommends nothing in /tmp survive boot.
http://www.pathname.com/fhs/2.2/fhs-3.15.html
It's bad practice to have a persistent mount point inside of /tmp or
/var/tmp.
If your /tmp is a tmpfs of some kind, then the above fstab entry is
redundant anyway.
The main (possible) problem is some program requires a directory/file to
exist in /tmp, but doesn't create that directory/file itself. Thats
just a plain stupid (programming) practice, so I doubt you'll run into
any issues with removing the fstab entry, and so on.
3) Go back to ignoring it.
I'm going to investigate #1 first as this is something that I think
is left over from years ago, but maybe you or someone else has another
idea.
Thanks,
Mark
PaulNM
--
gentoo-user@lists.gentoo.org mailing list
