Cependant, attacher gdb sur apache2 ne suffit pas, parce que, par défaut sur ma debian(*), il y à 6 processus d'apache lancés, et en plus il faut les droits d'admin pour les contrôler (logique).
Donc, il faut lancer apache2 avec "-X", comme dit sur tant de sites. Sauf que, encore une fois, c'est plus compliqué que ça sur ma machine(*), car juste lancer "#/usr/sbin/apache2 -X" à la main n'exécute pas le contenu du fichier "/etc/apache2/envvars", qui contient un certain nombre de variables d'environnement nécessaire à la configuration d'apache ( qui se trouve elle dans "/etc/apache2/apache.conf" chez moi ).
Chose que j'ai mis... trop longtemps à voir... bref... il y a une ligne dans ce fameux fichier "/etc/apache2/envvar" qui définit la variable "APACHE_ARGUMENTS".
C'est ici qu'il faut ajouter le fameux "-X", ce qui donne donc:
export APACHE_ARGUMENTS=''
Ensuite, lancer apache, mais pas par son exécutable, ni par le mécanisme d'init comme on l'aurait fait pour d'autres services ( ça semble sûrement évident à certains, mais pour moi qui ne suis pas un admin, j'ai voulu utiliser la méthode classique de debian... grand mal m'a pris. ) mais par l'outil dédié d'apache ( je ne savais pas qu'il y en avait un, à ma décharge... je l'ai découvert via l'auto-complétion. ) via "#/usr/sbin/apache2ctl start".
Bien entendu, avec la config standard dans /etc, apache utilise le port 80, ce qui implique de devoir lancer cette commande sous root, ou de modifier la config, selon l'humeur et/ou les contraintes.
Lancer une requête pour le script qui pose problème, taper un petit "ps -A|grep mon_cgi" pour récupérer le pid, et enfin, attacher gdb à ce pid.
[^] # Re: process séparé ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 3.
Bien vu aussi, c'est ce que j'ai fait du coup.
Cependant, attacher gdb sur apache2 ne suffit pas, parce que, par défaut sur ma debian(*), il y à 6 processus d'apache lancés, et en plus il faut les droits d'admin pour les contrôler (logique).
Donc, il faut lancer apache2 avec "-X", comme dit sur tant de sites. Sauf que, encore une fois, c'est plus compliqué que ça sur ma machine(*), car juste lancer "#/usr/sbin/apache2 -X" à la main n'exécute pas le contenu du fichier "/etc/apache2/envvars", qui contient un certain nombre de variables d'environnement nécessaire à la configuration d'apache ( qui se trouve elle dans "/etc/apache2/apache.conf" chez moi ).
Chose que j'ai mis... trop longtemps à voir... bref... il y a une ligne dans ce fameux fichier "/etc/apache2/envvar" qui définit la variable "APACHE_ARGUMENTS".
C'est ici qu'il faut ajouter le fameux "-X", ce qui donne donc:
export APACHE_ARGUMENTS=''
Ensuite, lancer apache, mais pas par son exécutable, ni par le mécanisme d'init comme on l'aurait fait pour d'autres services ( ça semble sûrement évident à certains, mais pour moi qui ne suis pas un admin, j'ai voulu utiliser la méthode classique de debian... grand mal m'a pris. ) mais par l'outil dédié d'apache ( je ne savais pas qu'il y en avait un, à ma décharge... je l'ai découvert via l'auto-complétion. ) via "#/usr/sbin/apache2ctl start".
Bien entendu, avec la config standard dans /etc, apache utilise le port 80, ce qui implique de devoir lancer cette commande sous root, ou de modifier la config, selon l'humeur et/ou les contraintes.
Lancer une requête pour le script qui pose problème, taper un petit "ps -A|grep mon_cgi" pour récupérer le pid, et enfin, attacher gdb à ce pid.
Welcome to your script.
*:
Debian testing
apache 2.4.7
sysVinit