Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Some PHP cron jobs started failing on a shared server recently. They had been working without error and no updates for nearly a year, but now would no longer run due to syntax errors. What was going on?

It turns out these scripts were suddenly now running under PHP 4, not PHP 5. There is a version of PHP 4 installed at /usr/local/bin/php, but this was the "shebang" line on these scripts:

#!/usr/local/php5/bin/php

I did some experiments:

% /usr/local/php5/bin/php --version
PHP 5.2.6 (cli) (built: May 11 2008 13:09:39) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

% echo '<?= phpversion() ?>' | /usr/local/php5/bin/php
5.2.6

% printf '#!/usr/local/php5/bin/php\n<?= phpversion() ?>' > version
% chmod +x version
% ./version
5.2.6

% mv version x.php
% ./x.php
4.4.9

I didn't know Linux would let file extensions override shebang lines, but that's what I'm seeing. Support at the hosting company had no idea why this was happening (or what had changed recently to make it happen), so I went with a workaround: rename the scripts so they no longer end in ".php".

The cron jobs are running again, but I hate a "just don't do that" answer. I'm really curious to know where this behavior is coming from, because I've never seen anything like this from *nix at the shell level. I tested under both zsh and bash, so I don't think I can blame a shell configuration. I grepped for 'php' under /etc to see if that would give me any clues, but no. Any ideas?

share|improve this question
    
Wow... new hosting company time. –  womble Nov 7 '09 at 0:03
add comment

2 Answers 2

up vote 8 down vote accepted

Sounds like you have php registered with binfmt_misc.

Check out the man page on the subject: binfmt_misc.txt

You'll want to unregister the php binfmt_misc handler by echoing -1 to it (must be root). It will be listed in /proc/sys/fs/binfmt_misc/ if this is your issue.

As a warning, this could break other stuff on the system. For instance, if another PHP script is being executed but doesn't have a valid shebang. CGI or suExec could be issues depending on their configuration. In short, be sure to test everything.

share|improve this answer
    
This appears to be it. I just looked at /proc/sys/fs/binfmt_misc/php and it is enabled, and pointing at /usr/local/bin/php ... and the timestamp of this file happens to be exactly when those jobs started failing. This is a shared host, so I don't have root. But at least I know what happened now. Thanks! –  drench Nov 6 '09 at 18:42
    
See also: man update-binfmts. –  Dennis Williamson Nov 6 '09 at 19:57
add comment

It does look like binfmt_misc, and your hosting company does seem to be a bit crazy :) But I suspect they've probably done this for compatibility, making .php files use php4, and php5 files use php5. Try a php5 extension. It shouldn't be necessary to do this for all the files on a site (just cronjobs and other things run as server jobs/scripts) because your webserver will have its own execution logic/handlers.

share|improve this answer
    
If they've done it on an existing server with customers on it, regardless of the reason, they deserve to be shot out of a cannon. –  womble Nov 8 '09 at 3:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.