Bug 188536 - init script broken
init script broken
Product: Fedora
Classification: Fedora
Component: denyhosts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
: 198966 234751 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-04-10 18:32 EDT by Rudolf Kastl
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-24 15:23:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix the start/stop/restart etc init functions to behave properly (1.04 KB, text/plain)
2007-04-03 18:34 EDT, Jonathan Underwood
no flags Details
Updated patch (3.81 KB, patch)
2007-04-04 13:42 EDT, Jonathan Underwood
no flags Details | Diff

  None (edit)
Description Rudolf Kastl 2006-04-10 18:32:44 EDT
Description of problem:
the init script doesent return success or failure properly so for the event of
starting and stopping the commandline used is displayed instead OK or FAIL

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. service denyhosts start
Actual results:
starting DenyHosts:    /usr/bin/denyhosts.py --daemon --config=/etc/denyhosts.conf

Expected results:
DenyHosts starten:             [OK]

Additional info:
additionally the initscript should be tweaked to use NLS. i can file that as a
seperate bug.
Comment 1 Jason Tibbitts 2006-04-10 18:56:06 EDT
The init script just calls into Denyhosts's control script and does properly
return any exit values.  So I'm afraid I don't understand what it is that you're
reporting here.  The string "starting DenyHosts..." is printed by denyhosts
itself.  The script starts and stops denyhosts as expected, so I don't see how
you can call it "broken".

I also do not understand what you mean by "tweaked to use NLS".  If you have
patches, I will happily pass them upstream, but a Fedora-specific rewrite of
denyhosts' daemon control script is not going to happen since I do not wish to
diverge that much from the upstream sources.
Comment 2 Rudolf Kastl 2006-04-11 09:18:23 EDT
i will fix it upstream for all distributions. init scripts that return proper
exit values and use NLS support arent fedora specific at all.

actually you can see from above example output that the script returns is the
executed command (which could be reproduced by various fc5 users aswell on
irc...) and not the exit value. Stopping the service is broken aswell.

I can attach a patch that fixes it though i am not the maintainer. You can also
leave this bug open until my upcoming fix will go upstream and leave the bug
here open to track once its fixed in fedora. thats your decision. 
Comment 3 Jason Tibbitts 2006-04-11 09:27:22 EDT
I'm still not understanding what you're calling broken.  Does the script not
start up and shut down the denyhosts daemon when asked?  It almost seems that
you're complaining about the form of the output.  Could you clarify exactly what
is broken for you?  Are you able to start the daemon at all?
Comment 4 Rudolf Kastl 2006-04-11 10:27:13 EDT
of course its about the output of the script. 

starting DenyHosts:    /usr/bin/denyhosts.py --daemon --config=/etc/denyhosts.conf

is not the intended output.

DenyHosts starten:             [OK] 

would be the optimum. atleast.

more details on nls support is here: 

so i dont have to explain it again.
Comment 5 Jason Tibbitts 2006-07-14 22:26:57 EDT
*** Bug 198966 has been marked as a duplicate of this bug. ***
Comment 6 Jason Tibbitts 2006-07-14 22:31:12 EDT
Since someone else has reported this, I will reiterate:

I do see this as a deficiency but one that is not in any way critical, and
moreover I honestly don't know how to internationalize the messages or output
them in the format used by the other initscripts.  However, I will happily
accept patches.
Comment 7 Paul Wouters 2006-09-14 18:05:47 EDT

This is a serious bug. Currently when you run "service denyhosts start", you do
not get the prompt back. Services are supposed to background. This will break my
server when i reboot because it will be hanging on denyhosts in the startup phase.

This is for version 2.5-1.fc4
Comment 8 Jason Tibbitts 2006-09-14 21:20:46 EDT
What you are seeing seems to be completely unrelated to anything else stated in
this bug.  I test denyhosts on everything from FC-2 to rawhide and have not seen
this behavior.  More information would be much appreciated.
Comment 9 Jason Tibbitts 2007-04-01 11:27:48 EDT
*** Bug 234751 has been marked as a duplicate of this bug. ***
Comment 10 Jonathan Underwood 2007-04-03 18:33:41 EDT
The current init script calls /usr/bin/denyhosts-control to start/stop denyhosts. 

denyhosts-control is a python script that quite literally contains the init
logic encapsulated in /etc/init.d/functions. This would allow denyhosts to be
properly controlled on a system without sysv init. However, Fedora has init :)
So, I've attached a patch which fixes this problem.

The patch is a minimal patch, but if you accept this, I would like to clean up
the init script and comment it properly, as it took a few minutes of figuring
out the cron/daemon logic, and that should be commented into the file. Plus the
logic could be simplified considerably.
Comment 11 Jonathan Underwood 2007-04-03 18:34:50 EDT
Created attachment 151629 [details]
Fix the start/stop/restart etc init functions to behave properly
Comment 12 Jonathan Underwood 2007-04-04 13:42:05 EDT
Created attachment 151682 [details]
Updated patch

Updated patch to /etc/init.d/denyhosts which fixes the missing "status"
operation, and general cleanups for readability and maintainability.
Comment 13 Jonathan Underwood 2007-04-17 07:09:42 EDT
Comment 14 Jason Tibbitts 2007-04-17 11:54:16 EDT
I'm not really sure what "Bump" is supposed to mean, but we're in feature freeze
and I'm not going to go breaking the init stuff that works perfectly well as it
is just a couple of weeks before we release.

Once the tree branches and we have a "devel" to play in that's really for
development, then I'll take a look at this.
Comment 15 Jonathan Underwood 2007-05-02 05:37:55 EDT
Sorry, the "Bump" wasn't a demand for a new package including the fix. I was
interested to know if you're happy with this approach, or whether you think it
is still preferable to be calling denyhosts-control from within the init file. I
have an alternative patch, if the latter approach is more desireable. 

[But, yes, "Bump" rather over abbreviates that intent, clearly you need to work
on your mind reading skills ;)]
Comment 16 Jason Tibbitts 2007-05-02 11:10:14 EDT
The only real issue with not calling into the control script that I can see is
that currently upstream has the flexibility to change how the daemon expects to
be called and then encapsulate those changes within the control script so that
nothing is visible outside of the package.

Frankly I think that's not much of an issue, since:

1) They can't change too much because calling denyhosts.py directly is expected
usage in many situations.

2) The only argument that gets passed currently is --config.

3) Upstream is essentially dormant at the moment, so I'm not really expecting
significant changes.

In any case, denyhosts-control is simple enough that picking up any changes
should be trivial.  I may make the srpm checksum it just to ensure that any
changes don't get missed.  The only blocker at the moment is the bewildering
refusal of the people managing the repos to actually give us a branch for F7 so
that development can continue without mucking up the release.
Comment 17 Jason Tibbitts 2007-08-24 15:23:08 EDT
I believe this should all be fixed in rawhide now.

Unfortunately Jonathan's patch didn't quite work; it didn't successfully stop a
denyhosts instance which was started with the old initscript.  I believe I've
worked around that, although it took me way longer than I'd hoped especially
given how simple the fix is.  Oh, well.

In any case, an updated version is built in rawhide and should appear on the
mirrors soon.

Note You need to log in before you can comment on or make changes to this bug.