Skip to main content

Piped email to WHMCS getting bounce back

Adam Helman
Hi So, I have WHMCS installed under my domain which is on a VPS server running Cloudlinux. This supports multiPHP so I can have different domains running various PHP versions. For this domain and WHMCS I have PHP 7.0 and ionCube Loader 5.6 (which works for PHP 7.0 I believe). I set up the forwarders in cPanel to pipe emails to the WHMCS support area, ensuring they point to the correct PHP version (7.0) for that domain, and everything works fine (almost). An example of the forwarder pipe is: /opt/cpanel/ea-php70/root/usr/bin/php -q /home/yourscope/whmcsdata/crons/pipe.php After that set up, anyone raising an email to a support email address gets a notification of their ticket being opened. I as the admin get an email notification that a ticket has been raised, and the ticket is nicely there in the support area of WHMCS. Happy days. The trouble is, the customer sending that original email, as well as getting the correct notifications, also gets this weird bounced email that says:
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: pipe to |/opt/cpanel/ea-php70/root/usr/bin/php -q /home/yourscope/whmcsdata/crons/pipe.php generated by info@example.co.uk The following text was generated during the delivery attempt: ------ pipe to |/opt/cpanel/ea-php70/root/usr/bin/php -q /home/yourscope/whmcsdata/crons/pipe.php generated by info@example.co.uk ------ Failed loading /usr/local/IonCube/ioncube_loader_lin_5.6.so: /usr/local/IonCube/ioncube_loader_lin_5.6.so: undefined symbol: zval_update_constant_inline_change Action: failed Final-Recipient: rfc822;|/opt/cpanel/ea-php70/root/usr/bin/php -q /home/yourscope/whmcsdata/crons/pipe.php Status: 5.0.0
Now, I've looked everywhere for hours (including WHMCS docs) and did find a number of similar issues that have solutions around pipe.php permissions, or redirecting its output to NULL and a bunch of other things. None of these have worked, nor have they referenced the loading ionCube being part of the problem, or the fact I have multiPHP environment. Given all is actually good, I simply wanna stop that bounce and the path of the ionCube loader is correct. Anyone have any ideas please as to why it's complaining, and what I can do to either fix it or suppress it? Many thanks.

Comments

5 comments

Date Votes
  • Infopro
    I have PHP 7.0 and ionCube Loader 5.6 (which works for PHP 7.0 I believe)

    The docs are your friend: System Requirements - WHMCS Documentation Ioncube Loaders: The latest 6.x version for PHP 7
    0
  • Adam Helman
    The docs are your friend: System Requirements - WHMCS Documentation Ioncube Loaders: The latest 6.x version for PHP 7

    Yes indeed - you are of course right. And to clarify I am actually using ionCube 6.1.0 (I misquoted taking the version from the bounced email - my apologies!). Of course, if I wasn't using the right ionCube Loader, I wouldn't even be able to get WHMCS up and running with PHP 7.0, let alone pipe to it! But regardless, apologies again for giving out some garbage info (blush). From my PHP 7.0 info: Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v6.1.0 (), Copyright (c) 2002-2017, by ionCube Ltd. with Zend OPcache v7.0.22, Copyright (c) 1999-2017, by Zend Technologies
    The path in the bounceback email refers to 5.6 - so somewhere it is clearly defaulting to the standard PHP build and not the PHP 7 build (which uses the correct ionCube Loader) - so I guess the ideal is to give a replacement path that is specific to the PHP 7.0 build, like the forwarder. But anyone know where I can do that?
    0
  • cPanelMichael
    The path in the bounceback email refers to 5.6 - so somewhere it is clearly defaulting to the standard PHP build and not the PHP 7 build (which uses the correct ionCube Loader) - so I guess the ideal is to give a replacement path that is specific to the PHP 7.0 build, like the forwarder. But anyone know where I can do that?

    Are you using any custom php.ini files within the affected account? There's also a thread you may want to review at: Issue with piping Thank you.
    0
  • Adam Helman
    Thanks for the reply. I don't believe there is anything customised with php.ini over and above the weird thing Cloudlinux sets up MultiPHP. Regardless, the link you gave looks like that might be helpful as that too looks like it involves MultiPHP. Will have a look in more detail and report back in the next day or so. Thanks again.
    0
  • Adam Helman
    Ok fixed it - thanks for the pointer! In case anyone else has a similar problem. That link you gave mentioned about the local.ini file used in MultiPHP. My error was different - so I didn't follow that chap's suggestion - however it made me think about that ini file. When I looked at the one for PHP7 the local.ini file was pointing to the wrong ionCube for PHP 7.0. Hence it spitting out a PHP error. Changing the local.ini file by commenting out the ref to the wrong ionCube loader (via the "MultiPHP INI Editor" sidebar option in WHM for PHP 7.0) solved this:
    ;zend_extension="/usr/local/IonCube/ioncube_loader_lin_5.6.so"
    MultiPHP had a one line ini for the correct loader, but I think the order in which these piecemeal ini files are loaded / read meant that the 5.6 loader line was the last one read, overriding the correct loader line. Anyway - all is at one in the world once more.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post