How can I keep a file busy

[Hakki Aydin Ucar]

I wanted to keep a file ;plain text file; busy so that I can monitor with fuser and cannot rm with an error "text file busy"

[V. Nyga]

Hi,

you can try with editing it - with vi for example.

Volkmar

[Suraj K Sankari]

hi,
if you open a file in vi then you can't unmount that file system fuser will show devise is busy,
but
>>cannot rm with an error "text file busy"
This will not be possible because if a file is open in one session you can delete this file from other session.

Suraj

[Venkatesh BL · Accepted solution]

try this:

# cat exe1.c ;; program which just waits for input.
#include

int main(argc,argv)
int argc;
char **argv;
{
getchar();
exit(0);

/* NOTREACHED */
return 0;
}

# cc exe1.c -o exe1 ;;compile

# ./exe1& ;; run in background
[1] + Stopped (SIGTTIN) ./exe1&

# rm exe1 ;;now try to remove the file.
rm: exe1 not removed. Text file busy

#

[Laurent Menase]

it just need to be a running executable.

[Hakki Aydin Ucar]

vi a plain text file it is not possible to get error like text file busy cannot rm that . .

I think it is only in question for executables, not possible to reproduce for plain text ? Am I right ?

[Laurent Menase]

Yes ,scripts can be removed while executing because they are not text file in the sens of process description where text is the code part.

[Venkatesh BL]

Yes, as Laurent mentioned, your definition of 'Text file' is different from what kernel refers.

[Michael Steele_2]

tail -f file & (* indefinite and in background - will have to kill -9 the process to close file *)

[Laurent Menase]

no tail -f will indeed keep it open, but as it is not a "text" -understand executable text and not plain text, and it is not executed -
it will not avoid rm to work on the file.

[James R. Ferguson]

Hi:

Using 'kill -9' should be a last resort for any process. Since it cannot be trapped (caught) a process isn't given an opportunity to cleanup any temporary files, shared memory segments (nasty!) or perform any other epilog processing.

A simple 'tail -f' can be terminated by a simple 'kill' alone.

As for using 'vi', 'vi' makes an in-memory copy of the file to perform its work and does not hold a file open for the duration of its edit.

Regards!

...JRF...

[TTr]

What exactly are you trying to do with the plain text file? May be there is a different solution to your problem.

By the way you can create a "text file busy" quickly

# cp /usr/bin/more /tmp/m
# /tmp/m /etc/hosts (ensure /tmp/m does not exit)

In another shell try "rm -f /tmp/m". You can use any binary that you can keep it running in one shell and try removing it from another.

[Dennis Handly]

>TTr: What exactly are you trying to do with the plain text file?

Right. If you want to keep the file from being removed by mistake, you could create more hardlinks to it.

[Hakki Aydin Ucar]

What exactly wanted to do it is that there is a log file collecting data continuously, and therefore it s getting bigger in time, So I want to trim/truncate it in some periods. I cannot be sure before go to trimming stop thatthat and then trim, or just trim with the on of the commands:
>log_file OR cat /dev/null > log_file

apparently it seems I do not to stop or close before trimming this file since it is a text file ?

[TTr]

> there is a log file collecting data continuously, and therefore it s getting bigger in time, So I want to trim/truncate...

If you do something to this log file, you have to know what will happen to the process(es) that write to it. Sometimes nothing happens and they continue running and writing to the log file, sometimes they will hang and need restarting. For example if you do something to /var/adm/syslog/syslog.log file, the syslogd daemon will hang and need to be restarted.
Are these applications from a well known vendor? Check with the vendor to see if they have a special method for cleaning/rotating the logs. Or if you have a test environment you need to do some testing.

[James R. Ferguson]

Hi Hakki:

> apparently it seems I do not to stop or close before trimming this file since it is a text file ?

If your file isn't an executable in the sense that Laurent cited, and thus is a simple ASCII "text" file, you can truncate it by doing either:

# > filename

or:

# cat /dev/null > filename

If no process is using the file, it will be reduced to a size of zero.

If a process is using the file, then this will return disk blocks to the system but will not change the length of the file that the process with the file open "sees". Rather the file will be sparse with nulls at its beginning. This is generally not an issue for log files.

Regards!

...JRF...

[Hakki Aydin Ucar]

>TTr: In another shell try "rm -f /tmp/m". You can use any binary that you can keep it running in one shell and try removing it from another.

I see ,if I checked the more ;
# file /usr/bin/more
/usr/bin/more: PA-RISC1.1 shared executable dynamically linked

1-dynamic linked OR compiled executables cannot be removed while they are open/busy.
2-text files can be removed when they are open/busy since they have another temporary session.
3-shell scripts can be removed when they are open/busy since they are somehow a text file and have same behavior.


>JRF: If a process is using the file, then this will return disk blocks to the system but will not change the length of the file that the process with the file open "sees".

As far I understand, when it is active cannot truncate it but possible to trim when it is only open and not used by a process.

[Cesare Salvioni]

hi,
1. you cannot delete a file only if it's a executable file running (this give the error text file busy) or if it's a open file locked, really rarely used
2. you can always trim (whith > filename) a file only opened by applications
3. be carefull about removing a file, if a process has opened for writing the file, the system will apparently delete the file (you can't see it with ll) but will defere the operation as soon as the process close the file. In the while space on disk will still be useed and the file handle given to the process will still be valid, that means the process will still write on a 'ghost' file.

Usually applications logs to file in two styles, they can open the log file at the very beginnig, keep it open and close at the end or open and close each time they want to log.
In the first case removing and recreating the log is uneseless or space wasting as far as you can't signal (maybe with kill -HUP) the process to close and reopen the log file.
In the second removing and recreating the log file is good.
In both case trimming with > filename should do the trick because the system truncate the file transparently for the process.
Be aware also about moving (renaming) the file, if the process has the file opened what is really important is the file handle, tied to the inode, not to the name. So if you move and recreate the file, the process will still continue to write to the old renamed logfile, not to the new.
This is also the way to change an executable, rename it and copy the new file, once all the processes using that executable file are dead, you can delete the old executable.

Hope thi helps

[Hakki Aydin Ucar]

Most of the answers was useful for me. Thanks.