LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   [logrotation] (https://www.linuxquestions.org/questions/linux-software-2/%5Blogrotation%5D-4175529077/)

thomas2004ch 12-23-2014 03:17 AM

[logrotation]
 
On one of our LINUX machine there is a Java application deployed on a Jboss server. This application writes everyday many logs in the server.log. But this log is not rotated everyday.

Surely one can configure the log4j.xml. But on LINUX there is logratate alrotithm under the /etc/logratade.d.

I've try this and the log file could be rotated. But after rotation there is no any log written into the server.log. I have to reboot the machine, then the log could be written into the server.log. But the day after that the server.log is rotated but no logs more written in to the server.log

I wonder why?

pascaltaf 12-23-2014 03:32 AM

Hi Thomas
 
The reason is simple I think, but the solution is not always easy to implement.
When your server.log is moved to another name (which name I don't know), does it keep on growing ?
I don't know very well logrotate, I use the good old newsyslog to perform log rotation, and the idea is that it has 2 things to do :
- renaming the log files
- telling the processes which write in the log files that they have been renamed
For example, if you manually move /var/log/messages to whhichever name you want (let's say /var/log/messages.old) and you don't tell syslogd it has moved, then syslogd will continue writing in /var/log/messages.old instead of creating a new /var/log/messages and writing to it.
If you tell him by performing
kill -HUP `pgrep syslogd`
then it will close its file descriptor and open a new one and then write to the newly created /var/log/messages.

sag47 12-23-2014 03:38 AM

It's because once JBoss/Tomcat has an open file handle for server.log it doesn't ever close it and re-open a new file handle. Thus the behavior you see is java continuing to run without writing to a new server.log. If left as is then the server.log will eventually fill up all of your disk space (you'll see a discrepancy between df and du commands in space usage); however, once JBoss is restarted your disk space will be reclaimed until the next time it happens. If you would like to learn more about this behavior then see this LQ thread.

To answer your question for resolving it you want to use the "copytruncate" option in logrotate (see man logrotate). An example of using copytruncate.

Code:

/var/log/samba/* {
    notifempty
    olddir /var/log/samba/old
    missingok
    sharedscripts
    copytruncate
}

EDIT: after some light experimentation I believe pscaltaf is right about it growing after being renamed. I had a process open and looked up its file descriptor based on PID.

Code:

ls -l /proc/1234/fd/
#more generically /proc/<PID>/fd/

When I moved the file and ran the ls command again the file descriptor was still pointing at the renamed file. So the behavior is likely it will keep writing to the renamed file. You'll still have to use the copytruncate option or do the right thing with log4j.

SAM

pascaltaf 12-23-2014 04:05 AM

Or maybe use the postrotate option :
Code:

postrotate
/usr/bin/killall jboss

or something like that, depending on what process is to be warned.
But this doesn't always fit, because some processes don't reply correctly to the kill -HUP, some just die when they receive it, some kill their children so you have to test what is working with jboss without causing service interruption.

thomas2004ch 12-23-2014 04:38 AM

Quote:

Originally Posted by pascaltaf (Post 5289450)
Or maybe use the postrotate option :
Code:

postrotate
/usr/bin/killall jboss

or something like that, depending on what process is to be warned.
But this doesn't always fit, because some processes don't reply correctly to the kill -HUP, some just die when they receive it, some kill their children so you have to test what is working with jboss without causing service interruption.

Using the killall is quite danger.

---------- Post added 12-23-14 at 05:38 AM ----------

It seems no way is better than to configure the log4j.


All times are GMT -5. The time now is 09:12 AM.