Logrotate cronjob fails but running at command-line works.
March 21, 2009 11:32 PM Subscribe
Why does my logrotate.conf file work correctly when logged in as root, but fail when executed as part of cron.daily?
I have a few custom application logs that I want to rotate automatically using logrotate. I picked as a base template, the logrotate.conf file that gets installed for Apache:
OS Info - CentOS 5, 64-bit running on a VPS.
Please help!
I have a few custom application logs that I want to rotate automatically using logrotate. I picked as a base template, the logrotate.conf file that gets installed for Apache:
/var/log/httpd/*log { missingok notifempty sharedscripts postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true endscript }Here are two logrotate.conf entries that I created:
/var/log/hellavcr.log { ifempty missingok nomail weekly rotate 1 } /var/log/hellanzbinit.log { ifempty missingok nomail daily rotate 2 }If I sudo as root and execute "/usr/sbin/logrotate hellanzb" the command executes without any errors. However, every time the cronjob "/etc/cron.daily/logrotate" runs I get a bunch of error messages:
sh: line 2: missingok: command not found sh: line 3: nomail: command not found sh: line 4: weekly: command not found sh: line 5: rotate: command not found sh: line 2: ifempty: command not found sh: line 3: missingok: command not found sh: line 4: nomail: command not found sh: line 5: daily: command not found sh: line 6: rotate: command not foundI've checked the permissions for both the logrotate.conf files and the actual log files and they seems to be identical as far as my applications and Apache goes - so why the errors?
OS Info - CentOS 5, 64-bit running on a VPS.
Please help!
I agree with idiopath; that's exactly the output you'd get if the shell is trying to exec the logrotate.conf file.
posted by caphector at 11:51 PM on March 21, 2009
posted by caphector at 11:51 PM on March 21, 2009
Response by poster: idiopath, caphector: This is the script that is being executed by cron:
posted by your mildly obsessive average geek at 12:03 AM on March 22, 2009
#!/bin/sh /usr/sbin/logrotate /etc/logrotate.conf EXITVALUE=$? if [ $EXITVALUE != 0 ]; then /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]" fi exit 0logrotate.conf has the following permissions:
-rw-r--r-- 1 root root 520 Dec 1 2007 /etc/logrotate.confThe additional configuration files under /etc/logrotate.d/ have the following permissions:
-rw-r--r-- 1 root root 75 Feb 12 06:10 hellanzb -rw-r--r-- 1 root root 72 Feb 12 06:10 hellavcr -rw-r--r-- 1 root root 167 Nov 12 10:43 httpd
posted by your mildly obsessive average geek at 12:03 AM on March 22, 2009
What is the contents of /etc/logratotate.conf? A typo there could be doing this.
posted by idiopath at 12:13 AM on March 22, 2009
posted by idiopath at 12:13 AM on March 22, 2009
Response by poster: idiopath: Here's what logrotate.conf looks like:
posted by your mildly obsessive average geek at 12:38 AM on March 22, 2009
# see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # uncomment this if you want your log files compressed #compress # RPM packages drop log rotation information into this directory include /etc/logrotate.d # no packages own wtmp -- we'll rotate them here /var/log/wtmp { monthly minsize 1M create 0664 root utmp rotate 1 } # system-specific logs may be also be configured here.
posted by your mildly obsessive average geek at 12:38 AM on March 22, 2009
If it works while for you from a command line, but not from cron, I'd check for pathing problems. For cron jobs, you need explicit paths for all commands, but when you're logged in, you probably have some paths defined that allow commands to work without explicit paths in your scripts and conf files.
posted by ursus_comiter at 6:29 AM on March 22, 2009 [1 favorite]
posted by ursus_comiter at 6:29 AM on March 22, 2009 [1 favorite]
Following up on what ursus_comiter said, I would try running /usr/bin/printenv from both the command line, and from within cron, and comparing the two, as it could easily be pathing or other environment variable issues.
posted by fings at 7:28 AM on March 22, 2009
posted by fings at 7:28 AM on March 22, 2009
what happens when you run:
/usr/sbin/logrotate /etc/logrotate.conf
directly as root?
I'm wondering if there are errors somewhere else (aside from your conf files).
posted by alikins at 9:40 AM on March 22, 2009
/usr/sbin/logrotate /etc/logrotate.conf
directly as root?
I'm wondering if there are errors somewhere else (aside from your conf files).
posted by alikins at 9:40 AM on March 22, 2009
Response by poster: Whoa, lots of answers but so far not too much luck :( . I'll try to reply one by one:
hades: This is the output from ls-l /etc/logrotate.d
hellanzb
hellavcr
httpd
named
proftpd
rkhunter
rpm
rtorrent
syslog
yum
As you can see, hellanzb is the first listing in the folder so it's unlikely there's a conflict.
ursus_comiter, fings, intermod: I don't know enough about CentOS to be certain but I *believe* this particular cronjob runs under the account "nobody". It certainly doesn't run under root, as it isn't in the crontab -l listing for root and there is no user called "cron" in /etc/passwds.
Now, the "nobody" account shell is set /sbin/nologin which means I can't su in to check the environment. I could probably modify the account to a regular shell, but then I wouldn't be replicating the problem exactly.
I could be completely wrong about the account details, but this is my (vague) understanding.
alikins: If I run that command as root, no errors at all - process exits cleanly.
I'm pretty sure I'm failing to state something obvious which could resolve this problem in a jiffy :(
posted by your mildly obsessive average geek at 10:32 PM on March 22, 2009
hades: This is the output from ls-l /etc/logrotate.d
hellanzb
hellavcr
httpd
named
proftpd
rkhunter
rpm
rtorrent
syslog
yum
As you can see, hellanzb is the first listing in the folder so it's unlikely there's a conflict.
ursus_comiter, fings, intermod: I don't know enough about CentOS to be certain but I *believe* this particular cronjob runs under the account "nobody". It certainly doesn't run under root, as it isn't in the crontab -l listing for root and there is no user called "cron" in /etc/passwds.
Now, the "nobody" account shell is set /sbin/nologin which means I can't su in to check the environment. I could probably modify the account to a regular shell, but then I wouldn't be replicating the problem exactly.
I could be completely wrong about the account details, but this is my (vague) understanding.
alikins: If I run that command as root, no errors at all - process exits cleanly.
I'm pretty sure I'm failing to state something obvious which could resolve this problem in a jiffy :(
posted by your mildly obsessive average geek at 10:32 PM on March 22, 2009
Response by poster: hades: I just checked the man page and discovered that ifempty *is* the default, so I'm going to remove that entry to see if helps things. Just for reference, here's the entire error log from the cron job:
/etc/cron.daily/logrotate:
sh: line 2: missingok: command not found
sh: line 3: nomail: command not found
sh: line 4: weekly: command not found
sh: line 5: rotate: command not found
sh: line 6: postrotate: command not found
sh: line 2: missingok: command not found
sh: line 3: nomail: command not found
sh: line 4: weekly: command not found
sh: line 5: rotate: command not found
sh: line 6: postrotate: command not found
sh: line 2: ifempty: command not found
sh: line 3: missingok: command not found
sh: line 4: nomail: command not found
sh: line 5: daily: command not found
sh: line 6: rotate: command not found
sh: line 7: postrotate: command not found
sh: line 2: ifempty: command not found
sh: line 3: missingok: command not found
sh: line 4: nomail: command not found
sh: line 5: weekly: command not found
sh: line 6: rotate: command not found
sh: line 7: postrotate: command not found
posted by your mildly obsessive average geek at 11:12 PM on March 22, 2009
/etc/cron.daily/logrotate:
sh: line 2: missingok: command not found
sh: line 3: nomail: command not found
sh: line 4: weekly: command not found
sh: line 5: rotate: command not found
sh: line 6: postrotate: command not found
sh: line 2: missingok: command not found
sh: line 3: nomail: command not found
sh: line 4: weekly: command not found
sh: line 5: rotate: command not found
sh: line 6: postrotate: command not found
sh: line 2: ifempty: command not found
sh: line 3: missingok: command not found
sh: line 4: nomail: command not found
sh: line 5: daily: command not found
sh: line 6: rotate: command not found
sh: line 7: postrotate: command not found
sh: line 2: ifempty: command not found
sh: line 3: missingok: command not found
sh: line 4: nomail: command not found
sh: line 5: weekly: command not found
sh: line 6: rotate: command not found
sh: line 7: postrotate: command not found
posted by your mildly obsessive average geek at 11:12 PM on March 22, 2009
Response by poster: hades: Ah! Light finally dawns. I was missing a endscript entry for the files where I had a prerotate entry. In other words I was doing:
posted by your mildly obsessive average geek at 12:46 AM on March 23, 2009
/var/log/rtorrentInit.log { prerotate /sbin/service rtorrent stop > /dev/null 2>/dev/null || truemissing an endscript here!
ifempty missingok nomail daily rotate 2 postrotate /sbin/service rtorrent start > /dev/null 2>/dev/null || true endscript }I knew that posting the full error message would be useful for something!
posted by your mildly obsessive average geek at 12:46 AM on March 23, 2009
This thread is closed to new comments.
posted by idiopath at 11:42 PM on March 21, 2009