Bug 123213 - glibc RPM update restarts sshd even if not desired in the current runlevel
glibc RPM update restarts sshd even if not desired in the current runlevel
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-13 16:55 EDT by Valdis Kletnieks
Modified: 2008-05-09 13:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-13 17:24:04 EDT
Type: ---
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 Valdis Kletnieks 2004-05-13 16:55:43 EDT
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 17:05:05 EDT
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 17:24:04 EDT
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...

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