I just upgraded to 1.8 RC and the system will not fetch any new emails since the upgrade. Is there any specific place i should look to get this working again?

12 days later

Has anyone else run into this issue since upgrading? I updated to the GA release and i still cannot get the system to fetch new emails using task scheduler. It was working great on 1.7.3 and stopped when i upgraded to 1.8. If i enable autocron in the admin panel it will fetch the email but that requires someonre to be logged in at all time to work.

If autocron polls and collects your emails, then I would think that the problem is with your task scheduler or the way its calling the cron.php.  You would need to post the details of that setup for us to be of further assistance.In general please remember to help us to help you, by reading and following the posting guidelines in this thread.

the detail of task scheduler are shown belowI have an action set to run a script/program which call up the php.exe program via "C:\Program Files (x86)\PHP\php.exe" and the i added an argument that points to the cron.php file via C:\inetpub\wwwroot\ticket\api\cron.phpEverything worked fine until i did the update and then it stopped. Nothing in the task scheduler setup has changed.Thanks for your help thus far

I am having the same issue.I am unable to fetch mail using POP/IMAP polling. Poll on auto-cron is working just fine, so the email configuration is correct, but I am receiving the T_FUNCTION...bootstrap.php line 233 error when I look at the error_log in the api folder. I understand that this is usually a result of not running the appropriate version of php, but in this case I am running 5.4.20 which should be OK. I have tried specifically calling a 54 php.ini file via php -c in cron which does not help. The error I receive from Cron Daemon is Status: 500 Internal Server Error.Any help would be greatly appreciated. osTicket Version.8.0Mail Sending: phpMailMail Fetching/Receiving: IMAPPHP version: 5.4.20Operating System: linuxThank you.

To anyone with the same issue - I was able to fix this by prefixing the cron statement with the following:/usr/php/54/usr/bin/php

By default cron CLI was running PHP 5.2.17

I am having the same issue after upgrading to 1.8.

Auto-cron is fetching the mail, but fetching mail by using task scheduler and cron job is not.

No errors are reported in the event viewer, but when I pipe the result of running the job to a log file I see

"kwaheri rafiki!"

osTicket Version: 1.8.0

Mail Sending: phpMail

Mail Fetching?REceiving: IMAP

PHP Version: 5.5.1

Operating System Windows 2008 R2

 

 

Managed to fix my issue by adding

define('ROOT_PATH', '/');

to /include/ost-config.php

Managed to fix my issue by adding

define('ROOT_PATH', '/');

to /include/ost-config.php

Where did you add this lie on the ost-config.php file. What section?

My osTicket install is also not fetching emails since the upgrade to 1.8 or 1.8.0.1. My knowledge of Linux is, shall we say, limited at best. Wouldn't know what to look for in logs.

Hello!I have been lookin all over for a solution to this... loosing hope :-(I have added; define('ROOT_PATH', '/'); to /include/ost-config.phpI have manually run the cron/php from a dos prompt. Can confirmed that I am running php >5.3.0 (see below)I can confirm that auto cron works fineCan confirm this has never worked on my osTicket install from day one. I am on 1.8 of osTicketHere is from my manual running from a batch file;C:\xampp\php>php.exe --versionPHP 5.3.8 (cli) (built: Aug 23 2011 11)Copyright (c) 1997-2011 The PHP GroupZend Engine v2.3.0, Copyright (c) 1998-2011 Zend TechnologiesC:\xampp\php>php.exe c:\xampp\htdocs\osTicket\api\cron.phpkwaheri rafiki!Any suggestions where to go next, logs to check? Thank you!

Anyone have an idea? Really at a loss here? 

First thing I would change is in bootstrap.php:        #Don't display errors -> DO display errors..         ini_set('display_errors', 1);        ini_set('display_startup_errors', 1);You can turn them back when you get it going, but you actually want to see where it breaks.That looks like its trying to determine if the current script is being run directly, and should rightly produce an error, however, it shouldn't be doing it from the API/Cron.. hmmIt appears the method used to determine this has changed:New (1.8)#Disable direct access.if(isset($_SERVER)        && !strcasecmp(basename($_SERVER),basename(__FILE__)))    die('kwaheri rafiki!');Old (1.7)    #Disable direct access.    if(!strcasecmp(basename($_SERVER),basename(__FILE__))) die('kwaheri rafiki!');You could try putting the old one in and see if it works.. Or add a check for $_SERVER as that should be populated for the cli env.. 

I added your bootstrap suggestions.About the only thing I am seeing is; (From php log) PHP Notice:  Undefined index: HTTP_HOST in C:\xampp\htdocs\index.php on line 7

wait, what? Index.php.. no, cron should be calling /api/cron.php not the client index page.

Sorry, I was not clear...Yes I am calling /api/cron.php using windows task scheduler... I just noted the above was the only error I saw in the PHP log.Im beginning to think that my initial 1.7 installation was not fully right. So far nothing I have done makes the cron work. Only time I get emails into osTicket is if someone is logged on. 

If cron works from dos, I'd suggest permissions were wrong, can the user on the scheduled task run php and read/execute the file? Upgrading might have cleared any ntfs permissions you initially configured...

Do you get any errors in the scheduler log?

I have reverted back to osTicket 1.7-gitI do not have the necessary programming skills to fix 1.8x. I am unable wait any longer with an install which does not notify of new incoming support requests. Will be checking back to see status on this, to me, important issue.

instead of C:\xampp\php>php.exe c:\xampp\htdocs\osTicket\api\cron.php

tryC:\xampp\php>php.exe -f c:\xampp\htdocs\osTicket\api\cron.phpI've also never had much luck running xampp... every couple years I try it again and it appears to still have odd ball problems that I do not encounter when I manually install things.