Bug 30508 - service xxx restart hangs openssh sessions at logout
Summary: service xxx restart hangs openssh sessions at logout
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-04 01:01 UTC by Pekka Savola
Modified: 2014-03-17 02:19 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2001-03-05 21:42:55 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2001:049 normal SHIPPED_LIVE New radvd packages are available 2001-04-16 04:00:00 UTC

Description Pekka Savola 2001-03-04 01:01:29 UTC
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-04 01:02:37 UTC
Err, meant to put this in initscripts component.

Comment 2 Bill Nottingham 2001-03-05 17:17:56 UTC
This works fine for me here, openssh-2.5.1-p1 on both ends.

Comment 3 Pekka Savola 2001-03-05 17:56:23 UTC
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
[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 17:57:55 UTC
Can you replicate it with this?  You use 'UseLogin no' probably?

mistress is RC1 system, haukka RHL7.

Comment 5 Bill Nottingham 2001-03-05 20:16:10 UTC
That's not httpd. :P

radvd needs to close its stdin in the child.

Comment 6 Pekka Savola 2001-03-05 20:26:54 UTC
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 20:43:49 UTC
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 21:28:26 UTC
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 21:42:50 UTC
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 21:47:02 UTC
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.