Question Quand les extensions de fichier remplacent-elles les lignes shebang sous Linux?


Certaines tâches cron PHP ont récemment échoué sur un serveur partagé. Ils avaient fonctionné sans erreur et sans mises à jour depuis près d'un an, mais ils ne s'exécuteraient plus en raison d'erreurs de syntaxe. Ce qui se passait?

Il s'avère que ces scripts fonctionnaient maintenant sous PHP 4, et non pas dans PHP 5. Il existe une version de PHP 4 installée dans / usr / local / bin / php, mais il s'agissait de la ligne "shebang" dans ces scripts:

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

J'ai fait des expériences:

% /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

Je ne savais pas que Linux laisserait les extensions de fichiers remplacer les lignes shebang, mais c'est ce que je vois. Le support de la société d'hébergement ne savait pas pourquoi cela se produisait (ou ce qui avait changé récemment pour que cela se produise), alors j'ai opté pour une solution de contournement: renommez les scripts pour qu'ils ne se terminent plus par ".php".

Les tâches cron sont à nouveau en cours d'exécution, mais je déteste la réponse «ne faites pas ça comme ça». Je suis vraiment curieux de savoir d'où vient ce comportement, car je n'ai jamais rien vu de tel de la part de * nix au niveau de la coque. J'ai testé sous zsh et bash, donc je ne pense pas pouvoir blâmer une configuration de shell. J'ai salué 'php' sous / etc pour voir si cela me donnerait des indices, mais non. Des idées?


7
2017-11-06 18:14


origine


Wow ... nouveau temps de société d'hébergement. - womble♦


Réponses:


On dirait que vous avez php enregistré avec binfmt_misc.

Consultez la page de manuel sur le sujet: binfmt_misc.txt

Vous voudrez désenregistrer le gestionnaire php binfmt_misc en lui faisant écho -1 (il doit être root). Il sera répertorié dans / proc / sys / fs / binfmt_misc / s'il s'agit de votre problème.

En guise d'avertissement, cela pourrait endommager d'autres éléments du système. Par exemple, si un autre script PHP est en cours d'exécution mais n'a pas de shebang valide. CGI ou suExec peuvent poser des problèmes en fonction de leur configuration. En bref, assurez-vous de tout tester.


8
2017-11-06 18:31



Cela semble être ça. Je viens de regarder / proc / sys / fs / binfmt_misc / php, qui est activé, et pointant sur / usr / local / bin / php ... et l'horodatage de ce fichier se situe exactement au moment où ces travaux ont commencé à échouer. C'est un hôte partagé, je n'ai donc pas de racine. Mais au moins je sais ce qui est arrivé maintenant. Merci! - drench
Voir également: man update-binfmts. - Dennis Williamson


Cela ressemble à binfmt_misc, et votre société d'hébergement semble un peu folle :) Mais je suppose qu'ils l'ont probablement déjà fait pour des raisons de compatibilité: les fichiers .php utilisent php4 et les fichiers php5 utilisent php5. Essayez une extension php5. Cela ne devrait pas être nécessaire pour tous les fichiers d’un site (uniquement les tâches cron et d’autres tâches exécutées sous forme de travaux / scripts de serveur) car votre serveur Web aura sa propre logique d’exécution / gestionnaires.


2
2017-11-07 00:42



S'ils l'ont fait sur un serveur existant avec des clients, quelle qu'en soit la raison, ils méritent d'être tirés d'un coup de canon. - womble♦