O script Perl não é executado corretamente no crontab ou no shell script

Question

Eu tenho um script Perl (que veio com meu software discador Vicidial) que funciona perfeitamente na linha de comando do Linux. Ele envia um email no final do script.

O script não cria nenhum erro e todo o script até o sendmail (https://metacpan.org/pod/Mail::Sendmail) funciona corretamente quando executada no crontab e em um executável de script shell (executando como root), porém o e-mail não é enviado.

Qual é a diferença entre executar o script em um executável bash e em uma CLI bash? A função sendmail não está gerando nenhum erro, por que simplesmente não envia?

Aqui estão dois trechos de código relevantes do script Perl:

use MIME::QuotedPrint;
use MIME::Base64;
use Mail::Sendmail;

if (length($attachment)>0) {
    #print $mail{body};
    sendmail(%mail) or die $mail::Sendmail::error;
    #print "error: ";
    #print $mail::Sendmail::error;
}

É assim que executo o script:

/usr/share/astguiclient/AST_email_web_report.pl --email-subject=XXXX--email-list=XXXX --email-sender=XXXX --date=XXXX

Answer 1

De modo geral, "funciona no shell de um usuário, mas não a partir crontab(ou no shell de outro usuário)" significa que o problema é causado pelo programa que depende de configurações de ambiente (muitas vezes PATH) que o primeiro usuário possui, mas são diferentes ou ausente no cronambiente e no shell do outro usuário.

Se eu estivesse na situação que você descreve, a primeira coisa que eu faria seria revisar o código Perl, porque Perl é minha praia, e então colocaria um print "Back from sendmail\n";comando imediatamente após o sendmail(%mail) or die, apenas para ter certeza absoluta de que o programa não é saindo silenciosamente ao tentar enviar o email. Mas presumo que você provavelmente já cobriu essas bases da melhor maneira possível.

A próxima coisa, então, é executar o envcomando no shell para o qual ele funciona e passar pela saída para quaisquer configurações que pareçam relevantes e, em seguida, tentar transplantar essas configurações para o ambiente shell do root para ver se elas recebem o e-mail trabalhando lá. Depois de identificar as configurações que fazem com que funcione para o root, você também pode colocar essas mesmas configurações no crontabarquivo e isso também deve ser corrigido.

Outro caminho que você poderia investigar seria verificar tail -fo log do seu servidor de e-mail para ver se ele pode estar recebendo a mensagem e depois descartando-a (ou devolvendo-a), mas isso parece um tiro no escuro e exige que você tenha acesso ao e-mail apropriado. logs do servidor. Problemas ambientais parecem muito mais prováveis, a menos que você esteja recebendo devoluções de tentativas de e-mail com falha. (Verifique a caixa de correio do root para eles, se ainda não o fez!)

Answer 2

Descobri um bug no script fornecido que permitia que uma opção fosse ativada quando não deveria. Agora tudo está funcionando normalmente.