No se encontró el comando java de Synology Scheduler .sh

Tengo un script bash cuya única tarea es ejecutar un archivo jar.

sms.sh

java -jar /volume1/homes/jar/smssender.jar

Con mi Synology NAS configuré una tarea.

Agregar el comando para ejecutar el script bash. Agregar salida de registro.

Ejecutando mi nueva tarea.

Verificando el registro para ver el siguiente error:

/volume1/homes/jar/sms.sh: línea 1: java: comando no encontrado

Comprobación de la versión / instalación de Java:

Comprobación de la ejecución del script sh manualmente (en funcionamiento):

¿Alguien con este mismo caso extraño? ¿Alguna solución / ideas?

Lo intenté

Reiniciar mi NAS
Desinstalar / instalar el paquete Java8

Pero ninguno funcionó.

java bash synology

— piguy
fuente

Dado su problema, es probable que sea un problema con un env (JAVA_HOME, PATH) no configurado correctamente cuando se ejecuta el trabajo. Debe usar la ruta absoluta al ejecutable de Java, ya sea buscar un archivo que lo haga por usted.

— NoDataFound

@NoDataFound ¿Qué quieres decir con ruta absoluta? ¿No es /volume1/(...)/file.jar la ruta? Gracias por ayuda y tiempo

— piguy

Primero, encuentre el ejecutable de Java. Luego, invoque usando /whatever/path/to/java/is/java /volume1/homes/jar(esto no es específico de la sinología)

— NoDataFound

Probablemente deberíamos agregar aquí que cualquier usuario que esté ejecutando el comando eventualmente no es el usuario con el que OP inicia sesión (a menos que esté seguro de que lo es) y, por lo tanto, tiene una RUTA diferente.

— BadZen

(Además: ¿esto es realmente sobre el tema?)

— BadZen

Respuestas:

Cuando el planificador de tareas de Synology ejecuta el script, sms.shla configuración de la RUTA se toma del script /etc/crontab. Que no contiene la ruta de Java.

El entorno de shell de inicio de sesión predeterminado se define int /etc/profile. Al final hay una sección para agregar la ruta de Java.

PATH=$PATH:/var/packages/Java8/target/j2sdk-image/bin # Synology Java runtime enviroment
PATH=$PATH:/var/packages/Java8/target/j2sdk-image/jre/bin # Synology Java runtime enviroment
JAVA_HOME=/var/packages/Java8/target/j2sdk-image/jre # Synology Java runtime enviroment
CLASSPATH=.:/var/packages/Java8/target/j2sdk-image/jre/lib # Synology Java runtime enviroment
LANG=en_US.utf8 # Synology Java runtime enviroment
export CLASSPATH PATH JAVA_HOME LANG # Synology Java runtime enviroment

Como ya se indicó en los comentarios ya dados, no se sugiere una secuencia de comandos de perfil destinada a un shell interactivo. Puede imitar el comportamiento del /etc/profilescript en su sms.shscript para establecer CLASSPATH PATH JAVA_HOME LANG.

Los puntos planteados sobre la codificación de la ruta en su secuencia de comandos y la portabilidad reducida resultante podrían tener una precedencia amante en este caso específico.

— Subóptimo
fuente

Su respuesta me ayudó mucho y es correcta, pero hice un clic incorrecto en mi teléfono y le di los 100 puntos al usuario. Lo siento mucho

— piguy

@piguy Eso es en vivo. ;-)

— Subóptimo

-1

No estoy familiarizado con Synologytan fwiw ...

El script de shell funciona cuando se ejecuta en la línea de comando porque la sesión de inicio de sesión particular ya ha cargado un conjunto de variables de entorno (por ejemplo, al iniciar sesión en el .profile/.bashrcscript (s) en el directorio de inicio se obtiene y se cargan las diversas variables de entorno específicas de Java - PATH, JAVA_HOME, CLASSPATH, etc.) que permiten que javael script se ejecute sin problemas.

El Synologyerror de trabajo fallido indica que las variables de entorno específicas de Java no se han cargado y, por lo tanto, el trabajo / script no se puede localizar java.

Suponiendo Synologyque no tiene una configuración / indicador de configuración que estipule la carga previa del perfil de inicio de sesión, la solución 'fácil' sería editar el script ( sms.sh) y hacer que obtenga el archivo de recursos apropiado antes de realizar cualquier operación (por ejemplo, llamar java). Un simple ejemplo:

$cat sms.sh
#!/usr/bin/bash

. ~root/.bashrc      # load the root account profile before continuing ...

java ...

NOTAS :

reemplace rootcon el nombre del inicio de sesión con el que se ejecutará el script (en las Synologyimágenes de ejemplo parece que ha elegido al rootusuario, por lo tanto, mis referencias de ejemplo ~root)
reemplace ~root/.bashrccon la ruta al perfil del usuario para precargar las variables de entorno necesarias para permitir que el script encuentrejava

— markp-fuso
fuente

No aliente que los archivos de configuración escritos para uso interactivo se utilicen en contextos no interactivos; esto conduce a situaciones en las que las personas piensan que los cambios que están haciendo son inofensivos (porque .bashrcno cambia la forma en que operan los demonios, ¿verdad?) Sino que pueden causar rotura de producción.

— Charles Duffy

Mucho mejor para encontrar la ubicación real y simplemente codificar una actualización PATH adecuada en el script en sí, o en un archivo de configuración de propósito específico de las fuentes del script. Eso también funciona en situaciones en las que esto no funcionará - f / e, cuando en /etc/profile.dlugar de ~/.bashrcser relevante.

— Charles Duffy

la codificación rígida no es portátil, especialmente en entornos mixtos de SO / versión; en cuanto al uso de archivos interactivos de configuración / recursos frente a archivos de recursos / configuración especialmente diseñados ... eso es más un problema de elección personal basado en los desarrolladores que escriben / mantienen el entorno; No he tenido / ningún problema en los últimos 20 años ... en entornos de producción ... usando un recurso común / archivo de configuración en todo un entorno de scripting, ymmv

— markp-fuso

El punteado en los archivos interactivos de un usuario tampoco es portátil (particularmente teniendo en cuenta cómo las distribuciones reequilibran qué contenido se hace mediante qué archivos: algunos hacen las cosas de la manera tradicional y usan .profile, otros usan .bash_profile, algunos usan /etc/profile.d, algunas configuran variables de entorno de PAM, etc.) . De una forma u otra, estás haciendo algo no portátil. Al menos el hardcoding PATH=$PATH:/whatever/specific/locationestá modificando la configuración, y su comportamiento es obvio para los lectores (que no necesitan preocuparse por si cambiará más adelante).

— Charles Duffy