From: Justin C on

My .proclog is getting quite large and I'd like to remove it and start
again. I remember reading somewhere that if a file which is being
written to is removed it's blocks are not marked as free. What is the
best way to remove this without risking removing a file which may be
open?

Justin.

--
Justin C, by the sea.
From: Will Kemp on
On Tue, 06 May 2008 11:11:06 +0000, Justin C wrote:

> My .proclog is getting quite large and I'd like to remove it and start
> again. I remember reading somewhere that if a file which is being
> written to is removed it's blocks are not marked as free. What is the
> best way to remove this without risking removing a file which may be
> open?

There's no real risk involved in removing an open file (depending on what
it is, of course). If you delete a file that's open, all that happens is
the file disappears from the directory, but it still exists. Once the
application using it closes it, the blocks will be unlinked and
deallocated and it will be gone.

The normal way to handle deleting open log files, for example, is to
delete them and then stop and restart the program that's writing to
them. With syslogd it's only necessary to send it a SIGHUP and it will
close the currently open log files and reopen them - creating new ones if
needed.

I'm not familiar with proclog - is it procmail? If so, doesn't procmail
only run when it's called by the MTA to handle an email? If it does, and
you delete or rename the log file, then the next instance of it should
create a new log file and carry on.


--
http://SnapAndScribble.com

From: Chris Davies on
Justin C <justin.0805(a)purestblue.com> wrote:
> My .proclog is getting quite large and I'd like to remove it and
> start again.

rm .proclog


> I remember reading somewhere that if a file which is being written to
> is removed it's blocks are not marked as free.

When the file has no more open file descriptors, it will be deleted for
you and the space freed. This is often used to create "nameless"
temporary files (and yes, there's a race condition):

open /tmp/secret.file
rm /tmp/secret.file
...
read-write /tmp/secret.file until finished
close /tmp/secret.file


> What is the best way to remove this without risking removing a file
> which may be open?

In procmail's case, you can simply delete it. For other applications,
specifically including apache, log files are held open for the duration,
and although you can delete them from the filesystem they're not
actually deleted until you bounce the application.

Chris
From: Nick Craig-Wood on
Justin C <justin.0805(a)purestblue.com> wrote:
> My .proclog is getting quite large and I'd like to remove it and start
> again. I remember reading somewhere that if a file which is being
> written to is removed it's blocks are not marked as free. What is the
> best way to remove this without risking removing a file which may be
> open?

If you just rm the file it will remain open with no name and still
using up disk space until the last process with the file open exits or
closes it.

Assuming that the programs writing to the file are doing so in append
mode (which is normal for log files) then the correct thing to do is

cp /dev/null .proclog

Which is shorthand for truncating the file.

That technique certainly works for log files opened by syslog, whether
it works for your application you'll have to see!

--
Nick Craig-Wood <nick(a)craig-wood.com> -- http://www.craig-wood.com/nick
From: Justin C on
On 2008-05-07, Nick Craig-Wood <nick(a)craig-wood.com> wrote:
> Justin C <justin.0805(a)purestblue.com> wrote:
>> My .proclog is getting quite large and I'd like to remove it and start
>> again. I remember reading somewhere that if a file which is being
>> written to is removed it's blocks are not marked as free. What is the
>> best way to remove this without risking removing a file which may be
>> open?
>
> If you just rm the file it will remain open with no name and still
> using up disk space until the last process with the file open exits or
> closes it.
>
> Assuming that the programs writing to the file are doing so in append
> mode (which is normal for log files) then the correct thing to do is
>
> cp /dev/null .proclog
>
> Which is shorthand for truncating the file.
>
> That technique certainly works for log files opened by syslog, whether
> it works for your application you'll have to see!

Thanks Nick, and Chris and Will, for you suggestions. I'd got the wrong
end of the stick with that one. Yes, this is procmail, and it only
appends to the log when it is called, so it may well be that it isn't
being written to when I delete it, and there is no problem. But even if
it is open when I delete it, it won't be for long.

Thank you for the help with this.

Justin.

--
Justin C, by the sea.