fixfiles logfile -- silly looking sequence...
Tom Mitchell
mitch48 at sbcglobal.net
Fri May 7 00:16:18 UTC 2004
I just noticed something harmless but silly
with fixfiles.
# fixfiles relabel
logging to /tmp/fixfiles.KVDZyC3888
Cleaning out /tmp
So what about /tmp/fixfiles.KVDZyC3888?
Was it really removed and does it matter?
...
So control Z....
[1]+ Stopped fixfiles relabel
[root at xtl2 root]# ls -l /tmp/fixfiles.KVDZyC3888
-rw-r--r-- 1 root root 0 May 6 16:33 /tmp/fixfiles.KVDZyC3888
It is there but now I wonder if I lost any bits of /tmp/fixfiles.KVDZyC3888
or perhaps I am not cleaning out /tmp.
I did do an strace and the tmp file seems to be opened twice.
I clearly see one unlink() system call of it followed by
a second open so it is removed so I could have lost bits.
First...
open("/tmp/fixfiles.XXX", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
Second...
open("/tmp/fixfiles.XXX", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666 <
Note the difference 0600, 0666. Should the script be setting
umask?
Possible solutions.
Move
mktemp /tmp/fixfiles.XXXXXXXXXX
echo "logging to $LOGFILE"
down in the script to follow the rm -rf /tmp/.??* /tmp/*
It turns out that
mktemp /tmp/fixfiles.XXXXXXXXXX
does create the file but the first output
is sent to the file after the
rm -rf /tmp/.??* /tmp/
line which causes it to be recreated.
Summary harmless I think.
--
T o m M i t c h e l l
/dev/null the ultimate in secure storage.
More information about the fedora-test-list
mailing list