Terminal – How to Invoke a Command or Script Disconnected from the Controlling Terminal

controlling-terminalinteractiveprocessterminaltty

I'm investigating the behaviour of a script that is normally run as an automated process (e.g. cron, Jenkins). The script can (eventually) invoke commands that behave differently (seeking user input) when run interactively; for example, patch will ask what to do with a reversed patch, and svn will ask for passwords, but I need to see what happens when they're run non-interactively.

Persuading patch that it's non-interactive is fairly easy; I just need to redirect stdout to be a non-tty:

$ </dev/null > >(cat) /path/to/myscript --args

However svn will connect to the controlling terminal if it exists; editing the scripts to pass --non-interactive isn't really an option as this is coming from several levels deep and it'd be difficult to be certain I'd found every invocation.

Is there a way to invoke a script/command non-interactively, without a controlling terminal (so that /dev/tty doesn't exist)? I'd prefer stdout/stderr to still go to my terminal.

(I found the question Run script in a non interactive shell? but the answers to that discuss the differences between the cron and user environment; I've already eliminated all differences except non-interactivity.)

Best Answer

You need to start another session not attached to a terminal, so for instance:

$ setsid sh -c 'tty; ps -jp "$$"; echo test' < /dev/null > log 2>&1
$ cat log
not a tty
  PID  PGID   SID TTY          TIME CMD
19506 19506 19506 ?        00:00:00 sh
test

See also the start-stop-daemon command found on some Linux distributions. There's also a daemon command.

Related Solutions

Run Script in Non-Interactive Shell – Shell Scripting Tips

The main differences between running a command from cron and running on the command line are:

cron is probably using a different shell (generally /bin/sh);
cron is definitely running in a small environment (which ones depends on the cron implementation, so check the cron(8) or crontab(5) man page; generally there's just HOME, perhaps SHELL, perhaps LOGNAME, perhaps USER, and a small PATH);
cron treats the % character specially (it is turned into a newline);
cron jobs run without a terminal or graphical environment.

The following invocation will run the shell snippet pretty much as if it was invoked from cron. I assume the snippet doesn't contain the characters ' or %.

env - HOME="$HOME" USER="$USER" PATH=/usr/bin:/bin /bin/sh -c 'shell snippet' </dev/null >job.log 2>&1

See also executing a sh script from the cron, which might help solve your problem.

SSH Signals – When SIGHUP is Not Sent to a Job on Logout

Bash seems to send the SIGHUP only if it self received a SIGHUP, which for example occurs when a virtual terminal is closed or when the SSH connection is interrupted. From the documentation:

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the SIGHUP signal to a particular job, it should be removed from the jobs table with the disown builtin (see Job Control Builtins) or marked to not receive SIGHUP using disown -h.

So if you type exit or press Ctrl+D all background process will remain, since this does not send a hang up signal to the Bash.

You can force Bash to warn you about the fact that there are still running background processes with

shopt -s checkjobs

There is an option to send the SIGHUP on exit if you are in an interactive shell(see here). But it doesn't work on my machine with Bash 4.2.25. Maybe it works for you

shopt -s huponexit

Best Answer

Related Solutions

Run Script in Non-Interactive Shell – Shell Scripting Tips

SSH Signals – When SIGHUP is Not Sent to a Job on Logout

Related Question