From: Guillaume Dargaud on
Helo all,
I've been having a very annoying problem lately. I have konsole opened with
many tabs were scripts or executables are running, some within ssh sessions,
some are command line, others do open X windows.
And sometimes a session will lock up for no reason. If it's text-only, I can
press [Scroll lock] and it will resume; but if it's opened some X windows I
haven't found a way to getting it back besides closing the tab.

I don't know if this is due to something I'm doing in my scripts (send
SIGSTOP traps to the wrong places ?!? I don't do anything like that) or
something totally unrelated.

There's at least one case where I can trigger it every time: a script does
some
ssh user(a)somewhere "/etc/init.d/someservice restart"
With set -x in the script I can see it hanging on the above line, when in
reality the entire script is already finished.

Any pointers are welcome.
--
Guillaume Dargaud
http://www.gdargaud.net/


From: Geoff Clare on
Guillaume Dargaud wrote:

> ssh user(a)somewhere "/etc/init.d/someservice restart"
> With set -x in the script I can see it hanging on the above line, when in
> reality the entire script is already finished.

The usual reason this happens is that the remote command started
a background process that still has the inherited stdout or stderr
open. It's surprising that a background process started from an
/etc/init.d script would not properly daemonize itself (which
includes reopening stdout and stderr to either /dev/null or a
log file), so maybe that isn't the problem. See if this cures it:

ssh user(a)somewhere "/etc/init.d/someservice restart >/dev/null 2>&1"

If it does, then you've found the problem, but this isn't really
suitable as a proper fix because it throws away any error messages
from the init.d script.

--
Geoff Clare <netnews(a)gclare.org.uk>

From: Chad on
On Jun 22, 5:41 am, Geoff Clare <ge...(a)clare.See-My-Signature.invalid>
wrote:
> Guillaume Dargaud wrote:
> > ssh user(a)somewhere "/etc/init.d/someservice restart"
> > With set -x in the script I can see it hanging on the above line, when in
> > reality the entire script is already finished.
>
> The usual reason this happens is that the remote command started
> a background process that still has the inherited stdout or stderr
> open.  It's surprising that a background process started from an
> /etc/init.d script would not properly daemonize itself (which
> includes reopening stdout and stderr to either /dev/null or a
> log file), so maybe that isn't the problem.  See if this cures it:
>
>  ssh user(a)somewhere "/etc/init.d/someservice restart >/dev/null 2>&1"
>
> If it does, then you've found the problem, but this isn't really
> suitable as a proper fix because it throws away any error messages
> from the init.d script.
>
> --

Why would stdout or stderr possibly cause the program(?) to "hang"?
From: Geoff Clare on
Chad wrote:

> On Jun 22, 5:41�am, Geoff Clare <ge...(a)clare.See-My-Signature.invalid>
> wrote:
>> Guillaume Dargaud wrote:
>> > ssh user(a)somewhere "/etc/init.d/someservice restart"
>> > With set -x in the script I can see it hanging on the above line, when in
>> > reality the entire script is already finished.
>>
>> The usual reason this happens is that the remote command started
>> a background process that still has the inherited stdout or stderr
>> open. �It's surprising that a background process started from an
>> /etc/init.d script would not properly daemonize itself (which
>> includes reopening stdout and stderr to either /dev/null or a
>> log file), so maybe that isn't the problem. �See if this cures it:
>>
>> �ssh user(a)somewhere "/etc/init.d/someservice restart >/dev/null 2>&1"
>>
>> If it does, then you've found the problem, but this isn't really
>> suitable as a proper fix because it throws away any error messages
>> from the init.d script.
>
> Why would stdout or stderr possibly cause the program(?) to "hang"?

It is ssh that "hangs". It copies whatever is written to stdout and
stderr on the remote system to the local system. It won't see EOF
on those streams until they are no longer open in any processes on the
remote system.

--
Geoff Clare <netnews(a)gclare.org.uk>