On Mon, Aug 4, 2008 at 2:34 PM, Fabien Carmagnac <[EMAIL PROTECTED]> wrote: > Hello, > > I have a problem when I remove a file which is a redirection of the std > output of a process: > > I launch a process and redirect output to file: > [EMAIL PROTECTED] ./myprocess &> mylog.log
This is somewhat dangerous. The stdout output of that program will be buffered and the stderr output will not. It is quite possible that you will see out-of-order results in that "log" file while normally one would want to use a log file as an unambiguous record of past events. > Then (after a few days/weeks), I remove the mylog.log file, hoping the system > will create a new fresh one. Somebody else already addressed the misconception here. [snip] > After a few days, df gives 100% disk used but kdirstat (a gui tool to watch > size of each folder recursivly), says 20%used. Yes, the log file has no name any more but it has not yet been deleted, since a process is holding it open. > > Then, if I reboot, df says 20%used also. > > So my question is : is there a way to rotate/remove/resize logs without: > - reboot computer Obviously. Many Unix programs do this. One typically designs such programs to manage their own log file. A well-designed long-running program will also do other things to prepare for robust longevity, for example - disassociating itself from its controlling terminal - changing directory in order to avoid blocking the unmounting of filesystems Long-running programs are often designed to reopen their logfile when they receive SIGHUP. See for example the documentation for the logrotate tool to get some understanding of this. > - stop process flishing in it Sorry, didn't understand this. > The computer is used as a very critical node in our organisation (quick > trading 24/24). In that case you should probably use more than one computer. Being physical objects, they can fail. But then I have no way of knowing if the cost of an outage in your environment would justify the use of a second computer, so feel free not to take my advice. James. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils