> > On Mon, Aug 28, 2000 at 02:31:29PM -0400, Chris Ryan wrote:
> > > It's not normally a good idea to move/remove files that a process has an
> > > open file handle for. The safest way is to copy the file to a new
> > > location/name then cat /dev/null > logfile
> >
> > What's wrong with moving the file when it's in use?
> >
> > Copying the file will take much longer, and you might loose log-entries
> > that are written after cp but before truncate.
* Dana Hudes <dhudes@hudes.org> [000828 13:07] wrote:
> *falls over in astonishment, gagging*
> *switch to CS professor mode*
>
> Filesystem corruption result highly likely.
> Reason: while you are touching the file, so is the process.
> It has a file handle open. Actually should be locked and it would
> be best if mv would honor that.
> Under other operating systems such as VMS, the file would be locked
> only SYSADMIN could mess with it.
> Think -- Linux is a Unix variant, a true multitasking
> multiprocessing operating (with thread (lightweight process) support, no
> less) system. While you are typing your mv command the process is running
> unless you suspend it somehow. Therefore it is busy writing to disk
> while you mess with its file. Even if you catch between writes, there is
> the write cache / ouptut buffers (which is why a close is often preceded
> by a fflush).
This is half wrong, if the rename operation happens on the same
filesystem then there is no chance of corruption. The OS will take
care of this. However if it's a mv to another filesystem then what
you're saying is a possibility.
I'm not sure if you miss-parsed Chris Ryan's question which I take
as a rename within the same filesystem, but I would not be so eager
to jump down his throat if you're not completely familiar with the
OS internals or not sure of the question.
(ponders how trivial it might be to write a program that swaps)
. o O (out open files out from under a running program)
This is a good way of fixing the problem:
cp logfile someplaceelse
killall -STOP postresql
# append any extra data written to the log
truncate -s 0 logfile # FreeBSD provides this as a userland tool
# you may have to write your own to call the OS's
# truncate/ftruncate routine
# or simply : cat /dev/null > logfile (my work)
killall -CONT postresql
you shouldn't loose any data that way.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."