in reply to File Locking and other apps

It might be relevant to know what OS you're using. I'm not a windows wizard, but I gather that the M$ OS has some deep locking mechanism, such that when a process opens a file for output, no other process gets to play with that file -- not no way, not no how.

In that case, you need to follow the previous advice: kill the current instance of the process, and restart it so that its log output is piped to some other process that will produce "rotation" log files. As indicated, log rotation scripts are already available, and of course, it could almost be as simple to cook up your own -- just decide what the rotation interval should be (hour, day, week) and how many intervals need to be kept at any given time (3, 7, 24, 31), come up with a suitable log file naming scheme, and have the rotation script delete the oldest file at each interval when it closes the current one and opens a new one.

On any unix-like OS, it should be possible to truncate a file even while some other process is writing to it. It can get messy, of course, depending on the nature of the output -- for a log file, probably the worst case would be ending up with a partial line at the beginning of the file.

Replies are listed 'Best First'.
Re^2: File Locking and other apps
by Anonymous Monk on Mar 07, 2006 at 02:35 UTC
    The Operating system is Solaris 9. I cannot stop the application because it is a critical app in our infrastructure (Custom C++ code). do you know how to do this?
[reply]
      You say you "cannot stop the application because it is a critical app...", and in the OP you said "this file is overwelming my filesystem." This is not clear.

      Is the app somehow able to keep running even when the filesystem is overwhelmed? Does the system never shut down at all? Is there no maintenance window, power outage or any other interruption in this critical app's operation?

      Surely there must be a point when the app stops, and when that happens, reconfigure its logging protocol before it starts again. Have its log output write to some sort of log rotation tool, as suggested above.

      As for your failed attempts to truncate the log file, perhaps this is a permission issue? What user/group owns the file and the directory that contains it? What are the permission modes on the file and on the directory that contains it? A user with adequate permission should be able to truncate the file. (Before truncating it, is it being backed up, and is that important?)

      Update: this is turning out to be a non-perl problem, unless you want to ask about how to re-invent log rotation in perl. Your options depend on knowing more about the app that is generating all this log data (and since it's not a perl app, we aren't talking about perl questions). You need to know things like:

      Is it a daemon that starts at boot time, or is it started some other way? Is there no control over the amount of logging output (either a config file or command line options at startup)? Does it require a specific file path/name to be the log file, or is it simply being started with stdout and/or stderr being redirected to this "overwhelming" file? Is the log info really useless (could you just redirect it to /dev/null)?

      Chances are, if you learn about that stuff, you'll find out how to solve the problem.

[reply]

In Section Seekers of Perl Wisdom