How to Start and Manage Background Processes in Shell Scripts

background-processcommand linejob-controlshell-scriptsignals

I'd like to run and configure a process similarly to a daemon from a script.
My shell is zsh emulated under Cygwin and the daemon is SFK, a basic FTP server.

For what matters here, the script startserv.sh can be drafted as follows:

#!/bin/sh
read -s -p "Enter Password: " pw
user=testuser
share=/fshare
cmd="sfk ftpserv -user=$user -pw=$pw -usedir $share=$share"
$cmd &

After running the script startserv.sh, it stops (ends?) without showing any prompt, then:

CTRL+C ends both the script and the background job process;
Hitting Enter the script ends the process remains in the background.

Anyway I can see it only via ps and not jobs, so, when I want to close the process, I have to send a brutal kill -9 signal, which is something I'd like to avoid in favour of CTRL+C.

An alternative would be running the whole script in background. 'Would be', but the read command is unable get the user input if the script is run as startserv.sh &.

Note that I need an ephemeral server, not a true daemon: that is, I want the server process to run in the background, after the script ends, to perform simple interactive shell tasks (with a virtual machine guest), but I don't need the process to survive the shell; therefore nohup seems not appropriate.

Best Answer

Hitting Enter the script ends the process remains in the background.

Almost! Actually, the script has already exited by the time you press Enter. However, that's how you can get your prompt back (because your shell prints its $PS1 all over again).

The reason why hitting Ctrl + C terminates both of them is because the two of them are linked. When you execute your script, your shell initiates a subshell in which to run it. When you terminate this subshell, your background process dies, probably from a SIGHUP signal.

Separate the script, the background process and the subshell

Using nohup, you might be able to get rid of this little inconvenience.

#!/bin/sh
read -s -p "Enter Password: " pw
user=testuser
share=/fshare
cmd="sfk ftpserv -user=$user -pw=$pw -usedir $share=$share"
nohup $cmd &

The `disown` alternative

If you can switch from /bin/sh to /bin/bash, you can give a try to disown as well. To know more, just type help disown in a bash instance.

disown -h $cmd &

Killing the background process "nicely"

Now, when it comes to killing your process, you can perfectly do a "Ctrl + C" using kill. Just don't send a brutal SIGKILL. Instead, you could use:

$ kill -2 [PID]
$ kill -15 [PID]

Which will send a nice SIGINT (2) or SIGTERM (15) to your process. You may also want to print the PID value after starting the process:

...
nohup $cmd &
echo $!

... or even better, make the script wait for a SIGINT, and send it back to the background process (this will keep your script in the foreground though):

#!/bin/sh
read -s -p "Enter Password: " pw
user=testuser
share=/fshare
cmd="sfk ftpserv -user=$user -pw=$pw -usedir $share=$share"
nohup $cmd &

# Storing the background process' PID.
bg_pid=$!

# Trapping SIGINTs so we can send them back to $bg_pid.
trap "kill -2 $bg_pid" 2

# In the meantime, wait for $bg_pid to end.
wait $bg_pid

If a SIGINT isn't enough, just use a SIGTERM instead (15) :

trap "kill -15 $bg_pid" 2 15

This way, when your script receives a SIGINT (Ctrl + C, kill -2) or a SIGTERM while waiting for the background process, it'll just relay the signals to it. If these signals do kill the sfk instance, then the wait call will return, therefore terminating your script as well :)

Read from a pipe, write to a file

If you want the daemon to read input produced by some arbitrary process, you need to connect that process to a pipe. Here the arbitrary process is you echoing commands, and it's going to run in a different context. So create a named pipe (often called a fifo in unix contexts).

mkfifo /var/run/daemon.fifo
</var/run/daemon.fifo /path/to/daemond --option >daemon.log

And just write commands to the pipe:

echo 'FORWARD 10' >/var/run/daemon.fifo
echo 'LEFT 72' >/var/run/daemon.fifo

This is unlikely to work as is however: there's a good chance that the daemon will exit when it sees an end of file on its standard input, which happens as soon as the first process that writes to the pipe terminates. You can use tail -f to avoid that problem.

</var/run/daemon.fifo tail -c +1 -f | {
  echo $$ >/var/run/daemon.pid
  exec /path/to/daemond --option >daemon.log
}

With some tail implementations, you may get bitten by buffering: the tail process will wait until it has amassed enough bytes to emit some output. I don't think this is solvable in the POSIX toolbox; if that's a problem, use a trivial C or Perl or Python program. As far as I can tell the tail from GNU coreutils (as found on Linux and elsewhere) is safe on this respect.

When you stop the daemon, echo >/var/run/daemon.fifo will kill the tail process.

Starting the program inside screen

Instead of invoking the daemon directly from your service manager (are you really using just SysV init, or something additional like wrapper scripts or Upstart?), invoke

screen -c daemon.screenrc -L -d -m -S daemon_name /path/to/daemond --option

Since the daemon won't be a child process of the service manager, you need to make sure to send a signal to the right process. How to do that depends on exactly how the daemon is started and by what.

It's technically possible to attach a running process to a terminal, but there's a risk you'll crash the program, so this is definitely out for a production system.

The -L option makes screen write everything that appears in its window to a file. The file name is given in daemon.screenrc with the logfile directive.

Python Background Process Ends When SSH Session Terminates – Why?

I would disconnect the command from its standard input/output and error flows:

nohup python3 -u <script> </dev/null >/dev/null 2>&1 &

ssh needs an indicator that doesn't have any more output and that it does not require any more input. Having something else be the input and redirecting the output means ssh can safely exit, as input/output is not coming from or going to the terminal. This means the input has to come from somewhere else, and the output (both STDOUT and STDERR) should go somewhere else.

The </dev/null part specifies /dev/null as the input for <script>. Why that is useful here:

Redirecting /dev/null to stdin will give an immediate EOF to any read call from that process. This is typically useful to detach a process from a tty (such a process is called a daemon). For example, when starting a background process remotely over ssh, you must redirect stdin to prevent the process waiting for local input. https://stackoverflow.com/questions/19955260/what-is-dev-null-in-bash/19955475#19955475

Alternatively, redirecting from another input source should be relatively safe as long as the current ssh session doesn't need to be kept open.

With the >/dev/null part the shell redirects the standard output into /dev/null essentially discarding it. >/path/to/file will also work.

The last part 2>&1 is redirecting STDERR to STDOUT.

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!
What does > /dev/null 2>&1 mean? | Xaprb

Best Answer

Separate the script, the background process and the subshell

The disown alternative

Killing the background process "nicely"

Related Solutions

Shell – How to make a shell script that sends output to a process

Read from a pipe, write to a file

Starting the program inside screen

Python Background Process Ends When SSH Session Terminates – Why?

Related Question

The `disown` alternative