sudo -b or, better,
openvpn [...] --daemon.
Since you're running
openvpn (and, less specifically, since you wish to run a program as root in the background), the most commonly dispensed information about how to run commands in the background does not address your situation. You said:
I've tried to append a & to the cpenvpn command and to place nohop in
front of it. Both does not work.
Your command is:
sudo openvpn ~/my_connection.ovpn
sudo's default configuration, if you haven't recently entered your password for
sudo in the same context (for interactive use, typically this means the same terminal) then it will ask for your password. But if you run the command in the background by appending
& then you won't be shown the
[sudo] password for user: line or given the opportunity to type it in.
So in this situation, running the command, entering your password, and sending it to the background afterwards is an reasonable way to do it, for interactive use.
But it's not the only way and, as you say, you will not want to do that in a script.
Way 1: Make sure
sudo has a fresh timestamp.
You can ensure that
sudo has a current timestamp when it is used to run your command, by first running:
Then, after that, you can run:
sudo openvpn ~/my_connection.ovpn &
However, it is usually better to avoid
nohup) altogether when you want to run a command in the background with
sudo. This is especially the case for scripting.
Way 2: Use
sudo -b. In general, this is usually what you want.
Instead, you can run
sudo itself in the foreground, but pass the
-b flag so
sudo causes the command to be run in the background.
sudo -b openvpn ~/my_connection.ovpn
This is usually a better way, especially if you are putting the command in a script. With
sudo -b you don't get job control, but in a shell script job control is disabled by default and you shouldn't usually use it.
man sudo explains:
Run the given command in the background. Note that it is not
possible to use shell job control to manipulate background
processes started by sudo. Most interactive commands will
fail to work properly in background mode.
This works because nothing is running in the background until after sudo has recieved your password (if necessary) and determined that you are permitted to run the command.
Way 3: But for
openvpn, you should probably just run it with
openvpn will run in the background automatically if you run it with the
sudo openvpn ~/my_connection.ovpn --daemon
--daemon after your
.opvn filename rather than before; the argument following
--daemon, if any, is interpreted as the name that the daemonized
openvpn process should use. (Do not also append
Whether or not this is appropriate depends on whether or not any interaction must occur after
openvpn has been run but before it daemonizes. And that depends, in part, on what is set up in
~/my_connection.ovpn. But if
openvpn couldn't immediately daemonize, then all the other ways of immediately running it in the background will break, too.
Therefore, in any situation where you know you want
openvpn to start running in the background, and you know you won't want to bring it back into the foreground, you should strongly consider the method of invoking it with the
--daemon option. This is specific to
openvpn--most programs do not support a
--daemon option, though many server programs do have some such option. (The name and syntax vary, however.)
To decide whether or not to use this option (and how you want to use it), I recommend you read the
openvpn manual page, especially in the section on
--daemon. It has a lot of useful information, and I am only quoting the first paragraph here:
Become a daemon after all initialization functions are
completed. This option will cause all message and error output
to be sent to the syslog file (such as /var/log/messages),
except for the output of scripts and ifconfig commands, which
will go to /dev/null unless otherwise redirected. The syslog
redirection occurs immediately at the point that --daemon is
parsed on the command line even though the daemonization point
occurs later. If one of the --log options is present, it will
supercede syslog redirection.
The optional progname parameter [...]
Way 4: Sometimes it's reasonable to run the whole script as root.
If you have a script that carries out multiple actions as root, it doesn't have any significant activity that would reasonably be run not as root, and there's never anything useful to come from running the script as a non-root user, then the user of the script should probably just run it as root.
If this is the case, then you should remove
sudo from commands in the script. When the script runs as root, there's no need for
sudo. (Though the root user can, by default, run any command as any user including itself with
sudo and doesn't need a password to do so. So if you do leave instances of
sudo in the script then it will probably still work.)
If you have any instances of
sudo in the script that are actually used to run commands as some other user than root (with
-u user), then you should still keep those instances.
If the whole script is being run as root, then most of the typical ways of making commands run in the background apply, including appending
& and, where needed, the use of
nohup (which you already know about). For this, though, you should still strongly consider using
openvpn with the