I want to use rsh (or anything else) to send a command to a machine on
my lan, but I want to detach from that command so I don't have to wait
until the command finishes.

Any suggestions for a clean way to detach?

I want to use rsh (or anything else) to send a command to a machine on
my lan, but I want to detach from that command so I don't have to wait
until the command finishes.

Any suggestions for a clean way to detach?

root wrote:

I want to use rsh (or anything else) to send a command to a machine on
my lan, but I want to detach from that command so I don't have to wait
until the command finishes.

Any suggestions for a clean way to detach?

detach in what sense?

So you can reattach later to see how it's doing?
if so:
as elsewhere advised: man screen
or if you want to suspend the rsh: type: ~^Z
you can then 'fg' it later.

Or so that you can leave it running and kill the connection?
if so: possibly "nohup" is your friend.

I want to use rsh (or anything else) to send a command to a machine on
my lan, but I want to detach from that command so I don't have to wait
until the command finishes.
....
Suppose that every few minutes some machine on the lan
originates a task for a dedicated machine also on
the lan. The dedicated machine only deals with these
tasks. I can't have a user on each machine monitoring
the jobs.

I was also thinking of a program on the remote machine
that does nothing but a fork to execute the task, but
uses setpgrp to "detach" from the forking program.

I know that last paragraph is obscure, let me explain.
Suppose I write a program vfork on the remote machine.
I call it like this:

rsh remote vfork command line to be executed

When vfork on the remote machine gets called
it sees its command line arguments as:
comand line to be executed. All vfork does
is execute those arguments via execlp. The
daughter process of vfork, however, is attached
to vfork so rsh waits for the daughter to finish.
So I want to use either setpgid or setpgrp to attach
the daughter process to another task, say the shell
under which some console is running.

You mean the task effectively works in the background on the remote machine,

ie you want to effectively do:


$ task &

but on the remote machine?

I don't think setpgid() works in the way you think it does...it's use is in
the processing of signals and inputting of data from a terminal (see: man
setpgrp).

Mefinx the problem is that the forked remote process is keeping open the
"tty" (socket) of the rsh (not ssh?) process. Your forking program will
need to close [and reopen] stdin, stdout, stderr (file descriptors 0-2) [to
relevant byte streams - especially stdout/stderr if you want results back
somehow, if no input/output is needed, reconnect to /dev/null].

You are right about my failure to grasp setpgid. What I wanted to do
was to disassociate the task from the shell that rsh brought up.
I have been different options on my machine then porting them over
to the remote machine. I thought I had something when I created a
program which merely copied the command line over to execlp, but
rand setsid() before the execlp. Something like this:

pid=fork();
if(pid==0){
setsid();
execlp(......);
}
exit(0);

Mefinx the problem is that the forked remote process is keeping open the
"tty" (socket) of the rsh (not ssh?) process. Your forking program will
need to close [and reopen] stdin, stdout, stderr (file descriptors 0-2) [to
relevant byte streams - especially stdout/stderr if you want results back
somehow, if no input/output is needed, reconnect to /dev/null].

Here's what I think is happening:
rsh brings up a shell on the remote machine
the shell forks to the command, but stays around until the command finishes
rsh keeps the connection open until the shell closes.

I'm pretty sure now that I can't do what I want.

Using ssh & the above program I can remotely start a background process
without waiting for it to terminate on the remote host. Try the above
program and see what happens.

Perfect. Your program detaches the command from rsh . Thanks for
the effort.

root wrote:

I want to use rsh (or anything else) to send a command to a machine on
my lan, but I want to detach from that command so I don't have to wait
until the command finishes.

Any suggestions for a clean way to detach?

detach in what sense?

So you can reattach later to see how it's doing?
if so:
as elsewhere advised: man screen
or if you want to suspend the rsh: type: ~^Z
you can then 'fg' it later.

Or so that you can leave it running and kill the connection?
if so: possibly "nohup" is your friend.

I have used the at command with faverable results. at will spawn the command
as the user running the at command at the time specified. (just once or at
the same time every day etc). I have not found a nice way to monitor the
output if the program is not generating a log. You can redirect the output
to a log file and tail it? The status from at and the output can be mailed
to you opon completion of the command. You can pick a time to run a program
or run it now. try man at

I cannot remember the syntax but something like this
at now < /pgmpath/runme

command line
^d

I cannot remember the syntax but something like this
at now < /pgmpath/runme

Thanks for the suggestion. Just now I played with the at command
and the syntax is unclear, with no examples in the man page.
One site suggested building the command interactively as:
at now
....

which works, but is not useful for me. I tried your syntax
as:
at now </usr/bin/sleep 20

a script file. So, now I tried:
rsh remote at now "<"/pgmpath/runme

Assuming /pgmpath/runme is on the remote host, you should be able to do:

$ rsh remote at now -f /pgmpath/runme

if you have different commands, you can either set up a set of scripts, or
create it locally and then copy it to the remote host for execution.