RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 852962 - SSHD started way too late, and stopped too soon
Summary: SSHD started way too late, and stopped too soon
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh
Version: 6.3
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Petr Lautrbach
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-30 06:05 UTC by matthew patton
Modified: 2012-09-03 14:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-03 14:50:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.