Bug 430877 - 'service sshd status' is broken
Summary: 'service sshd status' is broken
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh   
(Show other bugs)
Version: 5.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 430882 479838
TreeView+ depends on / blocked
 
Reported: 2008-01-30 12:05 UTC by Issue Tracker
Modified: 2018-10-20 00:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 479838 (view as bug list)
Environment:
Last Closed: 2009-01-20 22:03:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0209 normal SHIPPED_LIVE openssh bug fix and enhancement update 2009-01-20 16:06:15 UTC

Description Issue Tracker 2008-01-30 12:05:22 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2008-01-30 12:05:24 UTC
1. Provide clear and concise problem description as it is understood at the time of escalation

The command "service sshd status" does not tell whether the sshd service is running.  Instead it tells whether there are any sshd processes in the process table. 
 
It happens on both RHEL 5.1 and RHEL 4.6 (and, presumably, everything in between). 
 
For example: 
# /etc/init.d/sshd stop 
Stopping sshd:                                             [  OK  ] 
# service sshd status 
sshd (pid 26595 26593) is running... 
# ps -ef | grep ssh 
root     18430 18065  0 08:53 pts/1    00:00:00 grep --color ssh 
root     26593     1  0 Jan03 ?        00:00:00 sshd: happy [priv] 
happy    26595 26593  0 Jan03 ?        00:00:02 sshd: happy@pts/0

We know that no new connections will be accepted with this status but the status function should report that service is stopped.
 
2. State specific action requested of SEG

As the status function is generic to all the init scripts and I agree that it can't be modified for a single script. However the additional functionally can be added.

3. Additional info

This seems to be a limitation of using a common/generic "status" function via /etc/init.d/functions. The status function should also check /var/run/SERVICE.pid file or /var/lock/subsys/SERVICE, in this case /var/run/sshd.pid or /var/lock/subsys/sshd

This should be more reliable, though can never be 100% accurate in representing the service status. We also understand that not all services would actually create these (pid file) upon startup hence the "status" function primarily checks for running processes.

Also changing the behavior of the generic function could have cascading impact on all services using it.
This event sent from IssueTracker by mpoole  [Support Engineering Group]
 issue 161096

Comment 2 Martin Poole 2008-01-30 12:32:21 UTC
Simple enough to fix,


--- sshd.orig   2008-01-30 12:11:47.000000000 +0000
+++ sshd        2008-01-30 12:31:03.000000000 +0000
@@ -170,7 +170,7 @@
                fi
                ;;
        status)
-               status $SSHD
+               status -p $PID_FILE $SSHD
                RETVAL=$?
                ;;
        *)



Comment 3 Tomas Mraz 2008-01-30 13:00:27 UTC
Martin, this patch doesn't work. The -p option of status just adds another pid
file to be searched but it still does pidof $SSHD first.

Unfortunately I don't see any way how to fix this bug and not make it wrong in
other cases where the current code is fine.

Also it is questionable what the status option of the init script should really
report.


Comment 4 Martin Poole 2008-01-30 13:26:47 UTC
My apologies. I hadn't synchronised events between test windows properly.

The correct behaviour is to report whether there is a daemon performing the
initial accepts on the port.

It is perfectly possible to fix this and not break any other cases.

In fact simply changing the status check to 

  status -p $PID_FILE

actually produces the correct sort of return code. Although the message is not
quite as clear.


Comment 5 Tomas Mraz 2008-01-30 16:04:17 UTC
OK, then something like:
status -p $PID_FILE openssh-daemon

works probably best although I still don't think that it is 100% correct.
Clearly I can do this change in Rawhide and see if there will be any bad
side-effect.


Comment 7 RHEL Product and Program Management 2008-06-02 20:20:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 14 errata-xmlrpc 2009-01-20 22:03:16 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0209.html


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