Commande Java Synsh Scheduler .sh introuvable


9

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.

Configuration des tâches exécutée par root

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

entrez la description de l'image ici

Exécution de ma nouvelle tâche.

entrez la description de l'image ici

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:

entrez la description de l'image ici

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

entrez la description de l'image ici

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é.


4
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

3
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

1
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:


5

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.


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

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

1
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

1
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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.