sudo, &, -b or --daemon: how to background an OpenVPN client

Two questions hide inside the phrase 'run it in the background'. The first is whether this user may start a privileged process at all; the second is whether the session can continue without anyone typing into a terminal. A shell ampersand answers neither, and a script that stores a sudo password in a variable answers the first badly while leaving the second untouched. Separate them and the options become easy to compare.

Compare the three candidates on ownership, not on convenience.

Three ways to leave the terminal, three different owners

Appending an ampersand to a command asks the shell to run it as a background job, and the job still belongs to that shell. sudo may prompt before the program even starts, and OpenVPN may prompt afterwards for a key passphrase or a login. Backgrounding a command that expects input produces a process waiting on a terminal nobody is watching. The terminal is freed; the interaction is not.

That is the cheapest option and the one that fails most confusingly, because the prompt appears in a place the operator has already left.

sudo -b is not a credential handler

sudo -b runs the command in the background from sudo's own perspective, which sounds like the missing feature and is not. According to the sudo manual, interactive commands generally misbehave in that mode, and shell job control cannot manage the processes it creates. It moves the process without giving it a way to answer questions. Nothing about it supplies a private-key passphrase or a gateway login.

If the connection needs interaction, the fix is a supported non-interactive authentication arrangement, not a different way to launch the same prompt.

--daemon changes the program, not the login

--daemon asks OpenVPN itself to detach after initialization. The 2.6 manual notes that syslog redirection happens when the option is parsed, even though the detach happens later, so messages can stop appearing in the terminal earlier than expected. Silence after that point proves nothing about the tunnel. Add an explicit --log or --log-append so the output lands somewhere you can read.

Daemon mode also removes the console permanently. A protected private key needs askpass in that mode, and console-entered credentials combined with caching options can leave a later reauthentication with nowhere to ask. Check the authentication model against the installed version before assuming a background start will survive its first rekey.

What sudo validation does and does not buy

sudo -v validates or refreshes the cached local credential, authenticating if the policy requires it. It does not start OpenVPN, does not authenticate to the gateway, and does not guarantee that a later command in the script is permitted. sudo -n means the opposite: do not prompt, fail instead. That makes a local authorization failure explicit, which is useful, and it says nothing about what OpenVPN will ask for later.

Neither option is a reason to grant blanket passwordless commands or to pipe an administrator password into a script.

Prefer an owner that can be observed

For a machine-owned tunnel, use the service instance the distribution supports. That owner provides start, stop, status and logs, and it survives your session ending. Assembling shell backgrounding, daemonization and a restart loop around each other creates three owners for one tunnel and no clear answer to which one is running.

Whatever you choose, verify the resource the tunnel exists for. A successful start request is a process event, not proof of a working connection.