I am getting the following error email every week. It appears to be a problem with either cron, logrotate, or denyhosts. I'm not sure which.
Subject: Cron <root@vps> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/logrotate:
test: 91: /etc/hosts.deny: unexpected operator
Any suggestions?
Yes, but it has this:
and that script does stuff like
assuming the script is correct, if I had to guess I'd say your HOSTS_DENY line in your config file is malformed somehow.
Fortunately, we don't have to guess, this command will show you exactly where the error is coming from:
To me it looks like there is an error in line 91 of /etc/hosts.deny or /etc/cron.daily/logrotate.
Make sure entries in hosts.deny are formatted validly.
My bet is that somewhere there's a
sh
script with a double equal sign ("==") in atest
command instead of a single one ("="). Bash's builtintest
allows==
or=
, but the Bourne shell (at leastdash
on Ubuntu) only allows=
. Also, my/usr/bin/test
only allows the single equal. But see the bottom of this answer for other examples that produce this same error.I would look in
logrotate.conf
and see if it has a line 91 that might have that problem.If, for some reason, you want to recreate the error message for testing:
Create a file, let's call it "a", with the following contents:
Now do:
You should get:
You can also reproduce a similar error using any of the following:
Edit: Try the following to narrow down your search:
You will
su
to root, then run thefind
/awk
command. It will show you the filenames and line 91 of the file if the word "test" appears on that line, for each file under/etc
. Then you can look for operators that are incorrect.How about in /etc/logrotate.d/denyhosts ?
/etd/logrotate.d/denyhosts is very short and doesn't seem to me to use test:
/var/log/denyhosts {
create 0640 root root
missingok
weekly
rotate 7
compress
postrotate
/etc/init.d/denyhosts restart > /dev/null
endscript
}
The only instance of "test" on line 91 of a file in /etc is in an unrelated file.
The cron.daily/logrotate job point at /usr/sbin/logrotate (a binary file) -- if the bug is in there, where could I check the source code?
Just for sanity you may want to use:
to see that the test program is what you think it is. One defensive programming method is to use the full path to commands in cron jobs. This ensures the proper binary is called and prevents an attacker from substituting another similarly named command earlier in your PATH.
Here's some troubleshooting tips. I think Justin is absolutely on the right track. The problem is probably in your denyhosts setup. But let's track it down.
You're getting the error originally from logrotate. So run logrotate:
Assuming you get an error, at least you've got a reproducible case. Now let's see if the problem is in logrotate or denyhosts. Let's use the denyhosts command we saw in logrotate:
If that gives you an error, you're really close to tracking this down. Try taking off the "> /dev/null" from the end of the line to get more information. Post the output here for help.
However, if neither of the above two tricks got you an error, but you're still getting the error from the cron jobs, you've got a problem. Waiting a week between attempts to debug something sucks.
Add another line to your /etc/crontab. Copy the cron.weekly line, and paste it below all the other lines. Then edit it so all the "when" entries are asterisks.
Change that to:
Then it will run once a minute all day long, all week long. This is obviously not something you'd want to leave in there, but it can be helpful in troubleshooting.
In cases where you see errors in cron jobs that you don't see when running the scripts from the command-line, it's almost always a difference in your environment. Check the path first.
I had this same issue after uninstalling the denyhosts package. Confirm that you actually have the package installed:
You'll have "ii" as the first two characters if the package is installed. For example, I have openssh-server installed and get this result:
In my case, I think the logrotate configuration was not successfully removed when the package was removed, so I manually rm'd it.