Cron jobs fail with status 255: how to debug php cli?

[cri]

After upgrading from 4.2.8 to 4.3.4, my civimail cron jobs (set up with the PHP cli method) stopped working; I didn't pay much attention to it, since it was a test installation, but now I now need to have it working, so I upgraded to 4.4 and reviewed my setup, but the problem persists.

I already double-checked the cron setup as per:
http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMail+Installation
http://wiki.civicrm.org/confluence/display/CRMDOC/Managing+Scheduled+Jobs

...but the cron jobs just exit with status code 255 (i.e. the PHP generic error code) and no specific error message.

I've tested the following:

- Running the cron command line manually: I get the same result (so it shouldn't be a problem in the system cron setup), both as the user running the web server, and as root (so it shouldn't be a permissions problem)
- Enabling CiviCRM "Debugging" mode, but no logfiles were created in the "ConfigAndLog" directory (I guess that's only useful to debug the web UI?)
- Running the cron jobs via the web UI (Administer CiviCRM » Scheduled Jobs), and via wget URL: they work OK! So there are no errors in the CiviCRM setup (user, password etc)

So it seems the problem is with the PHP CLI; I compared the CLI's php.ini file wrt the apache module php.ini file, but I couldn't spot relevant differences.

I raised the error_reporting level in the php.ini file, and I also tried adding some error_reporting() statements to cli.php and other files called by the cron jobs, but I can't seem to get any useful error message from PHP.

I am not familiar with the CiviCRM PHP error handling internals: can anyone suggest how I can enable detailed error reporting, so that I can get some more feedback when I run the PHP CLI (rather than the generic 255 exit status)?

(btw: the cron  jobs I'm trying to run are civimail's fetch_bounces and process_mailing; other system info: drupal 7, php 5.3.3, Debian squeeze)

[Donald Lobo]

1. can u check and see if there is a ConfigAndLog directory in /tmp

2. based on the below, it seems like it either is a bootstrapping the CMS issue or permissions on templates_c

in general, we've had trouble getting a better handle on these issues and they seem very system specific. we need to add more error messages and debugging code in these files (IMO)

lobo

[cri]

1. can u check and see if there is a ConfigAndLog directory in /tmp

No, it is in its right place (by Debian standards): /etc/drupal/7/sites/default/files/civicrm/ConfigAndLog
and contains some old logfiles related to past errors (all related to the web interface usage, no CLI)

2. based on the below, it seems like it either is a bootstrapping the CMS issue or permissions on templates_c

AFAIK, templates_c seems to have the right permissions (and also contains plenty of stuff).

in general, we've had trouble getting a better handle on these issues and they seem very system specific. we need to add more error messages and debugging code in these files (IMO)

I'll be glad to help, if anyone can point me to some example of debugging code in CiviCRM, I can try to add it to the relevant PHP files.
(for the moment I will use wget-style cron jobs)

[Donald Lobo]

You can ping us on irc and we can help u get started

the basic method would be to add debug statements till you see the point where it fails.

going forward, we should trap those errors as we encounter them (the last one i remember, it was smarty failing internally and we did not get a chance to recover)

lobo