[linux-help] Re: Process persistence

[Denis Medvedev <t_mdl@xxxxxxxxx>]

Nohup has disadwantages.
it produces nohup.out and you cannot get rid of it.
Better way:
user $ command &
[1] 25333
user $ disown %1
user $ ^D
Volia! Process now runs detached.


--- Tom Hull <thull2@xxxxxxx> wrote:
> 
> Wayne White wrote:
> > I am fooling around with some machines on a
> network. I am trying
> > to telnet into one machine, from another, start a
> program and close
> > the telnet connection. When I close the
> connection, the program
> > dies.
> > 
> > I am trying to get the machines to run headless &
> without keyboards.
> > To do so I need to be able to start programs
> remotely. I know that
> > telnet isn't real secure, but this network isn't
> connected to the outside
> > world.
> > 
> > So, how can I cause a program started over a
> telnet session to
> > persist when the telnet connection is closed?
> 
> Run the program using nohup(1).
> 
> When you run a program, the process has a
> "controlling terminal",
> and when you log out, Linux sends a signal (SIGHUP,
> hang-up) to
> each process attached to that controlling terminal.
> All nohup
> does is to arrange so that the program ignores the
> SIGHUP, and
> redirects stdout/stderr to the file nohup.out, and
> stdin from
> /dev/null. Make sure to use & to run the program as
> a background
> job, otherwise nohup just waits on it:
> 
>    nohup PROGRAM ARGUMENTS ... &
> 
> There are other, fancier ways to do this: basically
> arrange for your
> program to change its process group and session id,
> which has the
> effect of changing the controlling terminal. Daemon
> programs are
> written to do just this, because for them you want
> to break all
> terminal-process associations (including SIGKILL,
> SIGSTOP, etc.).
> But that only works if you write the program to do
> it; nohup works
> for everything.
> 
> Also, if you don't want the nohup.out file left,
> redirect the
> outputs yourself.
> 
> > Is there some other way to log into the headless
> machine to start
> > a program? Perhaps just a console on the other
> machine? I wasn't
> > going to mess with SSH, but would that do what I
> need? I could
> > install it on both machines, I suppose.
> 
> You can use rsh(1), which is usually disabled due to
> security
> considerations. If you set it up properly on a
> firewalled local
> network, it should be ok. You can run programs on
> remote machines
> through any network service that allows it; e.g.,
> you can run
> CGI programs through httpd (if you configure it to
> do so).
> 
> > Many thanks,
> > 
> > wayne
> > 
> > -- This is the linux-help@xxxxxxxxx list.  To
> unsubscribe,
> > visit
> http://www.complete.org/cgi-bin/listargate-aclug.cgi
> > 
> > 
> 
> 
> 
> -- 
> /*
>   *  Tom Hull * thull2 at cox.net *
> http://www.tomhull.com/
>   */
> 
> -- This is the linux-help@xxxxxxxxx list.  To
> unsubscribe,
> visit
> http://www.complete.org/cgi-bin/listargate-aclug.cgi
> 


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
-- This is the linux-help@xxxxxxxxx list.  To unsubscribe,
visit http://www.complete.org/cgi-bin/listargate-aclug.cgi