fixfiles logfile -- silly looking sequence...

[Tom Mitchell]

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.