Prev: substitution for octal chars
Next: Team Red Bull Hats ( www.nike-black.com )
From: Guillaume Dargaud on 8 Jul 2010 07:39
Hello all,
How can I launch something via ssh and not wait for it to finish ?

OK, in more details, consider the following daemon Loop.sh:
#! /bin/bash
while true; do echo -n "."; sleep 1; done

And the following init.d script for it (InitLoop.sh):
#! /bin/bash
case "$1" in
start)
echo "Starting"
~/bin/Loop.sh &
;;
stop)
if killall -q Loop.sh; then
echo "Stopping"
fi
;;
status)
pgrep -l Loop.sh | grep -v InitLoop
;;
restart)
$0 stop
sleep 2 # Forces watchdog reboot
$0 start
;;
esac


So, if I do
$ InitLoop.sh restart
......
I get the dots as expected.

Now from a remote machine if I do
$ ssh MySystem "InitLoop.sh restart"
.......
ssh doesn't return.

I would like the dots to go to /dev/null and ssh to return after
launching the command. Ideally I would like to see 'Starting'
'stopping' always, but to see the dots only when doing an interactive
execution (not from ssh).
I've tried variations like
$ ssh MySystem "nohup InitLoop.sh restart >/dev/null &"

How can I detect interactive execution from the init.d script ?
Thanks
--
Guillaume Dargaud
http://www.gdargaud.net/
From: Dominic Fandrey on 8 Jul 2010 21:49
On 08/07/2010 13:39, Guillaume Dargaud wrote:
> Hello all,
> How can I launch something via ssh and not wait for it to finish ?
> Now from a remote machine if I do
> $ ssh MySystem "InitLoop.sh restart"
> ......
> ssh doesn't return.
>

Apparently ssh waits until all connections to stdin (from the
ssh perspective) are closed. With an interactive shell
the stdout of all child processes is connected to the shell,
which maintains a single connection to the terminal (let's
forget about stderr here).
So when the shell terminates that means all connections to the
stdin of the ssh session are closed.
Without a shell all children are directly connected so the
ssh session is forced to stay around.

>
> How can I detect interactive execution from the init.d script ?

I don't think it's a good idea to make this kind of distinction.

Instead simply close the stdout while forking:

ssh MySystem "InitLoop.sh restart >&-"

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Guillaume Dargaud on 9 Jul 2010 03:32

> Instead simply close the stdout while forking:
> ssh MySystem "InitLoop.sh restart >&-"

I had more or less figured out the stdin argument, but you make things
clearer. I'd never seen the >&- syntax before.
My workaround was to have a 'start' that would all go to /dev/null and
background and a 'fg' option that would leave it in the foreground and print
the dots.
I'll try it, thanks.
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
From: Geoff Clare on 9 Jul 2010 08:36
Dominic Fandrey wrote:

> Instead simply close the stdout while forking:
>
> ssh MySystem "InitLoop.sh restart >&-"

It's a bad idea to execute any program with stdin, stdout or stderr
closed (unless you know that this specific program has been designed
to allow it). Instead you should redirect them to or from /dev/null.

For programs that haven't been designed to cope with it, if you close
stdout and the program tries to write to stdout it will either:

1. get an EBADF error which may cause it to exit with an error message

2. write information meant for stdout to some other file that it opened
(which got assigned file descriptor 1 as the lowest available),
possibly corrupting that file.

There are similar problems with closing stdin or stderr.

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

 | 
Pages: 1
Prev: substitution for octal chars
Next: Team Red Bull Hats ( www.nike-black.com )