Bug 852962

Summary: SSHD started way too late, and stopped too soon
Product: Red Hat Enterprise Linux 6 Reporter: matthew patton <pattonme>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.3   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-03 14:50:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description matthew patton 2012-08-30 06:05:58 UTC
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 14:50:45 UTC
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.