Falha ao executar programa via cron [RESOLVIDO]

escomunal
(usa Red Hat)

Enviado em 31/05/2017 - 15:41h

Amigos, estou precisando de ajuda, vou tentar explicar sem me estender muito.

Possuo um shell script chamado executa.ksh dentro dele uma das linhas executa um programa binario de um cliente o qual não tenho acesso ao fonte.

Quando eu executo este programa manualmente (./executa.ksh) ele roda o binario normalmente, no entanto quando coloco no cron. ele apresenta erro de memoria para este binario.

Maiores detalhes: O script está carregando as variaveis do user, desconfio que este binario necessite de algum terminal pra ser executado, alguém tem alguma ideia de como posso executar isso.

paulo1205
(usa Ubuntu)

Enviado em 31/05/2017 - 16:58h

Erro de memória e erro de falta de terminal seriam, em princípio, distintos (a não ser que a aplicação acabe misturando internamente as coisas).

O que geralmente dá problema dentro do cron são variáveis de ambiente que afetem coisas que o programa espera, sendo que variáveis referentes a locales um dos exemplos mais comuns. Outras variáveis que costumam ser diferentes são PATH, SHELL (não deveria ser usada, mas sabe como é...), USER, HOME e TMPDIR.

Você consegue reproduzir totalmente as variáveis de uma sessão interativa no script executado via cron?

Alternativamente, você pode tentar executar o programa do usuário a partir de uma sessão interativa, mas desligando-o do terminal. Para tanto, você pode empregar redirecionamentos e o programa setsid.

escomunal
(usa Red Hat)

Enviado em 01/06/2017 - 19:43h

Paulo, muito obrigado, mas ainda estou com o mesmo problema, no entanto tenho mais informaçoes

o programa binario que está dentro do shell executa.sh está em c

Quando executo na mão esse executa.sh o programa finaliza belezão

Se eu coloco no cron dá erro, eu direcionei a saída do cron e o erro que acontece é falha de segmentação, eu trabalho com Unix a muito tempo, linux a pouco mais de 5 meses, nunca vi isso.

paulo1205
(usa Ubuntu)

Enviado em 02/06/2017 - 15:54h

Faça o seguinte, então: crie o seguinte script wrapper para o programa que você quer depurar, e tente executá-lo no terminal.

#!/bin/bash

exec </dev/null

exec >/tmp/output.$$

exec 2>/tmp/error.$$

#env

strace -o /tmp/trace.$$ -f -s1024 -p $$ &

sleep 1

exec setsid SEU_PROGRAMA ARGUMENTOS 

As três primeiras linhas com exec redirecionam os descritores normalmente associados ao terminal, e a ferramenta setsid provoca a execução do programa depois de dissociá-lo do terminal controlador e criar um process group novo (de modo que sinais enviados ao process group associado ao terminal não afetarão mais o programa). O strace, que executa como processo filho do script, vai provocar a captura de todas as chamadas de sistema executadas pelo script e seus demais descendentes.

Serão gerados três arquivos de saída, para você analisar, /tmp/output.pid, /tmp/error.pid e /tmp/strace.pid, que receberão, respectivamente, a saída padrão do programa, sua saída de erros, e as chamadas ao sistema executadas pelo script de wrapper, pelo programa setsid e, finalmente, pelo programa que você quer depurar.

Se o problema for realmente a falta de terminal, você provavelmente vai conseguir ver isso na saída do strace.

Também pode ser útil descomentar a linha que imprime valores das variáveis de ambiente (comando env). Se o fizer, elas serão jogadas dentro de /tmp/output.pid. Eventualmente, elas podem fazer diferença na execução do programa, talvez importando que sejam levadas para dentro da crontab.

Doug.linux
(usa Debian)

Enviado em 03/06/2017 - 08:45h

No cron voce esta colocando o caminho completo do PATH do executa.sh?
Ex:
/home/user/script/executa.sh

escomunal
(usa Red Hat)

Enviado em 05/06/2017 - 12:23h

yap, sempre, eu não uso cd em script... continua dando o problema, mas vou testar à tarde com a dica do Paulo

escomunal
(usa Red Hat)

Enviado em 06/06/2017 - 15:24h

Eta nóis que nunca apanhei desse jeito, to até com vergonha. mas vamos lá, executei conforme vc passou Paulo.

no trace são muitos bits pra escovar, e não cheguei a lugar nenhum, no entanto no error.$$ , quando executo na mão e finaliza com sucesso, tras somente a mensagem dos processos ex:

Process 29754 attached

No entanto quando coloco a mesma execução no cron ou no at aparece essa msg tb

tput: No value for $TERM and no -T specified

tentei adicionar o TERM no .cshrc mas dá pau logo no login

meu .cshrc , a linha do TERM está assim:

if ( ${?TERM} ) then
#stty erase
stty echoe
stty kill '^C'

echo TERM=$TERM
setenv term $TERM
endif

e quando logo no sistema:
Last login: Tue Jun 6 15:21:45 2017 from 172.19.3.104
TERM=xterm
xsmart$

paulo1205
(usa Ubuntu)

Enviado em 06/06/2017 - 17:49h

Fazia tempo que eu não via ninguém usando o csh.

Bom, se o programa precisa da variável de ambiente TERM, dê uma a ele. Possivelmente, “dumb” seria um bom valor.

Contudo, se o programa quer um terminal, será que ele deveria executar via cron?

Você sabe o que o programa faz?

escomunal
(usa Red Hat)

Enviado em 06/06/2017 - 18:28h

Tenho que manter o binario porque é do fornecedor do cliente , por mim já teria substituído por um shell, nada mais que um bocado de procedure escondidinha em C, mas não posso mexer nele, já foi dureza conseguir a fonte, na verdade estou colocando esses scripts via JOB/APS que desenvolvi aqui, e são muitos binarios, no entanto só um dá pau, é incrivel, executa na mão, vai ; no cron; dá falha de segmentação.

Já forcei carregar um set de variáveis, mas nada... to esfolando os miolos.

paulo1205
(usa Ubuntu)

Enviado em 06/06/2017 - 22:28h

O SIGSEGV tem alguma relação com o erro do tput, por falta de especificação do tipo de terminal?

Aquele wrapper que eu mostrei, acima, pode ser rodado via cron, também. Na saída do strace, investigue o que ocorre pouco antes do SIGSEGV.

Mas espere: você disse que tem o fonte?

escomunal
(usa Red Hat)

Enviado em 07/06/2017 - 10:13h

Tenho sim Paulo, mas é C , não consegui identificar muita coisa: Veja as linhas do erro com

/home/xmart/executa.sh: line 97: 21894 Falha de segmenta▒▒o

21894 fstat(3, {st_mode=S_IFREG|0755, st_size=3944, ...}) = 0
21894 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8764a5c000
21894 mmap(NULL, 2099840, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8760c90000
21894 mprotect(0x7f8760c91000, 2093056, PROT_NONE) = 0
21894 mmap(0x7f8760e90000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f8760e90000
21894 close(3) = 0
21894 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8764a5b000
21894 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8764a5a000
21894 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8764a59000
21894 arch_prctl(ARCH_SET_FS, 0x7f8764a5a700) = 0
21894 mprotect(0x7f87615e9000, 16384, PROT_READ) = 0
21894 mprotect(0x7f8761808000, 4096, PROT_READ) = 0
21894 mprotect(0x7f8761a23000, 4096, PROT_READ) = 0
21894 mprotect(0x7f8761cab000, 4096, PROT_READ) = 0
21894 mprotect(0x7f8761eaf000, 4096, PROT_READ) = 0
21894 mprotect(0x7f8764a65000, 8192, PROT_READ) = 0
21894 munmap(0x7f8764a5f000, 19668) = 0
21894 set_tid_address(0x7f8764a5a9d0) = 21894
21894 set_robust_list(0x7f8764a5a9e0, 24) = 0
21894 futex(0x7ffde4c6764c, FUTEX_WAKE_PRIVATE, 1) = 0
21894 futex(0x7ffde4c6764c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f8764a5a700) = -1 EAGAIN (Resource temporarily unavailable)
21894 rt_sigaction(SIGRTMIN, {0x7f8761811cb0, [], SA_RESTORER|SA_SIGINFO, 0x7f876181b7e0}, NULL, 8) = 0
21894 rt_sigaction(SIGRT_1, {0x7f8761811d40, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f876181b7e0}, NULL, 8) = 0
21894 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
21894 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
21894 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffddc30cee4} ---
21894 +++ killed by SIGSEGV +++

escomunal
(usa Red Hat)

Enviado em 09/06/2017 - 15:07h

Amigos, somente para não deixá-los sem resposta. Parte da nossa profissão é justamente aprender a contornar problemas quando esses se mostram graves e que podem ocupar muitas de suas preciosas horas.

Eu criei um novo script e o transformei em serviço (com nohup) e um segundo script no cron que gerencia esse serviço. Já está funcionando. Muito Obrigado a todos.

Rogério