Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Tcl catch exec hangs when executing a ssh command with pipe
1,797 views
Skip to first unread message
Adriana
May 3, 2012, 5:57:10 AM5/3/12
to
Hello,
I am stuck on a problem and I think that tcl/tk gurus could help me.
I am launching the following command:
if { [catch {exec "ssh" "$user@machine" "-2" "nohup myprogram 2>&1 | ./
log &"} msg] } {
puts "$msg"
}
where myprogram is a program that should continuously run and output
text.
It happens that the pipe in the ssh command makes the catch not
return.
This must be a known problem.
Does anyone know how to overcome it?
Thanks in advance.
Adriana
I am stuck on a problem and I think that tcl/tk gurus could help me.
I am launching the following command:
if { [catch {exec "ssh" "$user@machine" "-2" "nohup myprogram 2>&1 | ./
log &"} msg] } {
puts "$msg"
}
where myprogram is a program that should continuously run and output
text.
It happens that the pipe in the ssh command makes the catch not
return.
This must be a known problem.
Does anyone know how to overcome it?
Thanks in advance.
Adriana
Uwe Klein
May 3, 2012, 6:25:20 AM5/3/12
to
exec doesn't see the "&" it is obscured by " ... "
manual says:
If the last arg is ``&'' then the pipeline will be exe-
cuted in background.
try:
catch { exec -- ssh $user@machine -2 nohup myprogram |& ./log & } msg]
uwe
Robert Heller
May 3, 2012, 6:38:00 AM5/3/12
to
Are your sure you have dealth with known hosts and ssh keys? Eg
ssh is not asking questions of one sort or another?
Have you considered using open (with a pipe) and fileevent
instead of exec? Eg:
global pipe
set pipe [open "|ssh $user@machine -2 nohup myprogram 2>&1 | ./log" r]
fileevent $pipe readable [list readpipe]
proc readpipe {} {
global pipe
if {[gets $pipe line] < 0} {
if {[catch {close $pipe} msg]} {
puts "pipe closed: $msg"
}
set pipe {}
} elseif {[eof $pipe]} {
if {[catch {close $pipe} msg]} {
puts "pipe closed: $msg"
}
set pipe {}
} else {
puts $line
}
}
vwait pipe
> Thanks in advance.
> Adriana
>
--
Robert Heller -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
Uwe Klein
May 3, 2012, 6:50:49 AM5/3/12
to
Uwe Klein wrote:
> try:
> catch { exec -- ssh $user@machine -2 nohup myprogram |& ./log & } msg]
>
forget this.
> try:
> catch { exec -- ssh $user@machine -2 nohup myprogram |& ./log & } msg]
>
a misunderstanding on my side.
uwe
Adriana
May 3, 2012, 7:24:29 AM5/3/12
to
Hello,
thanks for your answer.
ssh, when launched from terminal, exit well and send the command in
background. authorized keys have been configured accordingly.
I have tried opening a pipe instead of using exec and it actually
returns but then leave the pipe open. I wouldn't like this cause the
program should be launched and should continue running on the machine
without the Tcl application worrying about it anymore.
There must be a way of telling Tcl to treat the pipe like in bash.
Isn't it?
On May 3, 12:38 pm, Robert Heller <hel...@deepsoft.com> wrote:
> Deepwoods Software --http://www.deepsoft.com/
thanks for your answer.
ssh, when launched from terminal, exit well and send the command in
background. authorized keys have been configured accordingly.
I have tried opening a pipe instead of using exec and it actually
returns but then leave the pipe open. I wouldn't like this cause the
program should be launched and should continue running on the machine
without the Tcl application worrying about it anymore.
There must be a way of telling Tcl to treat the pipe like in bash.
Isn't it?
On May 3, 12:38 pm, Robert Heller <hel...@deepsoft.com> wrote:
Shaun Deacon
May 3, 2012, 12:43:33 PM5/3/12
to
On May 3, 4:24 am, Adriana <adriana.tele...@gmail.com> wrote:
> Hello,
> thanks for your answer.
> ssh, when launched from terminal, exit well and send the command in
> background. authorized keys have been configured accordingly.
> I have tried opening a pipe instead of using exec and it actually
> returns but then leave the pipe open. I wouldn't like this cause the
> program should be launched and should continue running on the machine
> without the Tcl application worrying about it anymore.
> There must be a way of telling Tcl to treat the pipe like in bash.
> Isn't it?
Maybe you want to redirect to the log rather than pipe. The following
> Hello,
> thanks for your answer.
> ssh, when launched from terminal, exit well and send the command in
> background. authorized keys have been configured accordingly.
> I have tried opening a pipe instead of using exec and it actually
> returns but then leave the pipe open. I wouldn't like this cause the
> program should be launched and should continue running on the machine
> without the Tcl application worrying about it anymore.
> There must be a way of telling Tcl to treat the pipe like in bash.
> Isn't it?
works OK for me :
if { [catch {exec ssh user@machine "uname -a" 2>&1 > ./log &} err] } {
puts "ERROR: $err"
} else {
puts "OK"
}
where the result of 'uname -a' is written to the log
best regards
Shaun
Adriana
May 3, 2012, 5:28:53 PM5/3/12
to
output of the piped command and shows it in a particular format on a
graphical interface. Redirecting via ">" does not work for me.
Even creating a bash script executing the command and executing the
script in the Tcl application makes the Tcl app hang until the command
launched stops.
I don't know how to solve this problem. It is a Tcl behavior that
should have a work around...
Eric
May 3, 2012, 6:47:30 PM5/3/12
to
"If standard output has not been redirected then the exec command
returns the standard output from the last command in the pipeline..."
which is ./log in your case. The standard output of ./log (on the
remote machine) is provided by ssh which connects it to the local
machine where it is connected to the tcl exec command which waits
patiently for it to be closed so that exec can return the contents!
And catch, of course, waits for exec to complete. So there is nothing
wrong whatsoever, and all the software is doing what it is supposed to.
All you have to do is close the standard output of ./log , so instead of
| ./log &
you need
| ./log >/dev/null &
and then it will do what you expect.
Eric
--
ms fnd in a lbry
Robert Heller
May 3, 2012, 7:25:09 PM5/3/12
to
At Thu, 3 May 2012 14:28:53 -0700 (PDT) Adriana <adriana...@gmail.com> wrote:
>
> On May 3, 6:43=A0pm, Shaun Deacon <shaun.dea...@us.fujitsu.com> wrote:
> >
> > } else {
> > =A0 =A0 puts "OK"
as well. Maybe you need to look at the -f and -n options to ssh (from
man ssh):
-f Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background. This
implies -n. The recommended way to start X11 programs at a
remote site is with something like ssh -f host xterm.
-n Redirects stdin from /dev/null (actually, prevents reading from
stdin). This must be used when ssh is run in the background. A
common trick is to use this to run X11 programs on a remote
machine. For example, ssh -n shadows.cs.hut.fi emacs & will
start an emacs on shadows.cs.hut.fi, and the X11 connection will
be automatically forwarded over an encrypted channel. The ssh
program will be put in the background. (This does not work if
ssh needs to ask for a password or passphrase; see also the -f
option.)
Deepwoods Software -- http://www.deepsoft.com/
>
> On May 3, 6:43=A0pm, Shaun Deacon <shaun.dea...@us.fujitsu.com> wrote:
> > On May 3, 4:24=A0am, Adriana <adriana.tele...@gmail.com> wrote:
> >
> > > Hello,
> > > thanks for your answer.
> > > ssh, when launched from terminal, exit well and send the command in
> > > background. authorized keys have been configured accordingly.
> > > I have tried opening a pipe instead of using exec and it actually
> > > returns but then leave the pipe open. I wouldn't like this cause the
> > > program should be launched and should continue running on the machine
> > > without the Tcl application worrying about it anymore.
> > > There must be a way of telling Tcl to treat the pipe like in bash.
> > > Isn't it?
> >
> > Maybe you want to redirect to the log rather than pipe. The following
> > works OK for me :
> >
> > if { [catch {exec ssh user@machine "uname -a" 2>&1 > ./log &} err] } {
> > =A0 =A0 puts "ERROR: $err"
> >
> > > Hello,
> > > thanks for your answer.
> > > ssh, when launched from terminal, exit well and send the command in
> > > background. authorized keys have been configured accordingly.
> > > I have tried opening a pipe instead of using exec and it actually
> > > returns but then leave the pipe open. I wouldn't like this cause the
> > > program should be launched and should continue running on the machine
> > > without the Tcl application worrying about it anymore.
> > > There must be a way of telling Tcl to treat the pipe like in bash.
> > > Isn't it?
> >
> > Maybe you want to redirect to the log rather than pipe. The following
> > works OK for me :
> >
> > if { [catch {exec ssh user@machine "uname -a" 2>&1 > ./log &} err] } {
> >
> > } else {
> > =A0 =A0 puts "OK"
> > }
> >
> > where the result of 'uname -a' is written to the log
> >
> > best regards
> > Shaun
>
> The problem is that ./log is not a file but a program that takes the
> output of the piped command and shows it in a particular format on a
> graphical interface. Redirecting via ">" does not work for me.
> Even creating a bash script executing the command and executing the
> script in the Tcl application makes the Tcl app hang until the command
> launched stops.
> I don't know how to solve this problem. It is a Tcl behavior that
> should have a work around...
Does the application read from stdin? Maybe you need to redirect stdin
> >
> > where the result of 'uname -a' is written to the log
> >
> > best regards
> > Shaun
>
> The problem is that ./log is not a file but a program that takes the
> output of the piped command and shows it in a particular format on a
> graphical interface. Redirecting via ">" does not work for me.
> Even creating a bash script executing the command and executing the
> script in the Tcl application makes the Tcl app hang until the command
> launched stops.
> I don't know how to solve this problem. It is a Tcl behavior that
> should have a work around...
as well. Maybe you need to look at the -f and -n options to ssh (from
man ssh):
-f Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background. This
implies -n. The recommended way to start X11 programs at a
remote site is with something like ssh -f host xterm.
-n Redirects stdin from /dev/null (actually, prevents reading from
stdin). This must be used when ssh is run in the background. A
common trick is to use this to run X11 programs on a remote
machine. For example, ssh -n shadows.cs.hut.fi emacs & will
start an emacs on shadows.cs.hut.fi, and the X11 connection will
be automatically forwarded over an encrypted channel. The ssh
program will be put in the background. (This does not work if
ssh needs to ask for a password or passphrase; see also the -f
option.)
Deepwoods Software -- http://www.deepsoft.com/
M. Strobel
May 4, 2012, 4:03:17 AM5/4/12
to
Am 03.05.2012 23:28, schrieb Adriana:
> The problem is that ./log is not a file but a program that takes the
> output of the piped command and shows it in a particular format on a
> graphical interface. Redirecting via ">" does not work for me.
> Even creating a bash script executing the command and executing the
> script in the Tcl application makes the Tcl app hang until the command
> launched stops.
> I don't know how to solve this problem. It is a Tcl behavior that
> should have a work around...
My first idea when reading your question was an ad-hoc solution: why not wrap the
> The problem is that ./log is not a file but a program that takes the
> output of the piped command and shows it in a particular format on a
> graphical interface. Redirecting via ">" does not work for me.
> Even creating a bash script executing the command and executing the
> script in the Tcl application makes the Tcl app hang until the command
> launched stops.
> I don't know how to solve this problem. It is a Tcl behavior that
> should have a work around...
whole command up in a one line shell script on the server side?
/Str.
Adriana
May 4, 2012, 7:15:40 AM5/4/12
to
On May 4, 10:03 am, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
wrote:
I tried with a shell script that simply launches the command but still
the Tcl application hangs.
From the tcl application, I do:
if { [catch {exec startAgent.sh $user $machine} msg] } {
puts "$msg"
}
where startAgent.sh
#!/bin/bash
user=$1
machine=$2
ssh $user@$machine -2 "nohup myprogram 2>&1 | ./log &"
the catch/exec still hangs and only when I stop myprogram, it returns.
If I do,
if { [catch {exec startAgent.sh $user $machine &} msg] } {
puts "$msg"
}
of course it returns but the ssh connection appears in the process
list. I guess it launches the ssh connection in background and it
keeps it open which is something I would not like.
wrote:
the Tcl application hangs.
From the tcl application, I do:
if { [catch {exec startAgent.sh $user $machine} msg] } {
puts "$msg"
}
where startAgent.sh
#!/bin/bash
user=$1
machine=$2
ssh $user@$machine -2 "nohup myprogram 2>&1 | ./log &"
the catch/exec still hangs and only when I stop myprogram, it returns.
If I do,
if { [catch {exec startAgent.sh $user $machine &} msg] } {
puts "$msg"
}
of course it returns but the ssh connection appears in the process
list. I guess it launches the ssh connection in background and it
keeps it open which is something I would not like.
Adriana
May 4, 2012, 7:16:08 AM5/4/12
to
On May 4, 12:47 am, Eric <e...@deptj.eu> wrote:
Hello, thanks for your answer.
It does not change anything if I do that.
Andreas Leitgeb
May 4, 2012, 7:49:29 AM5/4/12
to
Adriana <adriana...@gmail.com> wrote:
> I tried with a shell script that simply launches the command but still
> the Tcl application hangs.
>
> From the tcl application, I do:
>
> if { [catch {exec startAgent.sh $user $machine} msg] } {
> puts "$msg"
> }
>
> where startAgent.sh
> #!/bin/bash
> user=$1
> machine=$2
> ssh $user@$machine -2 "nohup myprogram 2>&1 | ./log &"
Let me guess: if you start startAgent.sh directly from shell,
> I tried with a shell script that simply launches the command but still
> the Tcl application hangs.
>
> From the tcl application, I do:
>
> if { [catch {exec startAgent.sh $user $machine} msg] } {
> puts "$msg"
> }
>
> where startAgent.sh
> #!/bin/bash
> user=$1
> machine=$2
> ssh $user@$machine -2 "nohup myprogram 2>&1 | ./log &"
then it doesn't return you to the shell prompt, either.
Perhaps try using option "-x" with ssh, just in case, myprogram
idly opens an X11-connection, that might keep ssh waiting.
Robert Heller
May 4, 2012, 10:43:24 AM5/4/12
to
input on stdin). I *strongly* suggest that the -n and/or -f options be
supplied to ssh.
Deepwoods Software -- http://www.deepsoft.com/
Eric
May 4, 2012, 3:39:35 PM5/4/12
to
On 2012-05-04, Adriana <adriana...@gmail.com> wrote:
>>
>> you need
>>
>> ?| ./log >/dev/null &
mine, or something you are not telling us. I did do all the following
without recording it before replying to your original post.
Last login: Fri May 4 19:39:03 BST 2012 from teckel.deptj.eu on ssh
test1@teckel ~ $ id
uid=1006(test1) gid=100(users) groups=100(users)
test1@teckel ~ $ pwd
/home/test1
test1@teckel ~ $ ls -l
total 12
-rwxr-xr-x 1 test1 users 14 May 4 19:24 log
-rwxr-xr-x 1 test1 users 38 May 4 19:23 myprog
test1@teckel ~ $ cat myprog
while true; do echo hi; sleep 1; done
The above just something to produce output.
test1@teckel ~ $ cat log
cat > logfile
The above sends its input somewhere.
So I hope they are suitable representations of your programs.
test1@teckel ~ $ exit
Now see what processes exist:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
In my own session:
eric@teckel ~ $ ssh test1@teckel -2 "nohup ./myprog 2>&1 | ./log &"
does not return. Now the processes are:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 30297 30295 0 19:48 ? 00:00:00 sshd: test1@notty
test1 30300 1 0 19:48 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 30301 30300 0 19:48 ? 00:00:00 cat
test1 30299 1 0 19:48 ? 00:00:00 /bin/sh ./myprog
test1 30374 30299 0 19:49 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 30294 29402 0 19:48 pts/2 00:00:00 ssh test1@teckel -2 nohup ./
Clean up:
teckel ~ # kill 30299
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
and now my session has returned, so try:
eric@teckel ~ $ ssh test1@teckel -2 "nohup ./myprog 2>&1 | ./log > /dev/null &"
eric@teckel ~ $
which has returned immediately. But now the processes are:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 30464 1 0 19:51 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 30465 30464 0 19:51 ? 00:00:00 cat
test1 30463 1 0 19:51 ? 00:00:00 /bin/sh ./myprog
test1 30535 30463 0 19:52 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
No ssh in my session, but the expected processes for test1. So let's
do it all again with Tcl:
teckel ~ # kill 30463
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric@teckel ~ $ /usr/bin/tclsh
% set user test1
test1
% if { [catch {exec "ssh" "$user@teckel" "-2" "nohup ./myprog 2>&1 | ./log &"} msg] } {
puts "$msg"
}
doesn't return, and the processes are...
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 31443 31441 0 20:09 ? 00:00:00 sshd: test1@notty
test1 31446 1 0 20:09 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 31447 31446 0 20:09 ? 00:00:00 cat
test1 31445 1 0 20:09 ? 00:00:00 /bin/sh ./myprog
test1 31614 31445 0 20:11 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 31436 29402 0 20:08 pts/2 00:00:00 /usr/bin/tclsh
eric 31440 31436 0 20:09 pts/2 00:00:00 ssh test1@teckel -2 nohup
Clean up ...
teckel ~ # kill 31445
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 31436 29402 0 20:08 pts/2 00:00:00 /usr/bin/tclsh
... and try the other way:
% if { [catch {exec "ssh" "$user@teckel" "-2" "nohup ./myprog 2>&1 | ./log > /dev/null &"} msg] } {
puts "$msg"
}
%
which returns straight away, leaving us with:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 31701 1 0 20:16 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 31702 31701 0 20:16 ? 00:00:00 cat
test1 31700 1 0 20:16 ? 00:00:00 /bin/sh ./myprog
test1 31752 31700 0 20:17 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 31436 29402 0 20:08 pts/2 00:00:00 /usr/bin/tclsh
So myprog and log are running, and tclsh is free to do whatever
comes next! The difference in behaviour is just as I said before,
and Tcl has nothing to do with it anyway.
And just for the record:
% puts "$tcl_version $tcl_patchLevel"
8.5 8.5.9
% exit
eric@teckel ~ $ uname -a
Linux teckel 2.6.31-gentoo-r10 #4 SMP Mon Apr 5 22:10:54 BST 2010 i686 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux
eric@teckel ~ $ bash --version
GNU bash, version 4.1.9(2)-release (i686-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Apologies for the long post (and the few long lines), but it looked
like evidence time :-)
> On May 4, 12:47?am, Eric <e...@deptj.eu> wrote:
>> On 2012-05-03, Adriana <adriana.tele...@gmail.com> wrote:
>>
>> > Hello,
>> > I am stuck on a problem and I think that tcl/tk gurus could help me.
>>
>> > I am launching the following command:
>>
>> > if { [catch {exec "ssh" "$user@machine" "-2" "nohup myprogram 2>&1 | ./
>> > log &"} msg] } {
>> > ? ? ? ? puts "$msg"
>> On 2012-05-03, Adriana <adriana.tele...@gmail.com> wrote:
>>
>> > Hello,
>> > I am stuck on a problem and I think that tcl/tk gurus could help me.
>>
>> > I am launching the following command:
>>
>> > if { [catch {exec "ssh" "$user@machine" "-2" "nohup myprogram 2>&1 | ./
>> > log &"} msg] } {
>> > }
>> > where myprogram is a program that should continuously run and output
>> > text.
>>
>> > It happens that the pipe in the ssh command makes the catch not
>> > return.
>> > This must be a known problem.
>> > Does anyone know how to overcome it?
>> > Thanks in advance.
>> > Adriana
>>
>> From the manpage for exec:
>>
>> "If standard output has not been redirected then the exec command
>> returns the standard output from the last command in the pipeline..."
>>
>> which is ./log in your case. The standard output of ./log (on the
>> remote machine) is provided by ssh which connects it to the local
>> machine where it is connected to the tcl exec command which waits
>> patiently for it to be closed so that exec can return the contents!
>>
>> And catch, of course, waits for exec to complete. So there is nothing
>> wrong whatsoever, and all the software is doing what it is supposed to.
>>
>> All you have to do is close the standard output of ./log , so instead of
>>
>> ?| ./log &
>> > where myprogram is a program that should continuously run and output
>> > text.
>>
>> > It happens that the pipe in the ssh command makes the catch not
>> > return.
>> > This must be a known problem.
>> > Does anyone know how to overcome it?
>> > Thanks in advance.
>> > Adriana
>>
>> From the manpage for exec:
>>
>> "If standard output has not been redirected then the exec command
>> returns the standard output from the last command in the pipeline..."
>>
>> which is ./log in your case. The standard output of ./log (on the
>> remote machine) is provided by ssh which connects it to the local
>> machine where it is connected to the tcl exec command which waits
>> patiently for it to be closed so that exec can return the contents!
>>
>> And catch, of course, waits for exec to complete. So there is nothing
>> wrong whatsoever, and all the software is doing what it is supposed to.
>>
>> All you have to do is close the standard output of ./log , so instead of
>>
>>
>> you need
>>
>> ?| ./log >/dev/null &
>>
>> and then it will do what you expect.
>>
>> and then it will do what you expect.
>>
> Hello, thanks for your answer.
> It does not change anything if I do that.
There must be something in your environment that is different from
> It does not change anything if I do that.
mine, or something you are not telling us. I did do all the following
without recording it before replying to your original post.
Last login: Fri May 4 19:39:03 BST 2012 from teckel.deptj.eu on ssh
test1@teckel ~ $ id
uid=1006(test1) gid=100(users) groups=100(users)
test1@teckel ~ $ pwd
/home/test1
test1@teckel ~ $ ls -l
total 12
-rwxr-xr-x 1 test1 users 14 May 4 19:24 log
-rwxr-xr-x 1 test1 users 38 May 4 19:23 myprog
test1@teckel ~ $ cat myprog
while true; do echo hi; sleep 1; done
The above just something to produce output.
test1@teckel ~ $ cat log
cat > logfile
The above sends its input somewhere.
So I hope they are suitable representations of your programs.
test1@teckel ~ $ exit
Now see what processes exist:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
In my own session:
eric@teckel ~ $ ssh test1@teckel -2 "nohup ./myprog 2>&1 | ./log &"
does not return. Now the processes are:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 30297 30295 0 19:48 ? 00:00:00 sshd: test1@notty
test1 30300 1 0 19:48 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 30301 30300 0 19:48 ? 00:00:00 cat
test1 30299 1 0 19:48 ? 00:00:00 /bin/sh ./myprog
test1 30374 30299 0 19:49 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 30294 29402 0 19:48 pts/2 00:00:00 ssh test1@teckel -2 nohup ./
Clean up:
teckel ~ # kill 30299
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
and now my session has returned, so try:
eric@teckel ~ $ ssh test1@teckel -2 "nohup ./myprog 2>&1 | ./log > /dev/null &"
eric@teckel ~ $
which has returned immediately. But now the processes are:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 30464 1 0 19:51 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 30465 30464 0 19:51 ? 00:00:00 cat
test1 30463 1 0 19:51 ? 00:00:00 /bin/sh ./myprog
test1 30535 30463 0 19:52 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
No ssh in my session, but the expected processes for test1. So let's
do it all again with Tcl:
teckel ~ # kill 30463
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric@teckel ~ $ /usr/bin/tclsh
% set user test1
test1
% if { [catch {exec "ssh" "$user@teckel" "-2" "nohup ./myprog 2>&1 | ./log &"} msg] } {
puts "$msg"
}
doesn't return, and the processes are...
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 31443 31441 0 20:09 ? 00:00:00 sshd: test1@notty
test1 31446 1 0 20:09 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 31447 31446 0 20:09 ? 00:00:00 cat
test1 31445 1 0 20:09 ? 00:00:00 /bin/sh ./myprog
test1 31614 31445 0 20:11 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 31436 29402 0 20:08 pts/2 00:00:00 /usr/bin/tclsh
eric 31440 31436 0 20:09 pts/2 00:00:00 ssh test1@teckel -2 nohup
Clean up ...
teckel ~ # kill 31445
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 31436 29402 0 20:08 pts/2 00:00:00 /usr/bin/tclsh
... and try the other way:
% if { [catch {exec "ssh" "$user@teckel" "-2" "nohup ./myprog 2>&1 | ./log > /dev/null &"} msg] } {
puts "$msg"
}
%
which returns straight away, leaving us with:
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 31701 1 0 20:16 ? 00:00:00 bash -c nohup ./myprog 2>&1 | ./
test1 31702 31701 0 20:16 ? 00:00:00 cat
test1 31700 1 0 20:16 ? 00:00:00 /bin/sh ./myprog
test1 31752 31700 0 20:17 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 29401 29399 0 19:19 ? 00:00:00 sshd: eric@pts/2
eric 29402 29401 0 19:19 pts/2 00:00:00 -bash
eric 31436 29402 0 20:08 pts/2 00:00:00 /usr/bin/tclsh
So myprog and log are running, and tclsh is free to do whatever
comes next! The difference in behaviour is just as I said before,
and Tcl has nothing to do with it anyway.
And just for the record:
% puts "$tcl_version $tcl_patchLevel"
8.5 8.5.9
% exit
eric@teckel ~ $ uname -a
Linux teckel 2.6.31-gentoo-r10 #4 SMP Mon Apr 5 22:10:54 BST 2010 i686 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel GNU/Linux
eric@teckel ~ $ bash --version
GNU bash, version 4.1.9(2)-release (i686-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Apologies for the long post (and the few long lines), but it looked
like evidence time :-)
Robert Heller
May 4, 2012, 9:26:09 PM5/4/12
to
-n Redirects stdin from /dev/null (actually, prevents reading from
stdin). This must be used when ssh is run in the background. A
common trick is to use this to run X11 programs on a remote
machine. For example, ssh -n shadows.cs.hut.fi emacs & will
start an emacs on shadows.cs.hut.fi, and the X11 connection will
be automatically forwarded over an encrypted channel. The ssh
program will be put in the background. (This does not work if
ssh needs to ask for a password or passphrase; see also the -f
option.)
This *might* be an easier alternitive solution.
>
> Eric
Andreas Leitgeb
May 5, 2012, 3:25:10 AM5/5/12
to
Robert Heller <hel...@deepsoft.com> wrote:
> At Fri, 4 May 2012 11:49:29 +0000 (UTC) Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>> Adriana <adriana...@gmail.com> wrote:
>>> I tried with a shell script that simply launches the command but still
>>> the Tcl application hangs.
>>> From the tcl application, I do:
>>> if { [catch {exec startAgent.sh $user $machine} msg] } {
>>> puts "$msg"
>>> }
>>> where startAgent.sh
>>> #!/bin/bash
>>> user=$1
>>> machine=$2
>>> ssh $user@$machine -2 "nohup myprogram 2>&1 | ./log &"
>> Let me guess: if you start startAgent.sh directly from shell,
>> then it doesn't return you to the shell prompt, either.
>> Perhaps try using option "-x" with ssh, just in case, myprogram
>> idly opens an X11-connection, that might keep ssh waiting.
> Note: ssh *will* read from stdin (if nothing else, it will just gobble all
> input on stdin). I *strongly* suggest that the -n and/or -f options be
> supplied to ssh.
I think, that's not the point.
> At Fri, 4 May 2012 11:49:29 +0000 (UTC) Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>> Adriana <adriana...@gmail.com> wrote:
>>> I tried with a shell script that simply launches the command but still
>>> the Tcl application hangs.
>>> From the tcl application, I do:
>>> if { [catch {exec startAgent.sh $user $machine} msg] } {
>>> puts "$msg"
>>> }
>>> where startAgent.sh
>>> #!/bin/bash
>>> user=$1
>>> machine=$2
>>> ssh $user@$machine -2 "nohup myprogram 2>&1 | ./log &"
>> Let me guess: if you start startAgent.sh directly from shell,
>> then it doesn't return you to the shell prompt, either.
>> Perhaps try using option "-x" with ssh, just in case, myprogram
>> idly opens an X11-connection, that might keep ssh waiting.
> Note: ssh *will* read from stdin (if nothing else, it will just gobble all
> input on stdin). I *strongly* suggest that the -n and/or -f options be
> supplied to ssh.
The OP obviously wants to start a remote command to the remote host's
background, and then have ssh finish immediately (and the ssh-connection
be closed, too).
Robert Heller
May 5, 2012, 6:38:28 AM5/5/12
to
(eg stdout / stderr being 'consumed' by a remote command), will tend to
expect input on stdin and will wait for stdin to be closed. ssh opens
pipes in both directions and waits for *both* to be closed. In the OP's
case, the stdout/stderr pipe is going to he log program, but stdin is
dangling, so ssh does an I/O wait on it. It is necessary to redirect
that dangling pipe to /dev/null, then ssh can then cleanly exit getting
an EOF from /dev/null.
Eric
May 5, 2012, 7:45:12 AM5/5/12
to
On 2012-05-05, Robert Heller <hel...@deepsoft.com> wrote:
> At Fri, 4 May 2012 20:39:35 +0100 Eric <er...@deptj.eu> wrote:
>
>>
>> On 2012-05-04, Adriana <adriana...@gmail.com> wrote:
>> > On May 4, 12:47?am, Eric <e...@deptj.eu> wrote:
>> >> On 2012-05-03, Adriana <adriana.tele...@gmail.com> wrote:
>> >>
>> >> > Hello,
>> >> > I am stuck on a problem and I think that tcl/tk gurus could help me.
>> >>
>> >> > I am launching the following command:
>> >>
>> >> > if { [catch {exec "ssh" "$user@machine" "-2" "nohup myprogram 2>&1 | ./
>> >> > log &"} msg] } {
>> >> > ? ? ? ? puts "$msg"
>> >> > }
>> >> > where myprogram is a program that should continuously run and output
>> >> > text.
>> >>
>> >> > It happens that the pipe in the ssh command makes the catch not
>> >> > return.
>> >> > This must be a known problem.
>> >> > Does anyone know how to overcome it?
>> >> > Thanks in advance.
>> >> > Adriana
<snip>
> At Fri, 4 May 2012 20:39:35 +0100 Eric <er...@deptj.eu> wrote:
>
>>
>> On 2012-05-04, Adriana <adriana...@gmail.com> wrote:
>> > On May 4, 12:47?am, Eric <e...@deptj.eu> wrote:
>> >> On 2012-05-03, Adriana <adriana.tele...@gmail.com> wrote:
>> >>
>> >> > Hello,
>> >> > I am stuck on a problem and I think that tcl/tk gurus could help me.
>> >>
>> >> > I am launching the following command:
>> >>
>> >> > if { [catch {exec "ssh" "$user@machine" "-2" "nohup myprogram 2>&1 | ./
>> >> > log &"} msg] } {
>> >> > ? ? ? ? puts "$msg"
>> >> > }
>> >> > where myprogram is a program that should continuously run and output
>> >> > text.
>> >>
>> >> > It happens that the pipe in the ssh command makes the catch not
>> >> > return.
>> >> > This must be a known problem.
>> >> > Does anyone know how to overcome it?
>> >> > Thanks in advance.
>> >> > Adriana
>> > Hello, thanks for your answer.
>> > It does not change anything if I do that.
>>
>>
>> There must be something in your environment that is different from
>> mine, or something you are not telling us.
>
> From the ssh man page:
>
> -n Redirects stdin from /dev/null (actually, prevents reading from
> stdin). This must be used when ssh is run in the background. A
> common trick is to use this to run X11 programs on a remote
> machine. For example, ssh -n shadows.cs.hut.fi emacs & will
> start an emacs on shadows.cs.hut.fi, and the X11 connection will
> be automatically forwarded over an encrypted channel. The ssh
> program will be put in the background. (This does not work if
> ssh needs to ask for a password or passphrase; see also the -f
> option.)
>
> I wonder: would 'ssh -n ...' work the same as 'ssh ... >/dev/null'?
> This *might* be an easier alternitive solution.
gives the same results as
eric@teckel ~ $ ssh test1@teckel -2 "nohup ./myprog 2>&1 | ./log &"
eric@teckel ~ $ ssh test1@teckel -2 -f "nohup ./myprog 2>&1 | ./log &"
eric@teckel ~ $
returns immediately, but
teckel ~ # ps -Hfu test1
UID PID PPID C STIME TTY TIME CMD
test1 13029 1 0 12:12 ? 00:00:00 bash -c nohup ./myprog
2>&1 | ./
test1 13030 13029 0 12:12 ? 00:00:00 cat
test1 13028 1 0 12:12 ? 00:00:00 /bin/sh ./myprog
test1 13037 13028 0 12:12 ? 00:00:00 sleep 1
teckel ~ # ps -Hfu eric
UID PID PPID C STIME TTY TIME CMD
eric 12902 12900 0 12:10 ? 00:00:00 sshd: eric@pts/2
UID PID PPID C STIME TTY TIME CMD
eric 12903 12902 0 12:10 pts/2 00:00:00 -bash
eric 13025 1 0 12:12 ? 00:00:00 ssh test1@teckel -2 -f nohup ./m
i.e. the ssh process is still running on the local side which, as
the OP said, is undesirable. This is as implied by the manpages,
because -n redirects stdin, which has no effect, and all -f does is
to additionally background the ssh process.
BTW, the correct answer works the same if you close ./log's stdout
instead of redirecting it to /dev/null :
eric@teckel ~ $ ssh test1@teckel -2 "nohup ./myprog 2>&1 | ./log >&- &"
eric@teckel ~ $
(except that the log program itself may or may not have some reason
for disliking that)
Eric
May 5, 2012, 8:27:19 AM5/5/12
to
in this case. The fact that nohup is being used on the remote may
have something to do with it.
Adriana
May 7, 2012, 8:00:53 AM5/7/12
to
On May 5, 2:27 pm, Eric <e...@deptj.eu> wrote:
> On 2012-05-05, Robert Heller <hel...@deepsoft.com> wrote:
>
>
>
>
>
>
>
>
>
> > At Sat, 5 May 2012 07:25:10 +0000 (UTC) Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>
> >> Robert Heller <hel...@deepsoft.com> wrote:
> >> > At Fri, 4 May 2012 11:49:29 +0000 (UTC) Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
> On 2012-05-05, Robert Heller <hel...@deepsoft.com> wrote:
>
>
>
>
>
>
>
>
>
> > At Sat, 5 May 2012 07:25:10 +0000 (UTC) Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>
> >> Robert Heller <hel...@deepsoft.com> wrote:
> >> > At Fri, 4 May 2012 11:49:29 +0000 (UTC) Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
thanks a lot for all your posts.
Indeed, the >/dev/null helps but I also had to put </dev/null after
myprogram.
It is solved!
Thanks a lot!
Cheers,
Adriana
0 new messages