How can I make a program keep running even after I logout?

Nikolas Britton freebsd at
Wed Dec 15 17:30:07 PST 2004

Rae Kim wrote:

>Thank you all guys..
>I've tried daemon, nohup and Nicolas' csh method
>all works fine.
My way isn't a csh way it's just that I use csh as my default shell and 
was just stating the fact that with csh background jobs do not die when 
you exit, so the "nohup" is optional (but recommend) with csh.

The way I do it is a hybrid of my own method I thought up and Rubens method:

# nohup foobar > foobar.log&

"nohup" is to ingore the SIGUP signal, "foobar" is your command you want to run, ">" is to redirect output from 
stdout (the console) to a file, "foobar.log" is the file you're redirecting output to, "&" is to background the job.

example: nohup cvsup -g -L 2 /root/ports-supfile > /root/ports-supfile.log&
# tail -f foobar.log

tail displays the end of a file (are log file), the "-f" flag "causes tail to not stop when end of file is reached, but rather to wait for additional data to be appended to the input", "foobar.log" this is are log file from are backgrounded job above.

example: tail -f /root/ports-supfile.log

So what tail -f essentially does is bring are background job back to the foreground by redirecting the output from the command back to stdout. This mean that if we're on a remote connection and the link die the program will stay running and we can just login again and start where we left off, or if we get back home/work/school/where we can still watch whats happening in realtime.

I just had an idea... Is there a way to redirect stdin to a file or redirect stdin to a file and have are job use this file for stdin? if this is was possible we could interact with are background job from any remote or local terminal, this could be a security risk though because anyone could interact with it?.

So anyways... The beauty of this is that we're using standard unix stuff so you can do this from any *nix box and from any shell.


###My (old) Way###
$ ssh localhost
Password: ****
Last login: Mon Nov 22 06:13:59 2004 from localhost
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
       The Regents of the University of California.  All rights reserved.

FreeBSD 5.3-RELEASE-p1 (SPECTRA) #0: Sat Nov 20 23:30:17 CST 2004

Welcome to FreeBSD!

$ su
Password: ****
spectra# cvsup -g -L 2 /root/ports-supfile > /root/ports-supfile.log&
[1] 71669
spectra# exit
$ exit
Connection to localhost closed.
$ tail /root/ports-supfile.log
 Add delta 1.25 2004. marcus
Edit ports/x11-toolkits/py-gnome2/Makefile
 Add delta 1.78 2004. kwm
Edit ports/x11-toolkits/py-gnome2/distinfo
 Add delta 1.28 2004. kwm
Edit ports/x11-toolkits/py-gnome2/pkg-plist
 Add delta 1.31 2004. kwm
Updating collection ports-x11-wm/cvs
Shutting down connection to server
Finished successfully
$ exit

###Rubens Way###
>From work:
# nohup foobar >& foobar.log &

Back home:
# tail -f foobar.log


# nohup foobar >& foobar.log &
              ^^^^           ^^^

Why'd you do it like that, how is it diffrent from this way?:
# nohup foobar > foobar.log &
His example redirects both stdout and stderr to foobar.log, while yours
only redirect stdout. (Note that ">&" is a csh-specific operator. The
equivalent for a Bourne-shell derivative would be:
 nohup foobar > foobar.log 2>&1 &
I.e. redirecting stdout to foobar.log and then redirecting file
descriptor 2 (stderr) to wherever file descriptor 1 (stdout) goes to
(foobar.log in this case.)

When used with the nohup command I believe the redirection of stderr
is unnecessary since the manpage for nohup(1) says "If standard error is a
terminal, it is directed to the same place as the standard output."

More information about the freebsd-questions mailing list