Comando Synology Scheduler .sh java não encontrado

9

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.

Configuração da tarefa executada pela raiz

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

insira a descrição da imagem aqui

Executando minha nova tarefa.

insira a descrição da imagem aqui

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:

insira a descrição da imagem aqui

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

insira a descrição da imagem aqui

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.

piguy
fonte
4
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
3
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
11
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:

5

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
11
É 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
11
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