Scheduled Jobs Not Working Properly

[tobias]

Hey guys,

Until today, all scheduled jobs had been working just fine. A couple of hours ago, the job to load group emails no longer executes (all others do just fine).

The log file shows theses errors (repeatedly):

[2016-05-31 16:40:01] Espo.WARNING: E_WARNING: chgrp(): Operation not permitted {"code":2,"message":"chgrp(): Operation not permitted","file":"/www/htdocs/w01005e6/crm/application/Espo/Core/Utils/File/Permission.php","line":409} []
[2016-05-31 16:40:01] Espo.ERROR: EmailAccount 573d8d871354902ae (Select Folder) [0] cannot change folder, maybe it does not exist [] []

NB: The personal email account 573d8d871354902ae is an active account in table email_account and loads just fine (see screenshot attached) whereas group email account stopped loading (see other screenshot attached).

Any ideas?

Thanks so much,

Tobias

[yuri]

Hi

You got the explicit error message in your log. Try to investigate it.

[tobias]

Ok, I was able to fix the EmailAccount error, which was related to an unreadable IMAP folder.

The other error leaves me puzzled.

I found a thread in the forum (http://forum.espocrm.com/forum/gener...-not-permitted) stating that I should activate chgrp on our server. However, the server is running in CGI mode and hence, permissions haven't been a problem at all - until yesterday, although we hadn't changed any server settings.

Could you please explain, what files should have a different group and owner?

- Tobias

[yuri]

644 for files, 755 for folders
Except data, data/*, custom/*
They should be 664, 775

[tobias]

I've executed these commands in terminal, as explained in your setup instructions:
find . -type d -exec chmod 755 {} + && find . -type f -exec chmod 644 {} +;
find data custom -type d -exec chmod 775 {} + && find data custom -type f -exec chmod 664 {} +;

However, the cronjob to load group emails still won't execute every minute (or when calling php cron.php manually).

Any help would be much appreciated!

[yuri]

Check server's error log.

[tobias]

I'm afraid we don't have access to the server logs.

And permissions seem to be just fine (see screenshots), so...

Why is the cronjob for fetching personal emails working properly then?
How is the latter any different from the cronjob fetching group emails?

[yuri]

Error log (not espo error log) could help.

[tobias]

We've activated error logging for PHP but no errors have been logged so far (I assume this is due to ESPO trying and catching PHP errors).

The weird thing is that the cronjob is running (and fails) every 2h 11m (see screenshot), although it's been scheduled to run every 10 minutes.

FYI: Since we're not permitted to access our server's crontab file, we've setup a server cronjob that calls a phpx every 10 minutes and looks like this:

 [FONT=Monaco][SIZE=10px]<?php[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  exec("/usr/local/bin/php /www/htdocs/w01005e6/crm/cron.php  2>&1", $out, $result);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  echo "Returncode: " .$result ."<br>";[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  echo "<pre>";[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  print_r($out);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]?>[/SIZE][/FONT]

Also, let me stress once more that the job for fetching personal accounts is executing just fine (see other screenshot attached).

Besides, I've checked older ESPO error logs and Espo.WARNING: E_WARNING: chgrp(): Operation not permitted already existed for months without causing any problems (our server provider does not allow chgrp due to security restrictions).

That said, I believe the error message and the weird cronjob behaviour are not related and there's some other problem.

Any ideas to get this up and running again?

- Tobias

[yuri]

You can change your crontab definition to something like
* * * * * php cron.php > /path/to/log.log 2>&1 And then you will be able to see if any error occurs.

Usually such errors not catched by EspoCRM and should be in apache error log.

[tobias]

This is what http://crm.pinpoll.com/bridgeCRM.phpx looks like:

 [FONT=Monaco][SIZE=10px]<?php[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  exec("/usr/local/bin/php /www/htdocs/w01005e6/crm/cron.php  2>&1", $out, $result);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  echo "Result Code: " .$result ."<br>";[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  echo "Script Output: " ."<br>";[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  echo "<pre>";[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  print_r($out);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]
  //Your suggested code doesn't log any error[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]  exec("php /www/htdocs/w01005e6/crm/cron.php > /www/htdocs/w01005e6/crm/errorlog.txt 2>&1", $out, $result);[/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px] [/SIZE][/FONT]
  [FONT=Monaco][SIZE=10px]?>[/SIZE][/FONT]

cron.php executes just fine, no errors printed or logged - but still, only private email accounts are being fetched and there's no log in ESPO that group email fetching was even triggered the very time we'd executed the cronjob.

I really think there's something wrong with the setup of scheduled jobs in ESPO.

I know it's hard to debug without any error messages, but maybe you've got any other ideas?

- Tobias

[yuri]

1. Remove all records from job table with status = 'Running'. This will allow suspended job to be run again. It can be done via UI Administration > Scheduled Jobs > Jobs in the top-right menu. Or link: http://crm.pinpoll.com/#Admin/jobs
2. Run your script. Do it quickly before cron is run or deactivate it for this test.

[tobias]

Done and now, that's some really interesting output:

Result Code: 255
Script Output:

Array (
[0] => PHP Fatal error: Class 'Espo\Core\Mail\Mail\Storage\ErrorHandler' not found in /www/htdocs/w01005e6/crm/application/Espo/Core/Mail/Mail/Storage/Message.php on line 154
[1] =>
[2] => Fatal error: Class 'Espo\Core\Mail\Mail\Storage\ErrorHandler' not found in /www/htdocs/w01005e6/crm/application/Espo/Core/Mail/Mail/Storage/Message.php on line 154
)

What to do?

- Tobias

[yuri]

Try this fix: https://github.com/espocrm/espocrm/c...937f6353f16cef

And remove Running jobs one more time.

[tobias]

Hooray - it's working again

Thanks so much for your support and have a great day ahead!