linux - running - Ejecute el script con rc.local: el script funciona, pero no al inicio

rc local raspberry

Question

Tengo un script node.js que necesita comenzar al arrancar y ejecutar bajo el usuario www-data. Durante el desarrollo, siempre comencé el script con:

su www-data -c ''node /var/www/php-jobs/manager.js

Vi exactamente lo que sucedió, el manager.js ahora funciona genial. Buscando SO, encontré que tenía que colocar esto en mi /etc/rc.local . Además, aprendí a apuntar el resultado a un archivo de registro y a anexar el 2>&1 para "redirigir stderr a stdout" y debería ser un daemon para que el último carácter sea un & .

Finalmente, mi /etc/rc.local ve así:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

su www-data -c ''node /var/www/php-jobs/manager.js >> /var/log/php-jobs.log 2>&1 &''

exit 0

Si ejecuto esto yo mismo ( sudo /etc/rc.local ): ¡sí, funciona! Sin embargo, si realizo un reinicio, no se está ejecutando ningún proceso de node , el /var/log/php-jobs.log no existe y, por lo tanto, el manager.js no funciona. ¿Que esta pasando?

Answer 1

1 No recomiendo usar root para ejecutar aplicaciones como la aplicación de nodo.

Bueno, puedes hacerlo pero puedes atrapar más excepciones.

2 El rc.local normalmente se ejecuta como usuario root.

Por lo tanto, si el script se ejecuta como otro usuario, como www U, debe asegurarse de que PATH y el resto del entorno estén correctos.

3 Encuentro una manera fácil de ejecutar un servicio como usuario:

sudo -u www -i / the / path / of / your / script

Por favor, prefiera el manual de sudo ~ -i [comando] La opción -i (simular inicio de sesión) ejecuta el shell especificado por la entrada de la base de datos de contraseñas del usuario de destino como un loginshell ...

Answer 2

Conseguí que mi script funcionara editando /etc/rc.local luego emitiendo los siguientes 3 comandos.

sudo mv /filename /etc/init.d/
sudo chmod +x /etc/init.d/filename 
sudo update-rc.d filename defaults

Ahora la secuencia de comandos funciona en el arranque.

Answer 3

En Ubuntu noté que hay 2 archivos. El verdadero es /etc/init.d/rc.local ; parece que el otro /etc/rc.local es falso?

Una vez que modifiqué el correcto ( /etc/init.d/rc.local ) se ejecutó tal como se esperaba.

Answer 4

En algunos linux (Centos & RH, por ejemplo), /etc/rc.local es inicialmente solo un enlace simbólico a /etc/rc.d/rc.local . En esos sistemas, si el enlace simbólico está roto, y /etc/rc.local es un archivo separado, los cambios a /etc/rc.local no se verán en el arranque: el proceso de arranque ejecutará la versión en /etc/rc.d (Funcionarán si uno ejecuta /etc/rc.local manualmente, pero no se ejecutará en el arranque).

Suena como en el sistema de dimadima, son archivos separados, pero /etc/rc.d/rc.local llama a /etc/rc.local

El enlace simbólico de /etc/rc.local a ''real'' en /etc/rc.d puede perderse si uno mueve rc.local a un directorio de respaldo y lo copia de nuevo o lo crea desde cero, sin darse cuenta de que el original uno en /etc era solo un enlace simbólico.

Answer 5

En este ejemplo de una secuencia de comandos rc.local, utilizo la redirección io en la primera línea de ejecución en mi propio archivo de registro:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

exec 2> /tmp/rc.local.log  # send stderr from rc.local to a log file
exec 1>&2                      # send stdout to the same log file
set -x                         # tell sh to display commands before execution

/opt/stuff/somefancy.error.script.sh

exit 0

Answer 6

Esto es muy probablemente causado por una variable de entorno PATH faltante o incompleto.

Si proporciona rutas completas absolutas a sus ejecutables (su y nodo), funcionará.

Answer 7

Estoy usando CentOS 7.

$ cd  /etc/profile.d

$ vim yourstuffs.sh

Escriba lo siguiente en el script yourstuffs.sh.

Escribe lo que quieras aquí para ejecutar

export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH

Guarde y reinicie el sistema operativo.

Answer 8

He usado rc.local en el pasado. Pero he aprendido por experiencia que la forma más confiable de ejecutar el script en el momento del inicio del sistema es usar el comando @reboot en crontab. Por ejemplo:

@reboot path_to_the_start_up_script.sh

Answer 9

También podría haberlo hecho al especificar la ruta completa al nodo. Además, cuando desee ejecutar un comando de shell como daemon, debe cerrar stdin agregando 1 <& - antes de &.

Answer 10

Tengo entendido que si coloca su script en cierto nivel de RUN, debe usar ln -s para vincular el script al nivel en el que desea que funcione.

Answer 11

Terminé con advenedizo , que funciona bien.

Answer 12

Tuve el mismo problema (en CentOS 7) y lo solucioné dando permisos de ejecución a / etc / local:

chmod +x /etc/rc.local

Answer 13

si está usando Linux en la nube, generalmente no tiene la oportunidad de tocar el hardware real con las manos. por lo que no ve la interfaz de configuración cuando arranca por primera vez, y por supuesto no puede configurarla. Como resultado, el servicio de firstboot siempre estará en el camino a rc.local . La solución es desactivar firstboot haciendo:

sudo chkconfig firstboot off

si no está seguro de por qué su rc.local no se ejecuta, siempre puede verificar desde el archivo /etc/rc.d/rc porque este archivo siempre se ejecutará y llamará a otros subsistemas (por ejemplo, rc.local).

Answer 14

rc.local solo se ejecuta al inicio. Si reinicia y desea que se ejecute el script, debe ir al archivo rc.0 comenzando con el prefijo K99.