Souci avec SMI

[Gecko64]

Hello tout le monde !
Je viens vers vous pcq j'ai un souci avec php et plus précisément avec la fonction shell_exec.
Pour expliquer, une webradio où je fais de la maintenance à un souci avec un vieux panel de gestion de serveur de streaming shoutcast 1.
Ce panel étant compatible php5 maximum, j'ai du un peu chipoter pour avoir une Debian 9 avec cette version.
Cependant, tout marche bien, tout sauf une irréductible ligne de code qui résiste encore à l'envahisseur du bon fonctionnement.

Alors dans le code suivant, on voit qu'on prépare la commande d’exécution pour lancer le serveur shoutcast avec la configuration qui va avec, le tout stocké dans $cmdstr.
 

 $cmdstr = "nohup ".$config['sc_serv']." ".$config['smi_path']."/servers/".$port."".$srvname.".conf > /dev/null & echo $!";
 echo $cmdstr;
 $pid = shell_exec($cmdstr);
 echo $pid;

Quand je fais un echo de $cmdstr, il me sort la commande parfaite sans erreur de syntaxe; commande que j'ai même testé avec succès en bash sous le même utilisateur sous lequel apache2 exécute celle-ci.
Le souci, c'est dès que je regarde si le shell_exec a bien exécuté cette commande quand je passe par apache2 et non directement en bash, aucun serveur shoutcast ne se lance.
Je récupère bien un PID dans $pid mais aucune trace du serveur de streaming.

Du coup je ne sais pas si des gens baignant plus dans php que moi auraient une piste pour moi ?
Ce code tournait nickel sous Debian Wheezy, distribution sur laquelle ils sont encore mais plus pour longtemps...

Merci d'avance !

[Aenoa]

La commande est exécutée sous le nom d'utilisateur Apache (www-data par défaut sous debian). A-t-il les droits d'exécution etc?

 

Le(s) fichier(s) devraient avoir au moins --x en permission (noread nowrite execute) et si le script créer/modifie/lis des fichiers, www-data doit également avoir les permissions pour (ci-inclut, les logs générés par shoutcast).

 

Il se peut qu'il soit également exécuté en tant que PHP si tu as spécifié dans la config un utilisateur pour celui-ci.

Si cela fonctionne sous Wheezy et pas sur versions supérieures, vérifie que tout soit identique niveau config serveur+moteur php+accès répertoire sous version plus récente. 

 

Autre solution: PHP tourne sur ton serveur web en SAFE MODE, et comme la doc l'indique;

Note:

This function is disabled when PHP is running in safe mode.

[Gecko64]

Non il tourne sous l'utilisateur gecko; j'utilise le module mpm-itk et j'ai bien vérifié ça avec un htop.
C'est d'ailleurs sous ce même utilisateur que j'ai testé en bash directement.
Pour les droits d'accès, j'ai testé et aucun souci de ce côté, d'ailleurs il se lance directement en bash.
J'ai aussi testé un touch avec le shell_exec et la fonction existe bien, il me crée bien le fichier que j'ai passé en paramètre.
Pour le serveur, il y a eu pas mal de changements dans apache2, niveau domaine virtuel de ce que j'ai vu.
Pour le reste de la config, je suis resté avec celle par défaut.

En fait, j'en suis même arrivé à penser que comme mon binaire crée un socket réseau, par sécurité, il pourrait le bloquer.

Merci !

[Dan]

Si ton binaire génère une sortie comme un Line Break, il faut rediriger la sortie de ton shell_exec() ...

Par exemple :
 

shell_exec("ton programme avec arguments" >/dev/null 2>&1);

 

[Gecko64]

J'ai testé mais pareil, il refuse de se lancer.
C'est vraiment étrange...

[Dan]

Et en mettant le chemin complet vers l'appli ?

Parce que l'utilisateur php n'a vraisemblablement pas le même PATH que gecko

 

 

[Gecko64]

Rien n'est en relatif, j'ai testé les deux.
En console il se lance mais dès que je mets la commande en shell_exec, fini.

J'ai encore fait un shell_exec juste en dessous shell_exec("touch toto.txt"); et là on voit bien que ça marche et tourne sous l'utilisateur gecko : -rw-r--r--  1 gecko gecko    0 Jul 13 19:45 toto.txt
Il y a un utilisateur différent de apache2 pour php ?
Pcq moi je fais tourner apache2 sous un utilisateur spécifique et tout ce qui en découle est effectué sous cette identité là.
Mais sinon, ceci dans un fichier de test, ça ne marche pas : shell_exec("nohup /home/gecko/website/smi/shoutcast/1.9.8-Linux/sc_serv /home/gecko/website/smi/servers/8000SERVER.conf > /dev/null & echo $!");

[Dan]

Tu tournes php sous quelle forme ? php_mod ? SuPhp ? php-fpm ?

Et quelle version de php ? Parce qu'installer un php5.x sous debian 9 n'est pas ce que j'appellerais une bonne idée...

 

[Gecko64]

" Parce qu'installer un php5.x sous debian 9 n'est pas ce que j'appellerais une bonne idée... "

Tout à fait d'accord mais il ne veut pas lâcher son panel de gestion et je me vois mal, rouillé comme je suis en PHP, commencer à upgrader tout le code... :-/
Sinon c'est php_mod en version 5.6 ( php5_module (shared) ).
J'ai ajouté le repository de Jessie et j'ai mis les priorités de packet dans /etc/apt/preferences.d/jessie
C'est ainsi que j'ai pu le mettre sur Stretch, même si j'avoue aussi ne pas aimer faire ça.

[Dan]

Donne-moi précisément la ligne shell_exec() de ton code, sans la modifier d'aucune manière !

 

<edit: vue plus haut ! Remplace tes doubles quotes par des simples quotes !>

 

 

[Gecko64]

Je viens de le faire mais le problème persiste.
Par contre j'ai un trou niveau administration, c'est comment je pourrais garder une historique des pid qui existent durant un certain temps ?
Pcq il récupère bien un pid mais pas moyen de voir à quelle commande il appartient vu que ça disparait aussitôt.
Je pensais faire un "ps aux" en boucle super rapide qui ajoute tout à un fichier et aller chercher là dedans mais bon, chipotage chipotage ^^

[Dan]

As-tu essayé exec() en lieu et place de shell_exec() ?

 

 

[Gecko64]

Je viens d'essayer mais pareil... :-/

[SStephane]

Un peu tard, mais regarde dans le php.ini dédié à apache ce que tu as dans disable_functions (ou un truc du genre), je crois que c'est désactivé par défaut maintenant.