Bug 123213

Summary: glibc RPM update restarts sshd even if not desired in the current runlevel
Product: [Fedora] Fedora Reporter: Valdis Kletnieks <valdis.kletnieks>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-05-13 21:24:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Valdis Kletnieks 2004-05-13 20:55:43 UTC 
Description of problem: The postinstall of the glibc RPM runs
/usr/sbin/glibc_post_upgrade, which invokes "/sbin/service" to restart
ssh, even if ssh isn't set to run in the current runlevel.


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

How reproducible:
Upgrade glibc in a runlevel that ssh shouldn't be running in.

Steps to Reproduce:
1. chkconfig --level 5 sshd off
2. /etc/init.d/sshd stop
3. telinit 5
4. ps ax, etc to see no sshd running
5. rpm -Fvh glibc
6. See that sshd has been restarted even though you don't want it.
  
Actual results:
You have a running sshd


Expected results:
No sshd started

Additional info:
This can be a problem for sites that (for instance) configure a
runlevel 4 to be a special "mostly down" for system maintenance - the
glibc RPM can potentially get people get access to the machine before
you're ready.  Similar issues apply for any other case where for some
policy/security/technical reason, you want sshd *not* running just
then....
Comment 1 Jakub Jelinek 2004-05-13 21:05:05 UTC 
glibc_post_upgrade calls
/sbin/service sshd condrestart
and not restart.
condrestart restarts sshd only if /var/lock/subsys/sshd exists
(i.e. sshd service is supposed to be running).
So I wonder what's happening on your box.
I certainly tried /sbin/service sshd stop; /usr/sbin/glibc_post_upgrade
on my box and sshd has not been started (as expected).
Comment 2 Valdis Kletnieks 2004-05-13 21:24:04 UTC 
Apparently my system is on crack or something, I just re-tried it:

[/root]4 ls -l /var/lock/subsys/sshd
ls: /var/lock/subsys/sshd: No such file or directory
[/root]4 ps ax|grep sshd
11399 pts/10   S      0:00 grep sshd

[/root]4 rpm -Uvh --force /usr/src/valdis/fedora/glibc-2.3.3-27.i686.rpm 
Preparing...               
########################################### [100%]
   1:glibc                 
########################################### [100%]
Starting sshd:  [  OK  ]
[/root]4 ls -l /etc/rc*.d/*ssh*
ls: /etc/rc*.d/*ssh*: No such file or directory
[/root]4 ls -l /var/lock/subsys/sshd
ls: /var/lock/subsys/sshd: No such file or directory
[/root]4 ps ax|grep sshd
21988 ?        S      0:00 /usr/sbin/sshd
28433 pts/10   S      0:00 grep sshd
[/root]4 

OK.. I found the crack pipe.  What was happening was that rpm was
invoking glibc_post_upgrade, which launched /sbin/service - that then
blindly did a "/etc/init.d/sshd condrestart".  Due to a screw-up in
THAT script "condrestart" fell through and hit "restart".

I need to figure out how/when that init.d script gor b0rked...Am
closing this one as 'NOTABUG' while I chase my sshd issue...