How PHP Process Control went wrong

Well, with the occurrence of reading week I’ve been a bit behind on my blogging. When I last wrote about PHP Process Control, all seemed fine and dandy. A simple call or two, maybe a foreach loop after to process lines of output, nothing majorly wrong. All the theory worked. After experimenting with it though, I found a few issues.

Firstly, processing control is handled very differently on different operating systems. Windows is fairly do-it-itself without much worry of permissions, groups, ownership or pathing. When getting things to work in a *NIX environment however, a bit of debugging was involved.

Actually, a lot was and all I had to go off of was an OS return code and a great many googlings.

Lesson 1: Pathing and the 127 Return Code

What is the 127 return code above? That’s the first of many issues I ran across: inability to find the process.

There is that trap every Windows-centric developer falls into at one point or another when working on Linux: forgetting that searching for an executable on Linux will not check the current directory by default. What does this mean in the case of PHP Process control? Specify an absolute directory for the executable. This is easy in PHP though if it’s in the directory the script is running in (or any sub directory):

• __DIR__ is a magic constant that identifies the directory of the current script (only in PHP 5.3)
• dirname(__FILE__) extracts the absolute directory from the absolutely-qualified location of the current script (like above, but supported back to PHP 4.0.2)

There are other reasons for requiring a full path, but I didn’t realize those until learning lesson 3.

Lesson 2: Permissions and 126 return code

Ah yes, file permissions. Any of many permission-related issues may come up (I’m still not sure if I accounted for everything but the implementer of my work says all is well) but all these issues fall under the umbrella return code of 126. This is where things got real mucky. Apache executes under a user account (‘www’ on some machines, ‘apache’ on others, ‘httpd’ or ‘nobody’ on still others) for performing any interactions with the OS. In systems where permissions are exclusive rather than inclusive (any *NIX environment) this becomes an issue if not dealt with. So be sure to:

1. Determine the user that Apache runs under (place ‘passthru(“whois”);’ in a PHP script)
2. Give that user rights to execute the shell script
3. Run normally

Note that this may not be enough. The executable must be in a directory accessible by the apache user account (so keep your files away from /root/). Normally though, these permission issues seemed to arise as a result of running in a web context through a web server. In other words, the script will still likely work if run from the command line like so:

php myScript.php

Lesson 3: Apache Environment and the 127 return code

So our script has passed the above two checkpoints and is guaranteed to run, right? WRONG! These never came up with my own simple implementation of calling a shell script which just catted data around, but shell scripts which call other user-defined shell scripts or executables may still be in for an issue. This is because the Apache user may run in an environment with only a partial path (/bin, /sbin or /usr/bin may not be included by default).

So, a retrospect on my first foray into PHP Process Control: 30 minutes to research, 30 minutes to code, 4 hours to debug. Did the age-old programming wisdom of “expect things to take twice as long as you’d expect” hold? Most definitely. Did I learn a lot and enjoy every minute? Most definitely.