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.
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.
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)
in last days i get daily mail from cron's logrotate task:
/etc/cron.daily/logrotate:
gzip: stdin: file size changed while zipping
How can I fix it?
Thanks,
Gian Marco.
Here's a blog post in French which gives a solution.
In English, you can read this bug report.
To summarise:
First you have to add the --verbose option in the script /etc/cron.daily/logrotate to have more information the next time it runs to identify which rotation log cause the problem.
#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate --verbose /etc/logrotate.conf`
Next you have to add the delaycompress option in logrotate configuration.
Like exemple, I add the nginx's logrotate configiguration in /etc/logrotate.d/nginx:
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
...
}
upstart will close (and reopen) its log file when it notices that the file is deleted. However, if you look at what gzip does, you see that it doesn't delete the file until after it's one writing the output file. That means that there always is a race condition where log lines might be lost for lines logs being written gzipping.
You can disable the warning using gzip --quiet, but really that doesn't hide the fact that you might still loose log lines.
This means that delaycompress is not a generic fix to this. It's a specific fix to a specific problem.
The real solution for this is probably a combination of delaycompress and being able to send a signal to the process. It will make the race condition go away in practise (unless you rotate multiple times per second :) ).
Hello people
It's my first time using logrotate and I don't know if I'm configuring it in the right way. I'm using it with loggerhead log file in Ubuntu 11.04
Log is under
/log/loggerhead/loggerheadd.log
My configuration file looks like this
/log/loggerhead/loggerheadd.log {
daily
rotate 7
compress
delaycompress
missingok
}
Then I run a force rotation
logrotate -f /etc/logrotate.d/loggerhead
and that change the name of the log file to
/log/loggerhead/loggerheadd.log.1
And didn't create the original file (loggerheadd.log) again, so I couldn't run a new force rotation, because "the file doesn't exist".
So, it's supposed that the application write entries in "loggerheadd.log" but when logrotate run the file will be renamed, so where will be written the log entries? Am I missing something?
Hope you can help me
By default logrotate will just rename your files, so your old file will be gone.
You can either use the create option to create a new file after the old one is used, or copytruncate to copy the original file to one with a new name, then truncate the original. Either option will do what you're asking for (more details on the man page here)
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.