Bug 30508 - service xxx restart hangs openssh sessions at logout
service xxx restart hangs openssh sessions at logout
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
7.1
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Bill Nottingham
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-03 20:01 EST by Pekka Savola
Modified: 2014-03-16 22:19 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-05 16:42:55 EST
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 Pekka Savola 2001-03-03 20:01:29 EST
See #19837.  The problem is now back along with OpenSSH-2.5.1p1.  It's 
unfortunately long-lived and probably won't be solved for RHL71.

The problem is:

host1 $ ssh root@otherhost
host2 # service httpd restart
host2 # logout
[hangs forever!]

This is caused by the OpenSSH bug (also see openssh-closing.txt in openssh package), 
BUT IMHO, if at all possible, it'd be VERY nice if initscripts service start/stop mechanisms
could be altered so that it doesn't leave some child processes running, making openssh hang.

If this kind of work-around could be used, the IMO _worst_ problem with openssh sessions hanging
could be averted.

IMO, 'service httpd restart' problem _has_ to be worked around _somehow_ before final release.  Plain old
'sleep 20& exit' (which will only hang for 20 secs, not forever!) can be left in.
Comment 1 Pekka Savola 2001-03-03 20:02:37 EST
Err, meant to put this in initscripts component.
Comment 2 Bill Nottingham 2001-03-05 12:17:56 EST
This works fine for me here, openssh-2.5.1-p1 on both ends.
Comment 3 Pekka Savola 2001-03-05 12:56:23 EST
Script started on Mon Mar  5 19:52:31 2001
[psavola@haukka psavola]$ ssh root@mistress
root@mistress's password: 
Last login: Mon Mar  5 16:42:07 2001
[root@mistress /root]# rpm -q initscripts openssh
initscripts-5.69-1
openssh-2.5.1p1-5
[root@mistress /root]# /sbin/service radvd restart
Stopping radvd:                                            [  OK  ]
Starting radvd:                                            [  OK  ]
[root@mistress /root]# exit
 [ -- HANGS -- ]
Script done on Mon Mar  5 19:54:19 2001

[slight editing to cut out clear screen]
Comment 4 Pekka Savola 2001-03-05 12:57:55 EST
Can you replicate it with this?  You use 'UseLogin no' probably?

mistress is RC1 system, haukka RHL7.
Comment 5 Bill Nottingham 2001-03-05 15:16:10 EST
That's not httpd. :P

radvd needs to close its stdin in the child.
Comment 6 Pekka Savola 2001-03-05 15:26:54 EST
There is no generic solution? Oh the pain.  Is this a program or init.d/xxx script problem? 

Has anyone checked which base|powertools packages are borked and which not?
Comment 7 Bill Nottingham 2001-03-05 15:43:49 EST
Well, daemon() can't really redirect input from /dev/null, as that's going
to break *something*, I'm sure.

radvd is rather broken in that it doesn't close its filedescriptors,
chdir, etc. (If someone managed to break it, they could in theory read
whatever from the pty of whomever started it.)

You could certainly edit the radvd initscript to redirect input 
from /dev/null (as it stands, it also has stdout and stderr connected
to broken pipes...)

It's still a little odd in that ssh won't close the connection just because
something has that fd open, though.
Comment 8 Pekka Savola 2001-03-05 16:28:26 EST
Bah.  This should be ok for now (works for me)?

--- radvd-0.6.2/radvd.c Sun Dec 24 00:50:10 2000
+++ radvd-0.6.2.mod/radvd.c     Mon Mar  5 23:22:39 2001
@@ -161,6 +161,10 @@
         * lets fork now...
         */
 
+       /* Detach from controlling terminal */
+       if (daemon(0, 0) < 0)
+               perror("daemon");
+
        if (get_debuglevel() == 0) {

                switch (fork()) {

If so, I'll close this and mail this to timp@.

-- still -- I wonder how many other broken daemons are still out there..
Comment 9 Bill Nottingham 2001-03-05 16:42:50 EST
Looks good, you could either do it before or after the fork(), I suppose.
(when I did a quick check, I just put close(0,1,2,3) after the fork(),
but it should work either way.
Comment 10 Pekka Savola 2001-03-05 16:47:02 EST
This daemon would appear to be easily setuid'able (after getting the socket) for security
considerations.  Well, that is a thing for the future.

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