-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm having a similar problem with hung exits.  In my case:

1       a local script is connecting remotely to a system running OpenSSH 2.5.2p2
2       the script loops through remote systems and executes a remote rpm -Uhv
3       the rpm package has a post install script.
4       the post script calls a second script followed by...
5       /etc/rc.d/init.d/httpd restart.

6       At this point the session locks up,
        and in turn the script locks up and will not ^C out.

7       Usually I have to relogin and kill off the local script

My question is:
1.      Will this stdout workaround apply in this case?
2.      If so, should I redirect the commands in the post install script?
3.      or should I redirect the rpm command's stdout?

In my case it is important to see the output from rpm as it happens to
watch for errors as my web application is upgraded across my server farm.
Are there other issues that would cause this to only happen intermittently?
If so, what would be an alternative workaround?

On Wednesday 25 April 2001 08:06, you wrote:
> On Tue, Apr 24, 2001 at 03:29:42PM -0700, Kevin O'Brien wrote:
> > We've noticed the problem since 2.3 came out.  I've sent in a couple
> > messages and no one seems to acknowledge it's existence.
> >
> > -----Original Message-----
> > From: David Cress [mailto:[EMAIL PROTECTED]]
> >
> > If I ssh to a system, start a job that forks off, and try and exit, my
> > connection hangs, i.e.
>
> Oh, this problem is definitely real, at least on some platforms.  I
> get it with HP-UX 10.20 as well.  (With HP-UX 9.05, there are much
> worse problems, but fortunately I won't be running 9.05 much longer.)
>
> The only workaround I've found for it is to launch your background
> jobs with stdout and stderr redirected.  A simple jobs hangs:
>
>   imadev:~$ ssh vandev 'sleep 60 &'
>   wooledg@vandev's password:
>   Killed by signal 15.
>   imadev:~$
>
> But if I run it with redirection, it returns control to the local system
> before the sleep finishes:
>
>   imadev:~$ ssh vandev 'sleep 60 >/dev/null 2>&1 &'
>   wooledg@vandev's password:
>   imadev:~$ ssh vandev 'ps -fu wooledg | grep sleep'
>   wooledg@vandev's password:
>    wooledg 16061     1  0 07:57:59 ?         0:00 sleep 60
>    wooledg 16064 16062 12 07:58:30 ?         0:00 grep sleep
>   imadev:~$
>
> And in fact, I don't even need to redirect stderr; stdout alone is OK:
>
>   imadev:~$ ssh vandev 'sleep 60 >/dev/null &'
>   wooledg@vandev's password:
>   imadev:~$
>
> But if I just redirect stderr and not stdout, it hangs:
>
>   imadev:~$ ssh vandev 'sleep 60 2>/dev/null &'
>   wooledg@vandev's password:
>   Killed by signal 15.
>   imadev:~$
>
> I've tried with nohup as well, and that appears to make no difference
> either way -- "nohup sleep 60 &" hangs, while "nohup sleep 60 >/dev/null
> 2>&1 &" does not.
>
> So, it would seem that if the process that's launched on the remote
> system holds stdout open, the sshd child won't close the connection.

- -- 
Thomas Kreeger
Matchmaker Production Support Analyst
Phone: (781)-370-3497
Cell: (781)-760-4262
Email: [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBOucbdPwNQdQxzrC+EQKl6ACgvct+I0V5mlPSD3W0LqfRAKNakeEAniYz
lxEHmbMcUgCqBKu8q/BjDFgs
=+zXd
-----END PGP SIGNATURE-----

Reply via email to