Problème avec exec, shell_exec, system et tutti quanti - Page 1

Bon, j'ai un problème qui me bloque depuis plusieurs jours...
Dans un autre sujet, j'ai parlé de la commande winexe qui me permet de lancer une commande sur une machine Windows depuis Linux. Cette commande fonctionne parfaitement bien et remplit idéalement son rôle. Sauf que...
Ca déconne lorsqu'elle est lancée depuis un script php depuis Apache, et ce sous deux configurations différentes (un Ubuntu 9.10 avec PHP 5.2/Apache /2.2.12 et un Arch linux avec PHP 5.3.3 et Apache 2.2.17).
Concrètement, la commande se lance et fait ce qu'on lui demande, mais ne se finit jamais. Un top m'indique qu'elle est toujours "Running" et qu'elle utilise un processeur à 100% (avec Ubuntu, avec l'utilisateur www-data ; avec Arch avec http).
Ce qui est terrible, c'est que si je lance la commande exec("/usr/bin/winexe -d 1 --user=servadm/nil --password=suPeRPass --interactive=0 --uninstall //MonServWin \"c:\test.bat\" "); depuis php -a ça fonctionne parfaitement... même si je lance php -a avec l'utilisateur apache.

Les autres commandes lancées depuis exec() dans un script web fonctionnent très bien (un ls |grep o fait ce qu'on lui demande de faire).

Est-ce que vous savez s'il y a des paramètres qui pourraient faire merder l'exécution à travers Apache ?

rocess qui est dans les choux, j'ai comme message d'erreurtevent: EPOLL_CTL_ADD failed (Operation not permitted) - falling back to select()Ah, un dernier détail, mais je ne sais pas si c'est intéressant... si je tue le pmais je ne sais pas si c'est le fait de l'avoir tué qui provoque ça, ou si c'est la cause de la mise en vrac...

Petite info en passant : si j'exécute exec("/usr/bin/winexe"); sans rien, le script se finit proprement avec comme retour l'aide minimale ; idem si je demande la version avec -V. C'est dès que je fais une opération RPC que ça merde...

Souane, s'il te plaît, aide-moi !

php -a ça fait quoi?

Ca lance php en mode interactif (si tu as installé les paquets php-cli)... concrètement, tu as une console qui te permet de lancer des commandes php directement.

généralement ca vient d'un pb de droits, mais apparemment tu as déjà regardé de ce côté là

as tu la possibilité de préfixer la commande avec un strace pour voir quel est l'appel système qui s'est fait refuser l'accès?

Tu as essayé de rediriger toutes les entrées/sorties standard, pour vérifier qu'une communication non terminée ne bloque le processus ? (j'ai vu ça une fois, par contre a priroi ça n'expliquerait pas l'utilisation à 100% du CPU...)

epoll pourrait être lié à des connexions réseaux (il a dit que ça bloque quand il fait du RPC)

[nosmile]

squalyl (./5) :
as tu la possibilité de préfixer la commande avec un strace pour voir quel est l'appel système qui s'est fait refuser l'accès?

Très bonne idée, en effet... voici le résultat (après, ça continue à l'infini avec un incrément progressif du dernier paramètre) :
Fichier joint : trace.wexe

man 2 select:
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);

[...]
select() and pselect() allow a program to monitor multiple file descriptors, waiting until one or more of the file descriptors become "ready" for some class of I/O operation
(e.g., input possible). A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking.


On remarque que select est appelé avec les valeur :

select(9, [0 5 8], [], NULL, {0, 8386}) = 2 (in [0 5], left {0, 8384})

Donc il attend sur 0, 5 et 8 (readfds)

que sont 0, 5 et 8 ?
0 est stdout
5 est le dernier open retournant 5, cad socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
donc c'est une socket reseau
8 est socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 8
donc une socket aussi.

Tu as donc un probleme reseau dans cet environement.

vu que c'est précédé par sendto(), il envoie une bouteille à la mer et ne reçoit rien.

Putain, je suis naze, je n'ai même pas vu http://sourceforge.net/tracker/?func=detail&aid=3047190&group_id=277151&atid=1177003
/o\ :/
(A priori, le projet est plus ou moins en stand by dans la mesure où il est prévu qu'il soit intégré à Samba 4... Le souci, c'est que Samba 4 n'est disponible qu'en alpha en ce moment, donc c'est pas gagné... Cela dit, je vais essayer de voir si je ne peux pas recompiler Winexe avec l'alpha de Samba 4 sortie en septembre, on ne sait jamais...).
Mais c'est quand même bizarre comme bug ?!

Super, merci Souane !

Ah oui, pardon, je manque à toutes les règles de la bienséance... l'émotion du désespoir, sans doute

ben c'est ce qu'ils disent: il essaye de lire stdin (=0, stdout=1, stderr=2) alors qu'il y a rien a lire.

du coup ça marche bien en interactif (php -a) mais pas en automatique.

Ce qui est strange c'est que ça bouffe 100% de cpu.

a priori ton workaround c'est juste de remplacer winexe par:

screen -S $name-of-this-screen-session -D -m winexe (all the winexe
options you need here)

Bah oui, pourquoi ne pas te faire juste un petit script intermédiaire qui ne ferait que fournir les flux manquants à ton programme ?

J'ai pas essayé avec screen ; par contre, j'avais essayé avec un
echo Mon mot de passe\n|sudo -u mon utilisateur winexe ...
pensant naïvement que sudo ouvrirait un vt virtuel.

Yay \o/ exec("screen -D -m nice /usr/bin/winexe --user=servadm/nil --password=MonPassWord --interactive=1 --uninstall //MonSrv \"c:\test.bat\" > /dev/null 2>&1 & ");fait exactement ce que je veux...
Soussou !

de rien (merci pour le password )

Arf put** ne jamais bosser avant 10h du mat x_x (bon, ça va, c'est mon pass du serveur de tests )