vicidial.org

Web based GUI:
VERSION: 2.12-560a
BUILD: 160617-1427

Command line info:
ViciBox v.7.0.3-160505

Hi, I have modified AST_email_web_report.pl for my needs and it works fine when I run it manually but it appears that the sendmail function within the script is not executing when I try to run the script from within crontab. Is this normal on a ViciBox installation? Any ideas on what is causing this?

cron's "root" and your "root" are not the same. the shell is different. use full paths to all executables and scripts. specify the executable file by invoking it directly instead of letting the script specify the executable.

also check the os logs (journal or log files) AND the "root mail" usually /var/mail/root to see if errors are landing that may explain your issue.

Good job posting both your installer and vici with build

Thanks William, yeah doing some research last night I came to the conclusion that it was likely a shell/path/environment issue.

It's just a standard install of ViciBox so it would be great if someone could try to provide instructions for a fix because it can't just be me that has encountered this issue.

It appears that the Mail::Sendmail module is having an issue when run from crontab.

ah, but it CAN be you if you broke it and now must fix it, since it works for everyone else out of the box. for instance, something as simple as an IDE that removes the execute bit from perl files when they are edited. all sorts of things can go wrong. unless you're saying that a cronjob that was installed by vicibox failed to fire without any modifications first ... the problem is in fact you.

It isn't something that works out of the box without a manual crontab entry being added.

I'm just following these instuctions that mflorell wrote:

http://www.eflo.net/VICIDIALforum/viewt ... =2&t=29155

"We did create the AST_email_web_report.pl script to do this, and that script is included in the VICIdial codebase, but you need to copy and customize it for every report that you wish to run, as well as putting an entry for it in the crontab."

Can you please confirm William that this script AST_email_web_report.pl works for everyone else (email is sent) when it is working in the command line and then they put an entry for it in crontab?

Running AST_email_web_report.pl from the command line works wonderfully.

I have tried these entries in crontab with no success:

1 23 * * * /usr/bin/perl -I /usr/lib/perl5/vendor_perl/5.18.2 /usr/share/astguiclient/AST_email_web_report.pl --email-subject=xxxx --email-list=xxxx --email-sender=xxxx --date=2019-06-29

1 23 * * * bash -l -c 'perl /usr/share/astguiclient/AST_email_web_report.pl --email-subject=xxxx --email-list=xxxx --email-sender=xxxx --date=2019-06-29'

I've now determined that the encode_base64 function is working when run from crontab so I assume that the modules are running ok in the perl script in crontab. So no idea why the sendmail function is not sending email...

nothing in the cron log? nothing in the root email?

cron log says it executes normally

root email gives me cron output which is the same as if I run it from the command line, when I put a print statement in the script I can see that everything is working ok up until the sendmail function when running as a cron job

It just doesn't send the email when running as a cron job.

I just put the script command in a bash script executable file and that also does the same thing (when executed manually via CLI), no email sent despite normal output. It only works when I enter the script command manually.

To be clear: You execute these two lines in the CLI when logged in as root (not sudo to root, but logged in as root) and they work. But when you execute them in cron (with times), they "claim" to succeed, but they actually don't send the mail? (giving identical output, checked with DIFF)

Code: Select all

/usr/bin/perl -I /usr/lib/perl5/vendor_perl/5.18.2 /usr/share/astguiclient/AST_email_web_report.pl --email-subject=xxxx --email-list=xxxx --email-sender=xxxx --date=2019-06-29

bash -l -c 'perl /usr/share/astguiclient/AST_email_web_report.pl --email-subject=xxxx --email-list=xxxx --email-sender=xxxx --date=2019-06-29'

Next up: Since this script expects to send mail using a mail executable (sendmail, mail, postifx, whatever ...) I would expect there to be some sort of log for the mail package in question.

There should also be a response in the script that comes from the mail package being executed, which should be part of the log and/or email for root.

Those two lines are lines that I tried in crontab to see if it was a path related issue.

This is the line that runs fine in the CLI but not in a bash script file or in crontab:

/usr/share/astguiclient/AST_email_web_report_1stenergy_saves.pl --email-subject=XXXX--email-list=XXXX --email-sender=XXXX --date=2019-06-29

Try the ones you used in cron. If they are different, why are they different? If they fail on the CLI, they should also fail in cron. You could also consider running a screen with the sh shell instead of the bash shell to see if you can decipher the issue. You can also try running the script in a screen for fun (simulate the method Vicidial uses to fire up a screen and push a command into it).

And you skipped over the "Next up" stuff I posted.

AST_email_web_report.pl, one of the Vicidial scripts uses Time::Local, MIME::QuotedPrint, MIME::Base64, Mail::Sendmail.

https://metacpan.org/pod/Mail::Sendmail

I think this is the module.

error and log don't return anything when I print them.

I have already stated that the two lines that I tried in crontab were to see if it was a path related issue. Why would I try to use them in the CLI? The line I posted above works fine in the CLI.

It would be great if someone could confirm if this script has been tested in crontab because this is a standard Vicibox install.

I really appreciate your assistance though WIlliam.

If the command that doesn't work in cron also doesn't work in the CLI, perhaps the reason it doesn't work in the CLI could be fixed and perhaps that reason would also apply to the crontab.

Or I suppose you could continue to execute it from the cli instead of cron. (which may work in a screen as I suggested, since the screen could be executed ... from cron).

Good Luck.

This was the code in the perl script:

if ($args =~ /-q/i)
{
$q=1; $Q=1;
}

I had a "-Q" sequence in my email subject line option! OMG! So I changed the code to this:

if ($args =~ /--quiet/i)
{
$q=1; $Q=1;
}

and now everything works. If Vicidial is still using this script I would suggest fixing this bug.

so ... it works if you use -q insted of -Q?

Is there documentation? Does it say to use -Q or -q or --quiet?

The "-Q" string was part of my email subject line, part of "Retention-QA", it was triggering the --quiet option because the --quiet option was looking for a case insensitive -q. I don't know why the email was then not being sent, perhaps because the rest of the options were not being read correctly.

In the script it says to use --quiet.

I just tested this all again and replicated the issue when it's run through crontab and the script is changed to -q. It is a mystery to me because the script with -q sends the email when run from the CLI but when the script has -q instead of --quiet then it will not send email when run in crontab.

deleted message

Hmm :-/ now it is working from crontab with -q option coded in script... Do perl scripts ever get cached?

tim33 wrote:Hmm :-/ now it is working from crontab with -q option coded in script... Do perl scripts ever get cached?

nope. nor does crontab.

it's a pretty good way to tell you are progressing as a software engineer. you're absolutely positive you've lost your mind. you're half way there

Thanks William

Hahaha, I moved away from full time coding to telesales. I thought people might be easier than computers... The reality is that both will make you second guess your sanity some of the time...

I improved the deliverability of emails last night by using the ISP's smtp server and sending from an @isp address, maybe that helped... The weird thing is is that when the -q script is run from crontab if the email comes through there will be a delay of 5-20 mins whereas when I run the script from the CLI or from crontab with --quiet script change the email comes instantly...

I really don't like not understanding the issue totally but all is working well now so I'll probably leave it at that.

look at the raw emails when they come in using both methods. diff them to see if there is any tiny technical difference. if there is no difference, then the delay is likely your imagination.