Comando Synology Scheduler .sh java não encontrado

Eu tenho um script bash que é a única tarefa é executar um arquivo jar.

sms.sh

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

Usando o meu Synology NAS, configurei uma tarefa.

Adicionando o comando para executar o script bash. Adicionando saída de log.

Executando minha nova tarefa.

Verificando o log para ver o seguinte erro:

/volume1/homes/jar/sms.sh: linha 1: java: comando não encontrado

Verificando a versão / instalação do Java:

Verificando a execução do script sh manualmente (funcionando):

Alguém com esse mesmo caso estranho? Alguma solução / idéias?

eu tentei

Reiniciando meu NAS
Desinstalar / instalar o pacote Java8

mas nenhum funcionou.

java bash synology

— piguy
fonte

Dado o seu problema, provavelmente é um problema com um ambiente (JAVA_HOME, PATH) não configurado corretamente quando a tarefa é executada. Você deve usar o caminho absoluto para o executável em java, ou obter um arquivo fazendo isso por você.

— NoDataFound

@NoDataFound O que você quer dizer com caminho absoluto? Não é /volume1/(...)/file.jar o caminho? Obrigado pela ajuda e pelo tempo

— piguy

Primeiro, encontre o executável java. Em seguida, invoque-o usando /whatever/path/to/java/is/java /volume1/homes/jar(isso não é específico da

— sinologia

Provavelmente, devemos adicionar aqui que, independentemente do usuário que esteja executando o comando, provavelmente não será o usuário com o qual o OP está conectado (a menos que tenha certeza de que está) e, portanto, possui um PATH diferente.

— BadZen

(Também: isso é realmente sobre o assunto?)

— BadZen

Respostas:

Quando o agendador de tarefas Synology executa o script, sms.sha configuração PATH é obtida do script /etc/crontab. O que não contém o caminho Java.

O ambiente de shell de login padrão é definido int /etc/profile. No final, há uma seção para adicionar o caminho 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 já foi mencionado nos comentários já fornecidos, não é sugerido um script de perfil destinado a um shell interativo. Você pode imitar o comportamento do /etc/profilescript em seu sms.shscript para definir CLASSPATH PATH JAVA_HOME LANG.

Os pontos levantados sobre a codificação do caminho no seu script e a portabilidade reduzida resultante podem ter uma precedência de amante nesse caso específico.

— SubOptimal
fonte

Sua resposta me ajudou muito e está correta, mas eu cliquei errado no meu telefone e dei os 100 pontos ao usuário abaixo. Sinto muito

— piguy 16/02

@ piguy Isso é ao vivo. ;-)

— SubOptimal

-1

Eu não estou familiarizado com Synologytão fwiw ...

O script do shell funciona quando executado na linha de comando, porque a sessão de login específica já carregou um conjunto de variáveis de ambiente (por exemplo, ao efetuar o login no .profile/.bashrc(s) script (s) no diretório inicial, é fornecida e as várias variáveis de ambiente específicas do java são carregadas - PATH, JAVA_HOME, CLASSPATH, etc) que permitem que javao script seja executado sem problemas.

O Synologyerro do trabalho com falha indica que as variáveis de ambiente específicas do java não foram carregadas e, portanto, o trabalho / script não pode ser localizado java.

Supondo Synologyque não haja uma definição / sinalizador de configuração que estipule para pré-carregar o perfil de um login, a solução 'fácil' seria editar o script ( sms.sh) e obter o arquivo de recurso apropriado antes de executar qualquer operação (por exemplo, chamada java). Um exemplo simples:

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

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

java ...

NOTAS :

substitua rootpelo nome do login sob o qual o script será executado (nas Synologyimagens de exemplo , parece que você escolheu o rootusuário, por isso meu exemplo é referente ~root)
substitua ~root/.bashrcpelo caminho para o perfil do usuário para pré-carregar as variáveis de ambiente necessárias para permitir que o script encontrejava

— markp-fuso
fonte

Por favor, não incentive os arquivos de configuração escritos para uso interativo a serem usados em contextos não interativos - isso leva a situações em que as pessoas pensam que as mudanças que estão fazendo são inofensivas (porque .bashrcnão muda a forma como os daemons operam, certo?), Mas podem causar quebra de produção.

— Charles Duffy

É muito melhor encontrar a localização real e apenas codificar uma atualização PATH apropriada no próprio script ou em um arquivo de configuração de uso dedicado que as origens do script. Isso também funciona em situações onde isso não vai - f / e, quando /etc/profile.dao invés de ~/.bashrcser relevante.

— Charles Duffy

a codificação física dificilmente é portável, especialmente em ambientes mistos de SO / versão; quanto ao uso de arquivos de configuração / recurso interativos versus arquivos de recursos / configuração especialmente criados ... isso é mais um problema de escolha pessoal com base no (s) desenvolvedor (es) escrevendo / mantendo o ambiente; Eu tive problemas zero / zero nos últimos 20 anos ... em ambientes de produção ... usando um arquivo de recurso / configuração comum em todo um ambiente de script, ymmv

— markp-fuso

A pontilhação nos arquivos interativos de um usuário também não é portável (especialmente considerando como as distros reequilibram qual conteúdo é feito por quais arquivos - alguns fazendo as coisas da maneira tradicional e usando .profile, outros usando .bash_profile, alguns usando /etc/profile.d, algumas definindo variáveis de ambiente do PAM, etc.) . De uma forma ou de outra, você está fazendo algo não portável. Pelo menos a codificação codificada PATH=$PATH:/whatever/specific/locationestá alterando as configurações, e seu comportamento é óbvio para os leitores (que não precisam se preocupar em mudar mais tarde).

— Charles Duffy