Red Hat Bugzilla – Bug 428440
Denyhosts fails to start from control script
Last modified: 2008-01-14 15:04:59 EST
Description of problem: Denyhosts fails to start from control script
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Start denyhosts service
[root@arturo ~]# service denyhosts start
starting DenyHosts: /usr/bin/env python /usr/bin/denyhosts.py --daemon
Could not find environment variable: HOSTNAME
Denyhosts daemon starts
Added os.environ['HOSTNAME'] = "arturo" to /usr/bin/denyhosts-control for
I have to admit I find this odd, because that's not the expected output from the
denyhosts initscript. First off, can you verify that /etc/init.d/denyhosts
looks like this, down after the initial comment block:
# Make sure HOSTNAME is in the environment so denyhosts can
# use it in report subjects
If so, do you have a /bin/hostname executable?
If so, can you try changing the line:
in /etc/init.d/denyhosts to
just to rule out the possiility that the initscript is somehow being called with
no PATH defined.
Created attachment 291470 [details]
denyhosts init script
My init script does not match that at all.. I am attaching it so you can have a
look.. I checked to see there were no .rpmnew versions of it as well.
Well, it doesn't seem like your problem is actually with denyhosts; it looks
like either something went wrong when the package was installed or something
else is wrong with your system.
Things to try:
rpm -V denyhosts (as root, should give no output)
Make sure that /etc/init.d is a symlink to /etc/rc.d/init.d.
Uninstall and reinstall the denyhosts package.
There was a time before the release of F8 when we shipped a different
initscript; I suppose it's possible that you upgraded but the upgrade went awry
and left you with the old one somehow.
Uninstall and reinstall fixed this issue. Although the version and arch of the
removed and installed packages were identical, there was a mismatch in size. My
init script has now been replaced with the working version. I can only guess
that this happened when I upgraded from fedora 7 to 8.