PHP errors cause bounce, but Kayako works

[Destructo]

Similar to some problems I've seen here, I can send an email to the email address I've setup for Kayako that pipes the email to the cli script and Kayako properly opens a ticket. The problem is that the email simultaneously bounces because there are some PHP errors that I can't seem to hide. The errors are contained in the bounced email:

PHP Warning:  PHP Startup: U‰åWVSƒìè: Unable to initialize module
Module compiled with module API=20020429, debug=0, thread-safety=0
PHP    compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0

My host is completely incompetent and of course blame this on Kayako when it's obvious that it's a Zend module mismatch error.

Anyway, does anyone know how I could hide these startup errors so that the email won't bounce?

I've tried setting my piping to:

"|/home/site/www/support/cli/index.php > /dev/null"

but the email still bounces. If I move the > /dev/null part outside of the quotes, Kayako doesn't get the email and nothing bounces.

Any tips?

[John Haugeland]

I don't believe you could hide the pipe noise, short of making an intermediary which opens a second pipe to the real target and discards upchannel responses.

If I were you, I'd ask to speak to a supervisor at the ISP. That problem is going to cause memory leaks, which will become a stability problem.

[Destructo]

Thanks for the help, John. If I can't get them to resolve it properly, I'll end up writing a wrapper shell script to hide the output.

Hopefully that will work until I find the time to switch hosts.

[John Haugeland]

Ok.

[Destructo]

Here's the wrapper I've implemented in case anyone in the future has this problem:

#!/bin/sh
/www/support/cli/index.php "$@" > /dev/null 2>&1

That's just saved as "wrapper.sh" and I've changed my email forwarder to point to it. Works like a charm.

[Jamie Edwards]

Thanks for sharing that - I'm sure others will find it useful

[John Haugeland]

I do want to remind other people reading this thread, though, that the real problem is that PHP and Zend are out of sync, and that the real fix is what this customer's ISP refuses to do. That script is a last resort. Destructo realizes this, I believe, based on his comment about waiting until he has time to switch ISPs, but I want to make sure other people later who read this understand that as well. The out of sync problem has other consequences, and really should be fixed correctly.

It's quite a neat last resort, though.