Bug 30508

Summary:	service xxx restart hangs openssh sessions at logout
Product:	[Retired] Red Hat Linux	Reporter:	Pekka Savola <pekkas>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	7.1	CC:	nalin, rvokal
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-03-05 21:42:55 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 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
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 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.