Bash – error thrown when using su -c: bash: no job control in this shell

bashsu

I have written a script which should execute certain commands as another user and after execution is finished (success or failure) should logout immediately.

I have read that I can use -c of su to execute commands. So, I wrote a script like:

#!/usr/bin/env bash

su - user2 -c "echo 'hurray' && exit"

It executes the echo command but stays logged in as user2 doesn't logout. I even tried using logout instead of exit but it stays logged in. I need to execute script as user1 which invokes the su command and executes as user2 and then the control should return to user1 after completion.

UPDATE

Alright, I was to able logout automatically but this time some commands are not being executed. For eg:

Command1:

su user2 -c 'echo 1'

Output1:

And, then it logs out on its own.

Command2:

su user2 -c 'bash some-script.sh'

Output2:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

So, whenever I try to run some script via -c of su, it displays the above mentioned error. I've tried many commands with -c option such as ls, which, bash --version, mkdir, rm, whoami etc. All these commands produced the correct output. But any command which tries to execute a script, it fails with the error.

su user2 -c 'bash --version'      # Works
su user2 -c 'bash some-script.sh' # Doesn't work

I cannot figure out why this is happening. And, so is the reason I'm unable to fix this error.

Best Answer

The reason for this behaviour is documented in the manual page for recent versions of su:

-c, --command COMMAND

Specify a command that will be invoked by the shell using its -c.

The executed command will have no controlling terminal. This option cannot be used to execute interractive programs which need a controlling TTY.

(emphasis mine)

When you run basic commands such as ls, echo or bash --version, they simply print their output to the stdout stream without without needing a controlling terminal.

I suspect that either the way bash is being invoked (as an interactive shell) or some-script.sh contains commands which require a controlling terminal device so running 'bash some-script.sh' throws the cannot set terminal process group (-1): Inappropriate ioctl for device error.

Some explanation

A controlling terminal for a process is the terminal device from which the process was started. A controlling terminal can send signals to groups of process and is the mechanism by which job control works in Unix operating systems; job control allows processes in the process group to be run in foreground or the background.

The output of the ps command shows the controlling terminal for each process, e.g.,

$ ps

  PID TTY          TIME CMD
 3614 pts/5    00:00:00 bash
31628 pts/5    00:00:00 ps

Recent change in su

In the past, su -c did start a controlling terminal when not running an interactive shell. Running apt-get changelog login on my Ubuntu system shows that the removal of the controlling terminal was introduced in May 2012 as a security measure:

su: Fix possible tty hijacking by dropping the controlling terminal when executing a command (CVE-2005-4890). Closes: #628843

Related Solutions

Bash – Compatibility scripting: Save $? for use later

This answer works in bash-like shells and csh-like shells, and it doesn’t require perl:

sh -c '<< other code >>; [ "$0" != "" ] && exit "$0"; exit "$1"' "$?" "$status"

or you can add a dummy/pad parameter:

sh -c '<< other code >>; [ "$1" != "" ] && exit "$1"; exit "$2"' foo "$?" "$status"

and the test can be changed to [ ! -z "$0" ] (or "$1"). I don’t know whether it will work in zsh or fish. Every shell that I’m familiar with will evaluate $? and $status when the command is parsed, and pass them to the sh -c command as parameters. The sh shell assigns them to the last two positional parameters. When the “other code” finishes, the shell will check the positional parameter that got its value from $? to see whether it is null or non-null, and exit with the appropriate positional parameter value.

This will fail if the ambient shell uses something other than $? or $status to hold the exit status. It will also fail if the shell allows $? to be set (non-null) if it is not the exit status, or if $? is an invalid character sequence that causes the entire command to be rejected as a syntax error.

Bash: no job control in this shell

init is /bin/bash

As I said at https://unix.stackexchange.com/a/197472/5132, init=/bin/sh doesn't get "API" fileystems mounted, crashes in an ungainly fashion with no cache flush when one types exit (https://unix.stackexchange.com/a/195978/5132), and in general leaves it to the (super)user to manually do the actions that make the system minimally usable.

One of those actions (if you want to use a job control shell, as you apparently do) is acquiring a controlling terminal. /dev/tty isn't an actual terminal device. It's a device that redirects to whatever the opening process' controlling terminal is. If it does not have one, as process #1 does not to begin with (and usually all of the time when a real system manager program is being run as process #1), then opening the device fails.

Your system is too minimal. You need to run a program that sets up a controlling terminal, initializes a proper session, and probably does some of the bare minima of system management such as shutting down properly and cleanly, that then runs your job control shell.