Commande Java Synsh Scheduler .sh introuvable

J'ai un script bash qui n'a pour tâche que d'exécuter un fichier jar.

sms.sh

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

À l'aide de mon Synology NAS, j'ai configuré une tâche.

Ajout de la commande pour exécuter le script bash. Ajout d'une sortie de journal.

Exécution de ma nouvelle tâche.

Vérification du journal pour voir l'erreur suivante:

/volume1/homes/jar/sms.sh: ligne 1: java: commande introuvable

Vérification de la version / installation de Java:

Vérification de l'exécution du script sh manuellement (fonctionne):

Quelqu'un avec ce même cas étrange? Des solutions / idées?

j'ai essayé

Redémarrer mon NAS
Désinstaller / installer le package Java8

mais aucun n'a fonctionné.

java bash synology

— piguy
source

Compte tenu de votre problème, il s'agit probablement d'un problème avec un env (JAVA_HOME, PATH) non correctement défini lors de l'exécution du travail. Vous devez soit utiliser le chemin absolu vers l'exécutable java, soit générer un fichier faisant cela pour vous.

— NoDataFound

@NoDataFound Que voulez-vous dire par chemin absolu? /Volume1/(...)/file.jar n'est-il pas le chemin? Merci pour l'aide et le temps

— piguy

Tout d'abord, recherchez l'exécutable java. Ensuite, invoquez-le en utilisant /whatever/path/to/java/is/java /volume1/homes/jar(ce n'est pas spécifique à la synologie)

— NoDataFound

Nous devrions probablement ajouter ici que quel que soit l'utilisateur qui exécute la commande, ce n'est probablement pas l'utilisateur avec lequel OP se connecte (à moins qu'il ne soit sûr), et a donc un PATH différent.

— BadZen

(Aussi: est-ce vraiment sur le sujet?)

— BadZen

Réponses:

Lorsque le planificateur de tâches Synology exécute le script, sms.shle paramètre PATH est extrait du script /etc/crontab. Qui ne contient pas le chemin Java.

L'environnement shell de connexion par défaut est défini int /etc/profile. À la fin, il y a une section pour ajouter le chemin 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

Comme déjà indiqué dans les commentaires déjà donnés, la recherche d'un script de profil destiné à un shell interactif n'est pas suggérée. Vous pouvez imiter le comportement du /etc/profilescript dans votre sms.shscript pour définir CLASSPATH PATH JAVA_HOME LANG.

Les points soulevés concernant le codage en dur du chemin dans votre script et la portabilité réduite qui en résulte peuvent avoir une priorité pour les amoureux dans ce cas spécifique.

— SubOptimal
source

Votre réponse m'a beaucoup aidé et est correcte mais j'ai mal cliqué sur mon téléphone et donné les 100 points à l'utilisateur en dessous. Je suis vraiment désolé

— piguy

@piguy C'est en direct. ;-)

— SubOptimal

-1

Je ne connais pas Synologysi fwiw ...

Le script shell fonctionne lorsqu'il est exécuté sur la ligne de commande, car la session de connexion particulière a déjà chargé un ensemble de variables d'environnement (par exemple, lors de la connexion au .profile/.bashrc(x) script (s) dans le répertoire personnel, les sources et les différentes variables d'environnement spécifiques à java sont chargées - PATH, JAVA_HOME, CLASSPATH, etc) qui permettent javaet le script de s'exécuter sans problème.

L' Synologyerreur d' échec du travail indique que les variables d'environnement spécifiques à Java n'ont pas été chargées et que le travail / script ne peut donc pas être localisé java.

En supposant Synologyqu'il n'y ait pas de paramètre / indicateur de configuration qui stipule de pré-charger le profil d'une connexion, la solution `` facile '' serait d'éditer le script ( sms.sh) et de lui faire source le fichier de ressources approprié avant d'effectuer toute opération (par exemple, appeler java). Un exemple simple:

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

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

java ...

REMARQUES :

remplacer rootpar le nom de la connexion sous laquelle le script doit être exécuté (dans les Synologyimages d' exemple , il semble que vous ayez choisi l' rootutilisateur, d'où mes références d'exemple ~root)
remplacer ~root/.bashrcpar le chemin d'accès au profil de l'utilisateur afin de précharger les variables d'environnement nécessaires pour permettre au script de trouverjava

— markp-fuso
source

Veuillez ne pas encourager les fichiers de configuration écrits pour une utilisation interactive à être utilisés dans des contextes non interactifs - cela conduit à des situations où les gens pensent que les changements qu'ils apportent sont inoffensifs (car .bashrccela ne change pas le fonctionnement des démons, n'est-ce pas?) rupture de production.

— Charles Duffy

Il est préférable de trouver l'emplacement réel et de coder en dur une mise à jour PATH appropriée dans le script lui-même, ou dans un fichier de configuration dédié aux sources du script. Cela fonctionne également dans les situations où cela ne sera pas - f / e, quand /etc/profile.dplutôt que ce ~/.bashrcn'est pertinent.

— Charles Duffy

le codage en dur n'est guère portable, en particulier dans les environnements mixtes OS / versions; quant à l'utilisation de fichiers de configuration / ressources interactifs par rapport à des fichiers de ressources / configuration spécialement construits ... c'est plus un problème de choix personnel basé sur le ou les développeurs qui écrivent / maintiennent l'environnement; Je n'ai eu aucun / aucun problème au cours des 20 dernières années ... dans des environnements de production ... en utilisant un fichier commun de ressources / configuration à travers un environnement de script entier, ymmv

— markp-fuso

Le pointage dans les fichiers interactifs d'un utilisateur n'est pas portable non plus (en particulier compte tenu de la façon dont les distributions rééquilibrent le contenu par quels fichiers - certaines faisant les choses de manière traditionnelle et utilisant .profile, certaines utilisant .bash_profile, d'autres utilisant /etc/profile.d, certaines définissant des variables d'environnement à partir de PAM, etc.) . D'une manière ou d'une autre, vous faites quelque chose de non portable. Au moins hardcoding PATH=$PATH:/whatever/specific/locationest amendement à des paramètres, et son comportement est évident pour les lecteurs (qui ne pas à se soucier de savoir si elle va changer plus tard).

— Charles Duffy