#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

#### In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

# Cron.php not fetching mails

Hi,

I've gone through many articles before logging this. It seems my cron job for mail fetching has stopped working. I've been testing manually running the job and still no mails are being fetched. Here is the output I get when I run the manual job.

C:\wamp\bin\php\php5.5.12>php.exe -f c:\wamp\www\helpdesk\api\cron.php

Strict standards: Non-static method osTicket::is_cli() should not be called statically in C:\wamp\www\helpdesk\include\class.osticket.php on line 471

Call Stack:
0.0003     230712   1. {main}() C:\wamp\www\helpdesk\api\cron.php:0
0.0007     234848   2. require('C:\wamp\www\helpdesk\api\api.inc.php') C:\wamp\www\helpdesk\api\cron.php:17
0.0012     250544   3. require_once('C:\wamp\www\helpdesk\main.inc.php') C:\wamp\www\helpdesk\api\api.inc.php:23
0.0026     383136   4. require('C:\wamp\www\helpdesk\bootstrap.php') C:\wamp\www\helpdesk\main.inc.php:23
0.0111    1206168   5. osTicket::get_root_path() C:\wamp\www\helpdesk\bootstrap.php:325

• I'm not seeing a version of osTicket.  I am not seeing an error.
• edited May 2016
Hi,

Sorry I forgot about the version. It is below. The problem is that I'm not seeing any errors either, yet for some reason cron.php is not automatically logging into the mailbox and fetching the mails. When I use auto-cron and login to the interface it pulls the email successfully. What I've shown above is that even when I manually run it, the mail/ticket is not fetched by the cron job. I've updated to the latest release to see if it would help, but it has not helped.

Server Information
osTicket Version    v1.10-rc.2 (231f11e) — Up to date
Web Server Software    Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
MySQL Version    5.6.17
PHP Version    5.5.12
PHP Extensions
gdlib    Used for image manipulation and PDF printing
imap    Used for email fetching
xml    XML API
xml-dom    Used for HTML email processing
json    Improves performance creating and processing JSON
mbstring    Highly recommended for non western european language content
phar    Highly recommended for plugins and language packs
intl    Highly recommended for non western european language content
fileinfo    Used to detect file types for uploads
PHP Settings
cgi.fix_pathinfo    "1" is recommended if AJAX is not working
date.timezone    Africa/Johannesburg
Database Information and Usage
Schema    ost (localhost)
Space Used    15.97 MiB
Space for Attachments    10.11 MiB
Timezone    South Africa Standard Time (Interpreted as Africa/Johannesburg)

moderator note: removed your formating from server information.
• 1.10rc2 is a Release Candidate and should not be run in a production environment.

That being said:
First thing I would do is reenter the username/password in the email settings.
Then I would enable debug mode in osticket->settings. And see if anything showed up in the logs.
Failing that I would go to the mail server and consult the logs to see what the problem is.
• Hi there,

I'm still running this in a testing environment and wish to go live by mid-June. I've tested what you've asked and I don't see any logs even though debug has been enabled.

Can you explain how auto-cron differs from the cron.php? I assume it is using the same method as cron.php, but when auto-cron runs, it successfullt retrieves the mail and emails the ticket.
• I'm not a developer but it is my understanding that they run the same way.
• Ok that being said, I don't believe the problem exists with the mail server. Could the issue be with PHP or my cron.php file?
• It's more likely that your cron or windows task scheduler is calling cron.php wrong, or that you have more then once version of PHP installed and the call is using the wrong version.
• To rule out the task scheduler I've been running the command manually. Is this call correct: C:\wamp\bin\php\php5.5.12>php.exe -f c:\wamp\www\helpdesk\api\cron.php

Also, I've checked there is only one version of PHP installed and I am running it from within that directory.
• to emulate the call you should use:

>  C:\path\to\php.exe -f c:\wamp\www\helpdesk\api\cron.php
• Hi there,

Yes I am running the command correctly as you have shown here. Still not working.
• Admin panel -> Settings -> Emails -> Email Fetching checked?
• Yes that is ticked as well...
• I have seen this behavior when for example the (windows) firewall on the wamp server is activated:

the cron call will be logged as successful, the command line output shows no error but the email won't be fetched. Disable the firewall temporarily to see if this has a affect.

Then you could define an ingoing rule (advanced firewall settings) to allow those connections for the program "php.exe" and reactivate the firewall..
• Hi there,

The firewall was already disabled, but going a step further on your premise, I also tried disabling the anti-virus on the server. Unfortunately, still the same issue.

Has this gotten to the point where I should redo the installation? Perhaps the files that the cron job is calling are problematic which I will also take a look at.

• can you consult your mail server logs and see if the connection is being attempted and failing (which would also tell you why)?
• I've checked now and when I log into the web interface as an agent, the pop3 connection happens. When running it using cron.php, no connection is made. Any other suggestions please?
• What I've now done is run a packet capture on the server for any pop connections. When I login, it performs a connection to the pop server, however, when I run cron.php, no connection attempts are made. Clearly my call is not working correctly.
• edited May 2016
If you setup your cron call correctly.
disabled auto-cron.
configured and enabled the email.
and have Admin panel -> Settings -> Emails -> Email Fetching checked
then it should be working. I'm not sure why you would have issues with this.
I've never had a problem with this personally.
• No sure what else to try here. I've done several tests now with Wireshark. Every time I run cron.php, no attempt to connect to the POP3 server is made, though when I use auto-cron, the attempt is made successfully and I can see the conversation in Wireshark.
• Does it work in previous versions?
• It was working after I enabled it and I did not make any version changes, then on the 29th of April, it stopped working and has not worked since. I performed the upgrade on 3rd of May to see if it would help, but still nothing.
• "and I did not make any version changes, then on the 29th of April, it stopped working"

Did someone upgrade PHP on the server?
• No, no changes were mad to the server until I did the upgrade.
• There is a tutorial about setup osticket cron job at https://www.easycron.com/tutorials/how-to-set-up-cron-job-for-osticket , may be help you.
• Hi Annie,

This does not seem to be working either. When I manually run the /api/tasks/cron it shows "URL Not Supported", this I believe is because inside my /api directory, there are only the script files and no further folders.

I have the following configuration:

#!/usr/bin/php -q
<?php
/*********************************************************************
rcron.php

PHP script used for remote cron calls.

Peter Rotich <peter@osticket.com>
http://www.osticket.com

Released under the GNU General Public License WITHOUT ANY WARRANTY.

vim: expandtab sw=4 ts=4 sts=4:
**********************************************************************/

# Configuration: Enter the url and key. That is it.
#  key => API's Key (see admin panel on how to generate a key)
#

$config = array( 'url'=>'https://{mydomain}/api/tasks/cron', 'key'=>'{somekeycodehere}' ); #pre-checks function_exists('curl_version') or die('CURL support required'); #set timeout set_time_limit(30); #curl post$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$config['url']);
curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, '');
curl_setopt($ch, CURLOPT_USERAGENT, 'osTicket API Client v1.7'); curl_setopt($ch, CURLOPT_HEADER, TRUE);
curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Expect:', 'X-API-Key: '.$config['key']));
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, FALSE); curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
$result=curl_exec($ch);
curl_close($ch); if(preg_match('/HTTP\/.* ([0-9]+) .*/',$result, $status) &&$status[1] == 200)
exit(0);

echo \$result;
exit(1);
?>

• You can't use the url ../api/tasks/cron to test the r(emote)cron.
You have to call the rcron.php to test it.

../api/tasks/cron is a virtual url. You will not find a file or folder under this path.
• Yes sorry I forgot to add that portion. I have been using easycron as suggested by Annie above. The reason I mentioned the URL was because I couldn't find it. Here is the output from easycron:

HTTP/1.1 200 OK
Date: Wed, 18 May 2016 23:57:23 GMT
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
X-Powered-By: PHP/5.5.12
Content-Length: 19
Content-Type: text/html

#!/usr/bin/php -q

• This looks to me that the rcron is working like it should.
An example output from my instances when the rcron is executed successful:

HTTP/1.1 200 OK
Date: Thu, 19 May 2016 10:13:02 GMT
Content-Type: text/html
Content-Length: 18
Connection: keep-alive
Server: Apache

#!/usr/bin/php -q

When it still doesn't fetches the emails, something must prevent the cron call and I don't think it is coming from osticket. Like a firewall or something else, I guess you have to examine you environment deeper to see why this happens, for example with wireshark..
• I've done several tests now with Wireshark. Every time I run cron.php,
or rcron runs, no attempt to connect to the POP3 server is made, though when I use
auto-cron, the attempt is made successfully and I can see the
conversation in Wireshark.
• In my tests with wireshark and a disabled windows firewall I can see the communication with the mail server after triggering autocron, cron or rcron.

When the firewall is enabled I don't see this communication.

I can't imagine why only autocron is working correct. Normally the reason for that behavior is a wrong usage of cron or rcron but your configuration/usage looks fine. Without any error or useful hint it will be hard to find the reason for that behavior.