TL; DR: uso sudo -b
o, mejor ,.openvpn [...] --daemon
Dado que está ejecutando openvpn
(y, menos específicamente, ya que desea ejecutar un programa como raíz en segundo plano), la información más comúnmente distribuida sobre cómo ejecutar comandos en segundo plano no aborda su situación. Tu dijiste:
Intenté agregar un & al comando cpenvpn y colocar nohop delante de él. Ambos no funcionan.
Tu comando es:
sudo openvpn ~/my_connection.ovpn
Según sudo
la configuración predeterminada, si no ha ingresado su contraseña recientemente sudo
en el mismo contexto (para uso interactivo, generalmente esto significa el mismo terminal), le pedirá su contraseña. Pero si ejecuta el comando en segundo plano al agregarlo &
, no se le mostrará la línea ni tendrá la oportunidad de escribirlo.[sudo] password for user:
Entonces, en esta situación, ejecutar el comando, ingresar su contraseña y enviarla a un segundo plano es una forma razonable de hacerlo, para uso interactivo .
Pero no es la única forma y, como usted dice, no querrá hacerlo en un guión .
Forma 1: asegúrese de sudo
tener una nueva marca de tiempo.
Puede asegurarse de que sudo
tiene una marca de tiempo actual cuando se utiliza para ejecutar su comando, ejecutando primero:
sudo -v
Luego, después de eso, puedes ejecutar:
sudo openvpn ~/my_connection.ovpn &
Sin embargo, generalmente es mejor evitar &
(y nohup
) por completo cuando desea ejecutar un comando en segundo plano con sudo
. Este es especialmente el caso de las secuencias de comandos.
Camino 2: uso sudo -b
. En general, esto suele ser lo que quieres.
En cambio, puede ejecutarse sudo
en primer plano, pero pasar la -b
bandera sudo
hace que el comando se ejecute en segundo plano.
sudo -b openvpn ~/my_connection.ovpn
Esta suele ser una mejor manera, especialmente si está poniendo el comando en un script. Con sudo -b
usted no obtiene el control del trabajo , pero en un script de shell, el control del trabajo está deshabilitado de forma predeterminada y, por lo general, no debería usarlo .
Como man sudo
explica:
-b, --background
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.
Esto funciona porque no se está ejecutando en segundo plano hasta después sudo ha recibido su contraseña (si es necesario) y se determina que está autorizado para ejecutar el comando.
Forma 3: Pero openvpn
, probablemente, solo deberías ejecutarlo --daemon
.
openvpn
se ejecutará en segundo plano automáticamente si lo ejecuta con la --daemon
opción:
sudo openvpn ~/my_connection.ovpn --daemon
Pase --daemon
después de su .opvn
nombre de archivo en lugar de antes; El siguiente argumento --daemon
, si lo hay, se interpreta como el nombre que openvpn
debe usar el proceso demonizado . (Do no también append &
.)
Si esto es apropiado o no depende de si debe producirse alguna interacción después de que openvpn
se haya ejecutado pero antes de que se demonice. Y eso depende, en parte, de lo que está configurado ~/my_connection.ovpn
. Pero si openvpn
no se puede demonizar de inmediato, también se romperán todas las otras formas de ejecutarlo inmediatamente en segundo plano .
Por lo tanto, en cualquier situación donde se sabe que quiere openvpn
a empezar ejecuta en segundo plano, y usted sabe que no va a querer traer de vuelta al primer plano, usted debe considerar seriamente el método de invocar con la --daemon
opción. Esto es específico para: la openvpn
mayoría de los programas no admiten una --daemon
opción, aunque muchos programas de servidor sí tienen alguna opción. (Sin embargo, el nombre y la sintaxis varían).
Para decidir si usar o no esta opción (y cómo desea usarla), le recomiendo que lea la openvpn
página del manual , especialmente en la sección sobre --daemon
. Tiene mucha información útil, y solo estoy citando el primer párrafo aquí:
--daemon [progname]
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 [...]
Forma 4 : a veces es razonable ejecutar todo el script como root.
Si tiene un script que lleva a cabo múltiples acciones como root, no tiene ninguna actividad significativa que razonablemente se ejecute no como root, y nunca hay nada útil de ejecutar el script como un usuario no root, entonces el El usuario de la secuencia de comandos probablemente debería simplemente ejecutarlo como root.
Si este es el caso, entonces debe eliminar sudo
de los comandos en el script. Cuando el script se ejecuta como root, no hay necesidad de hacerlo sudo
. (Aunque el usuario puede raíz, de forma predeterminada, ejecutar cualquier comando como cualquier usuario incluido él mismo con sudo
y no necesita una contraseña para hacerlo. Así que si haces casos de licencia de sudo
en el guión, entonces probablemente va a funcionar todavía.)
Si tiene alguna instancia de sudo
la secuencia de comandos que realmente se utiliza para ejecutar comandos como otro usuario que no sea root (con ), entonces aún debe mantener esas instancias.-u user
Si todo el script se ejecuta como root, entonces se aplican la mayoría de las formas típicas de ejecutar comandos en segundo plano , incluyendo la adición &
y, cuando sea necesario, el uso de nohup
(que ya conoce). Para esto, sin embargo, aún debe considerar usar openvpn
con la --daemon
opción.