pipe.php permission changed

MS1Corp

Things humming along without problems for months, then suddenly none of our inbound emails are getting piped (verified by the WHM Mail Delivery Log).
All have this common error:

Child process of virtual_address_pipe transport returned 127 (could mean unable to exec or command does not exist) from command:

We discovered that the permission on pipe.php was 644.
We changed it to 755, retested the pipe and it seems to work now

What happened? Our CPANEL is set to automatically upgrade osTicket for minor releases.
Was there a recent release that reset the permissions on this file?

Whats the difference between the pipe returning 127 vs 255 (we saw both codes in the log).

Thanks

KevinTheJedi

MS1Corp

I would never rely on that auto-upgrader. I would always do it manually; it's very simple to do.

To answer your question, no, the file perms did not change on that file. Last change was 4 years ago. Yet another reason why I wouldn't trust auto-upgraders.

Apparently 127 is command not found (ie. couldn't find a file, etc.) and 255 is script exit error (ie. it crashed).

Cheers.

MS1Corp

Thanks for the reply

Ok, so it seems that even though the file itself did not change, the upgrader did apply the default permissions (644). This was unexpected, probably due to inexperience on our part. In other words, we expect that if a file had a material change (as detected by a merge utility for example, only then would the file be replaced/merged and file permissions reapplied.

It seems that when the file permissions are set to 644, this is the error that others with similar pipe configuration will see (error 127, meaning that the pipe.php file wasn't executable). Suggest adding to documentation if convenient, so that others can grasp an actual symptom resulting from incorrect pipe.php file permission.

Either way, thanks, and this can be closed.