Issues with Logrotate

From: AverageSecurityGuy 
------------------------------------------------------
I have an application that is writing to a log file and I am using =
logrotate to rotate the file daily. The problem is after logrotate runs, =
the application is writing to the old log file not the new one. I=92ve =
done some research and it looks like the application is writing to the =
file based on the inode and not the filename. Is there a way to work =
around this problem or does the application need to be fixed?

The application is running on CentOS 6.x

The logrotate configuration file looks like this.

/opt/controller/lce/lce.log {
    notifempty
    rotate 3
    daily
    dateext
    create 0644 lce lce
}

Thanks,

--
Stephen Haywood
Owner, ASG Consulting
CISSP, OSCP
423.305.3700
asgconsulting.co




=============================================================== From: Wil Wade ------------------------------------------------------ A little Googling says you will need to setup the logrotate script to create a new file for the old logs, copy the data, and then clear the original file. //Cannot do it basically... http://stackoverflow.com/questions/5752822/how-do-i-create-a-file-with-a-sp= ecific-inode-number //What happens with the inode when I run cp/mv/etc... http://www.theunixschool.com/2012/08/move-files-and-directories-inodes-part= -3.html =99ve done is

=============================================================== From: Billy ------------------------------------------------------ I'm not sure that's an accurate description. Programs don't use file names to write to files. They use filedescriptors. T= hey open the file, assign it to a fd and then continuously write to that fd w= ithout closing it (until the end of execution or error). This is also atomic: you can write to this fd without worry of it disappeari= ng or changing to a different medium. The only thing you have to worry about= is IO errors (very bad) or out of space (bad). Linux provides this atomic functionality by protecting the inode/fd pair by e= nsuring if a process has the file open, you can't get rid of the data or cor= rupt the inode/fd. You can write to a file in one process, delete it from an= other shell, and in another shell watch your disk usage run out. There won't= be a file to delete, because you already deleted it. Once the original proc= ess ends, the used space is automatically freed (since the inode is no longe= r protected). Apache and syslogd handle this by responding to a HUP signal. They are progr= ammed to "reread configuration files" when they receive that signal (via the= kill -HUP command). Other programs must be restarted: service dumbprog restart To achieve the same effect. What you ultimately want to do is tell the program to flush it's buffers, cl= ose the file, then reopen the file, and continue on keeping on. Logrotate has special blocks called prerotate and postrotate that help do th= is. --b Sent from my iPhone te a new file for the old logs, copy the data, and then clear the original f= ile. pecific-inode-number t-3.html ate to rotate the file daily. The problem is after logrotate runs, the appli= cation is writing to the old log file not the new one. I=E2=80=99ve done som= e research and it looks like the application is writing to the file based on= the inode and not the filename. Is there a way to work around this problem o= r does the application need to be fixed?

=============================================================== From: AverageSecurityGuy ------------------------------------------------------ Thanks Billy, I=92ll take a look at prerotate and postrotate. -- Stephen Haywood Owner, ASG Consulting CISSP, OSCP 423.305.3700 asgconsulting.co filedescriptors. They open the file, assign it to a fd and then = continuously write to that fd without closing it (until the end of = execution or error). disappearing or changing to a different medium. The only thing you have = to worry about is IO errors (very bad) or out of space (bad). pair by ensuring if a process has the file open, you can't get rid of = the data or corrupt the inode/fd. You can write to a file in one = process, delete it from another shell, and in another shell watch your = disk usage run out. There won't be a file to delete, because you already = deleted it. Once the original process ends, the used space is = automatically freed (since the inode is no longer protected). programmed to "reread configuration files" when they receive that signal = (via the kill -HUP command). buffers, close the file, then reopen the file, and continue on keeping = on. do this. create a new file for the old logs, copy the data, and then clear the = original file. http://stackoverflow.com/questions/5752822/how-do-i-create-a-file-with-a-s= pecific-inode-number http://www.theunixschool.com/2012/08/move-files-and-directories-inodes-par= t-3.html wrote: logrotate to rotate the file daily. The problem is after logrotate runs, = the application is writing to the old log file not the new one. I=92ve = done some research and it looks like the application is writing to the = file based on the inode and not the filename. Is there a way to work = around this problem or does the application need to be fixed?