my custom.conf file for logrotate is only performing the renaming of old files but not disposing them after my maxage day. i can see it rotating the files. the custom.conf file is saved to /etc/logrotate.d/ directory. can someone please tell me if i am missing something here?
It just continues to add previous dates *.log-20180428-20180430-20180502-20180504 at the end of my log file.
Here is the custom.conf file (Note: directory_name path is a mounted drive.)
/directory_name/*/*/*.log*
/directory_name/*/*.log*
{
daily
compress
delaycompress
rotate 4
ifempty
maxage 4
nocreate
missingok
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd-ng.pid 2> /dev/null` 2> /dev/null || true
endscript
}
The /etc/logrotate.conf file should not start and end with { and } like that.
And maxage and rotate is probably not needed both (I always just use rotate, never maxage).
Before { there should be a file name, like this:
/var/log/mylog {
...
}
You should probably add and change files in the /etc/logrotate.d folder instead of changing the /etc/logrotate.conf file. (Protects better against automatic changes on system upgraded I think, and cleaner)
Related
I have a problem with logrotate. The application itself produces following logs:
xxx.log
and at 23:59 the application changes the log to:
xxx.log.2019-01-05
and so on. Right now I am getting following in the log directory:
xxx.log
xxx.log.2019-01-01
xxx.log.2019-01-02
etc.
What I need to to is want to rotate the logs that get created on 23:59 and not to touch the xxx.log file itself.
I have tried with following logrotate rule:
/var/log/xxx/xxx/xxx.log.* {
daily
missingok
rotate 30
compress
notifempty
copytruncate
nosharedscripts
prerotate
bash -c "[[ ! $1 =~ *.gz ]]"
endscript
}
But first of all logrotate does not compress the log that was created last and it also adds .1.gz extension to previously compressed files.
logrotate does not compress the log that was created last
Do you have "delaycompress" defined in /etc/logrotate.conf? Per logrotate man:
delaycompress
Postpone compression of the previous log file to the next rotation cycle.
it also adds .1.gz extension
While you're at the aforementioned man page, you should check out what the "extension" option does:
extension ext
Log files with ext extension can keep it after the rotation.
I have a logrotate setting in logrotate.conf that doesn't want to run. What I'm trying to do is:
Rotate the log every day and truncate the log
Emailing me the rotated lines of the log
Adding the lines of the rotated log to a monthly archive
Create olddir rotated/ if it doesn't exist yet
What am i missing here?
(log file path){
daily
rotate 0
olddir rotated
copytruncate
nodateext
missingok
notifempty
compress
mailfirst
mail email (at) email . com
prerotate
original = $1
replacement = 'rotated'
olddir_path = "${original/php-error.log/$replacement}"
mkdir olddir_path
endscript
postrotate
original = $1
replacement = 'rotated'
olddir_path = "${original/php-error.log/$replacement}"
cat "${olddir_path}/php-error.log.1" >> "${olddir_path}/php-error-monthly.log"
endscript
}
You were great all the way up to "Create olddir rotate/ if it doesn't exist yet". Run logrotate -d /etc/logrotate.conf and I'll bet you get something like this back for that configuration:
error: /etc/logrotate.conf: error verifying olddir path rotated: No such file or directory
This is because that directory needs to exist at the time logrotate reads its configuration file; this is before any prerotate scripts are executed so naturally that directory does not exist and parsing the configuration fails. Make that directory first, however you'd like but first.
For some reason our tomcatlogs are being appended with a .1 when logrotate runs. e.g:
file "tcl-2013-08-16.0.log" becomes "tcl-2013-08-16.0.1.log". I am struggling to find what setting is adding the ".1" before the ".log" part of the file name. Below is a copy of the settings file from /etc/logrotate.d/:
extension .log
rotate 52
daily
nocreate
nodateext
missingok
notifempty
compress
delaycompress
Below is the config in /etc/logrotate.conf:
weekly
rotate 52
create
dateext
compress
delaycompress
include /etc/logrotate.d
What am I missing here?
Thanks, Nath
If you look at the copy of the settings file from /etc/logrotate.d/", you will find there is this option extension .log.
This option means you are trying to append the .log extension to rotated files.
If you remove this option and run logrotate again, you will find that by default the extension will be *.log.1 , *.log.2, and so on for the rotated files.
In a nutshell, remove the option extension .log. Because the rotated files will take .log as extension.
Currently my log file sits at 32 meg. Did I miss an option that would split the log file as it grows?
You can use logrotate to do this job for you.
Put this in /etc/logrotate.d/mongod (assuming you use Linux and have logrotate installed):
/var/log/mongo/*.log {
daily
rotate 30
compress
dateext
missingok
notifempty
sharedscripts
copytruncate
postrotate
/bin/kill -SIGUSR1 `cat /var/lib/mongo/mongod.lock 2> /dev/null` 2> /dev/null || true
endscript
}
If you think that 32 megs is too large for a log file, you may also want to look inside to what it contains.
If the logs seem mostly harmless ("open connection", "close connection"), then you may want to start mongod with the --quiet switch. This will reduce some of the more verbose logging.
Rotate the logs yourself
http://www.mongodb.org/display/DOCS/Logging
or use 'logrotate' with an appropriate configuration.
Using logrotate is a good option. while, it will generate 2 log files that fmchan commented, and you will have to follow Brett's suggestion to "add a line to your postrotate script to delete all mongod style rotated logs".
Also copytruncate is not the best option. There is always a window between copy and truncate. Some mongod logs may get lost. Could check logrotate man page or refer to this copytruncate discussion.
Just provide one more option. You could write a script that sends the rotate signal to mongod and remove the old log files. mongologrotate.sh is a simple reference script that I have written. You could write a simple cron job or script to call it periodically like every 30 minutes.
I looked at logrotate.conf examples and everything in my /etc/logrotate.d directory. Nowhere was I able to find documentation on variables in these files.
I am trying to create a config file for rotating the logs of an application we are writing. I want to set the directory where logs are stored once, and then use it as a variable, like so:
my_app_log_dir=/where/it/is/deployed/logs
${my_app_log_dir}/*.log ${my_app_log_dir}/some_sub_dir/*.log {
missingok
# and so on
# ...
}
Is that possible?
You can achieve what you are looking for by implementing this kludge:
my-logrotate.conf ( NOTE: double quotes " are mandatory, also note that file names don't have to appear on the same line )
"*.log"
"some_sub_dir/*.log"
{
missingok
# and so on
# ...
}
Then the actual logrotate script - my-logrotate.sh
#!/bin/sh
set -eu
cd "${my_app_log_dir}"
exec logrotate /path/to/my-logrotate.conf
Now you can add logrotate.sh to your crontab.
You can use a bash "here document" to create a suitable config file on the fly, either at installation time or before running logrotate.
A bash script might look like this:
cat >rt.conf <<.
"${my_app_log_dir}/*.log" {
rotate 5
size 15k
missingok
}
.
logrotate rt.conf
Directly in the config file no (as far as my knowledge in logrotate goes).
Other solution:
Use the include option to include parts of the configuration file from a directory. This can help you if you have a package for your application, the package can leave a file in that directory containing only the entries for your app.
With logrotate 3.8.7,a test reveals that you can set and use variables in the pre-rotate and post-rotate script sections.
I tried this for a particular service log file.
postrotate
pid_file="/run/some_service/some_serviced.pid"
test -e "${pid_file}" && kill -s HUP $(cat "${pid_file}") || true
touch "${pid_file}.WAS_USED"
endscript
After running logrotate in force mode to ensure the log file was rotated and the post-rotate script executed, on looking in /run/some_service, there was an additional file "some_serviced.pid.WAS_USED", thus proving that the use of the variable worked.