Bug 852962 - SSHD started way too late, and stopped too soon
SSHD started way too late, and stopped too soon
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh (Show other bugs)
6.3
Unspecified Linux
unspecified Severity low
: rc
: ---
Assigned To: Petr Lautrbach
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-30 02:05 EDT by matthew patton
Modified: 2012-09-03 10:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-03 10:50:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description matthew patton 2012-08-30 02:05:58 EDT
Description of problem:

The start order of SSHd is way late and is killed too early when booting/shutting down a system. currently it's '55 25' it should be something akin to '15 85'. There are many needless things ahead of SSHd; In particular the frightfully unreliable cluster daemons like cman and clvmd. On shutdown, again we have the badly behaved cluster subsystems, gfs2 etc. that have a nasty tendency to just hang forever. With SSHd long dead there is no recourse except to resort to fencing or other brutal methods when sshd should still and can be an option.

Yes, I'm aware of bug 494937, but talk about a pitiful hack. Nor did it deal with shutdown problems. Clustering is like NFSd, it is a system ADD-ON, not a core function like SSHd.

[ aside: cman and clvmd properly belong at level=3. Just imagine the fun when the cluster tries to start at runlevel=2 (the current wrong-headed default) and all kinds of block devices (eg. iscsi) aren't available. Doesn't anybody bother to sanity-check runlevels anymore? ]

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

How reproducible:
every time

Steps to Reproduce:
1. boot/shutdown the system
  
Actual results:
SSHd not started right after network. SSHd shut down while a multitude of network related processes are still open and some are well known to hang forever.

Expected results:

SSHd should be available as soon as the network is up and turned off right before the network is torn down.

Additional info:
Comment 2 Petr Lautrbach 2012-09-03 10:50:45 EDT
I'm afraid that we can't change default this values during this period of the release cycle. But you can do a simple local workaround using a chkconfig ovveride file, see chkconfig(8):

# ls /etc/rc.d/rc3.d/S*sshd
/etc/rc.d/rc3.d/S55sshd
# echo '# chkconfig: 2345 15 85' > /etc/chkconfig.d/sshd
# chkconfig --del sshd && chkconfig --add sshd
# ls /etc/rc.d/rc3.d/S*sshd
/etc/rc.d/rc3.d/S15sshd


> 
> [ aside: cman and clvmd properly belong at level=3. Just imagine the fun
> when the cluster tries to start at runlevel=2 (the current wrong-headed
> default) and all kinds of block devices (eg. iscsi) aren't available.
> Doesn't anybody bother to sanity-check runlevels anymore? ]

I'm not sure what do you mean. Both cman and clvmd have chkconfig comments like:
# chkconfig: - 24 76

what means that this services are disabled by default and it's up to an administrator to enable them in the right runlevels.

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