Synology Scheduler .sh comando java non trovato

Ho uno script bash che l'unica cosa è eseguire un file jar.

sms.sh

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

Utilizzando Synology NAS ho impostato un'attività.

Aggiunta del comando per eseguire lo script bash. Aggiunta dell'output del registro.

Esecuzione della mia nuova attività.

Verifica del registro per vedere il seguente errore:

/volume1/homes/jar/sms.sh: linea 1: java: comando non trovato

Verifica della versione / installazione di Java:

Verifica manuale dell'esecuzione di sh script (funzionante):

Qualcuno con questo stesso strano caso? Qualche soluzione alternativa / idee?

Provai

Riavvio del NAS
Disinstallare / installare il pacchetto Java8

ma nessuno ha funzionato.

java bash synology

— piguy
fonte

Dato il tuo problema, è probabilmente un problema con un env (JAVA_HOME, PATH) non impostato correttamente quando il lavoro viene eseguito. Dovresti usare il percorso assoluto per l'eseguibile java, o fonte un file che lo fa per te.

— NoDataFound

@NoDataFound Cosa intendi con percorso assoluto? /Volume1/(...)/file.jar non è il percorso? Grazie per l'aiuto e il tempo

— piguy

Innanzitutto, trova l'eseguibile Java. Quindi, invocalo usando /whatever/path/to/java/is/java /volume1/homes/jar(questo non è specifico della sinologia)

— NoDataFound il

Probabilmente dovremmo aggiungere qui che qualunque utente stia eseguendo il comando probabilmente non è l'utente con cui OP sta effettuando l'accesso (a meno che non sia sicuro che lo sia), e quindi abbia un PERCORSO diverso.

— BadZen

(Inoltre: è davvero in tema?)

— BadZen

Risposte:

Quando l'utilità di pianificazione Synology esegue lo script, sms.shl'impostazione PATH viene presa dallo script /etc/crontab. Che non contiene il percorso Java.

L'ambiente della shell di accesso predefinito è definito int /etc/profile. Alla fine c'è una sezione per aggiungere il percorso 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

Come già affermato nei commenti già forniti, non è suggerito reperire uno script di profilo destinato a una shell interattiva. Potresti imitare il comportamento dello /etc/profilescript nel tuo sms.shscript per impostare CLASSPATH PATH JAVA_HOME LANG.

I punti sollevati su come codificare il percorso nel tuo script e la conseguente portabilità ridotta potrebbero avere una precedenza amante in questo caso specifico.

— subottimale
fonte

La tua risposta mi ha aiutato molto ed è corretta ma ho sbagliato a scrivere sul mio telefono e ho dato i 100 punti all'utente in basso. Mi dispiace davvero

— piguy

@piguy È live. ;-)

— Subottimale il

-1

Non ho familiarità con Synologycosì prima ...

Lo script della shell funziona quando viene eseguito dalla riga di comando perché la particolare sessione di accesso ha già caricato un set di variabili di ambiente (ad esempio, al momento della registrazione negli .profile/.bashrcscript nella directory home viene fornita e vengono caricate le varie variabili di ambiente specifiche di Java - PATH, JAVA_HOME, CLASSPATH, ecc.) che consentono javae l'esecuzione dello script senza problemi.

L' Synologyerrore del processo non riuscito indica che le variabili di ambiente specifiche di Java non sono state caricate e pertanto il lavoro / script non è in grado di individuare java.

Supponendo che Synologynon ci sia un'impostazione / flag di configurazione che preveda di precaricare il profilo di un login, la soluzione "facile" sarebbe quella di modificare lo script ( sms.sh) e far sì che esso provenga il file di risorse appropriato prima di eseguire qualsiasi operazione (ad esempio, chiamata java). Un semplice esempio:

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

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

java ...

NOTE :

sostituisci rootcon il nome dell'account di accesso con cui deve essere eseguito lo script (nelle Synologyimmagini di esempio sembra che tu abbia scelto l' rootutente e quindi i miei riferimenti di esempio ~root)
sostituire ~root/.bashrccon il percorso del profilo dell'utente per precaricare le variabili di ambiente necessarie per consentire allo script di trovarejava

— Markp-Fuso
fonte

Si prega di non incoraggiare i file di configurazione scritti per l'uso interattivo da utilizzare in contesti non interattivi: ciò porta a situazioni in cui le persone pensano che i cambiamenti che stanno apportando siano innocui (perché .bashrcnon cambia il modo in cui i demoni funzionano, giusto?) Ma può invece causare rottura della produzione.

— Charles Duffy,

Molto meglio trovare la posizione reale e semplicemente codificare un aggiornamento PATH appropriato nello script stesso, o in un file di configurazione dedicato alle origini dello script. Funziona anche in situazioni in cui ciò non funziona - f / e, quando /etc/profile.dpiuttosto che ~/.bashrcè rilevante.

— Charles Duffy,

hardcoding è difficilmente trasportabile, specialmente in ambienti OS / versione misti; per quanto riguarda l'utilizzo di file di configurazione / risorse interattivi rispetto a file di configurazione / risorse appositamente costruiti ... questo è più un problema di scelta personale basato sulla scrittura / gestione dell'ambiente da parte degli sviluppatori; Negli ultimi 20 anni non ho avuto problemi / zero ... in ambienti di produzione ... utilizzando un file di configurazione / risorsa comune in un intero script env, ymmv

— markp-fuso

Anche la punteggiatura nei file interattivi di un utente non è portatile (in particolare dato come le distro riequilibrano quale contenuto viene fatto da quali file - alcuni fanno le cose nel modo tradizionale e usano .profile, alcuni usano .bash_profile, altri usano /etc/profile.d, alcuni impostano variabili d'ambiente da PAM, ecc.) . In un modo o nell'altro, stai facendo qualcosa di nonportabile. Almeno l'hardcoding PATH=$PATH:/whatever/specific/locationsta modificando le impostazioni e il suo comportamento è ovvio per i lettori (che non devono preoccuparsi se cambierà in seguito).

— Charles Duffy,