Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage Perl Problème de registre avec mod_perl

Problème de registre avec mod_perl

13 réponses
Avatar
Raphaël 'SurcouF' Bordet
Bonjour,

Depuis aujourd'hui, je constate que l'usage de mod_perl s'est trouvé
modifié sur un serveur web dont j'ai la charge (en cours d'intégration,
quoi): en effet, j'ai ce persistent message d'erreur dans les logs:

[Thu Oct 07 10:55:45 2004] [error] [client 192.168.0.8] Re-register of
content_disposition at
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
line 144!Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
line 144.!

La seule référence que Google m'a trouvé se réfère à la date du système,
hors il se trouve que celle-ci a changé dans la semaine (le BIOS se
croyait en 2006 et l'installateur de la RedHat avait suivi...).
Est-ce que cela a-t-il en effet un rapport de cause à effets ?
J'ai beau avoir joué du find /usr/lib/perl5 -type f -exec touch {} \;,
ça n'a rien donné de concluant...

Une idée ?

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Paul Gaborit
À (at) Thu, 07 Oct 2004 11:03:06 +0200,
Raphaël 'SurcouF' Bordet écrivait (wrote):
La seule référence que Google m'a trouvé se réfère à la date du système,
hors il se trouve que celle-ci a changé dans la semaine (le BIOS se croyait
en 2006 et l'installateur de la RedHat avait suivi...). Est-ce que cela
a-t-il en effet un rapport de cause à effets ?


Peut-être... Avez-vous redémarré Apache depuis le changement de date ?

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>

Avatar
Raphaël 'SurcouF' Bordet
Paul Gaborit wrote:
À (at) Thu, 07 Oct 2004 11:03:06 +0200,
Raphaël 'SurcouF' Bordet écrivait (wrote):

La seule référence que Google m'a trouvé se réfère à la date du système,
hors il se trouve que celle-ci a changé dans la semaine (le BIOS se croyait
en 2006 et l'installateur de la RedHat avait suivi...). Est-ce que cela
a-t-il en effet un rapport de cause à effets ?



Peut-être... Avez-vous redémarré Apache depuis le changement de date ?


Le processus père tournait depuis le 30 septembre mais malgré tout, le
relancer n'a rien changer...

Autre idée ?

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net


Avatar
Patrick Mevzek
La seule référence que Google m'a trouvé se réfère à la date du
système, hors il se trouve que celle-ci a changé dans la semaine (le
BIOS se croyait en 2006 et l'installateur de la RedHat avait suivi...).
Est-ce que cela a-t-il en effet un rapport de cause à effets ?



Peut-être... Avez-vous redémarré Apache depuis le changement de date ?


Le processus père tournait depuis le 30 septembre mais malgré tout, le
relancer n'a rien changer...


Vous avez bien fait stop, puis start ?
(pas tout à fait équivalent, avec modperl, à restart).

Autre idée ?


C'est quelle version de Apache::Reload, parce que dans la dernière, la
ligne 144 c'est une ligne blanche.
Le require est un peu plus haut, et si l'erreur vient de là, c'est que
Apache::Reload a été incapable de recharger un module qui a changé sur le
disque.
Il faudrait un
ReloadDebug on
dans la configuration Apache pour avoir le debug de Apache::Reload, et
voir ce qui est mis dans le require et qui échoue.

D'autre part, vérifier que votre serveur fonctionne correctement sans
Apache::Reload.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>



Avatar
Raphaël 'SurcouF' Bordet
Patrick Mevzek wrote:

La seule référence que Google m'a trouvé se réfère à la date du
système, hors il se trouve que celle-ci a changé dans la semaine (le
BIOS se croyait en 2006 et l'installateur de la RedHat avait suivi...).
Est-ce que cela a-t-il en effet un rapport de cause à effets ?



Peut-être... Avez-vous redémarré Apache depuis le changement de date ?


Le processus père tournait depuis le 30 septembre mais malgré tout, le
relancer n'a rien changer...


Vous avez bien fait stop, puis start ?
(pas tout à fait équivalent, avec modperl, à restart).


De même en faisant stop puis start...

Autre idée ?


C'est quelle version de Apache::Reload, parce que dans la dernière, la
ligne 144 c'est une ligne blanche.


0.08, fourni avec le paquet RPM mod_perl-0.99_09-10 de la RH ES.

Le require est un peu plus haut, et si l'erreur vient de là, c'est que
Apache::Reload a été incapable de recharger un module qui a changé sur le
disque.
Il faudrait un
ReloadDebug on
dans la configuration Apache pour avoir le debug de Apache::Reload, et
voir ce qui est mis dans le require et qui échoue.


Je ne vois pas à quel niveau insérer cette commande...
A vrai dire, ce doit être la première application utilisant mod-perl que
j'installe... :-(

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net




Avatar
Patrick Mevzek
C'est quelle version de Apache::Reload, parce que dans la dernière, la
ligne 144 c'est une ligne blanche.


0.08, fourni avec le paquet RPM mod_perl-0.99_09-10 de la RH ES.


Sur CPAN, y a que 0.07, pas au-delà. Strange....
Je suis étonné du numéro de version mod_perl aussi.

Le require est un peu plus haut, et si l'erreur vient de là, c'est que
Apache::Reload a été incapable de recharger un module qui a changé sur
le disque.
Il faudrait un
ReloadDebug on
dans la configuration Apache pour avoir le debug de Apache::Reload, et
voir ce qui est mis dans le require et qui échoue.


Je ne vois pas à quel niveau insérer cette commande... A vrai dire, ce


Dans la configuration Apache.
Vous devez avoir déjà qqpart
PerlInitHandler Apache::Reload
suffit d'ajouter
ReloadDebug on
juste après.

Accessoirement, prenez la liste des modules concernés (qui doivent
apparaître en PerlModule et équivalent dans la configuration Apache, plus
tous les use/require présents dedans), et faites un perl -cw dessus pour
voir lequel ne compile pas.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>


Avatar
Raphaël 'SurcouF' Bordet
Patrick Mevzek wrote:
C'est quelle version de Apache::Reload, parce que dans la dernière, la
ligne 144 c'est une ligne blanche.


0.08, fourni avec le paquet RPM mod_perl-0.99_09-10 de la RH ES.


Sur CPAN, y a que 0.07, pas au-delà. Strange....
Je suis étonné du numéro de version mod_perl aussi.


Surement une énième RedHat-erie... Je me languis de ma Debian, moi...

Le require est un peu plus haut, et si l'erreur vient de là, c'est que
Apache::Reload a été incapable de recharger un module qui a changé sur
le disque.
Il faudrait un
ReloadDebug on
dans la configuration Apache pour avoir le debug de Apache::Reload, et
voir ce qui est mis dans le require et qui échoue.


Je ne vois pas à quel niveau insérer cette commande... A vrai dire, ce


Dans la configuration Apache.
Vous devez avoir déjà qqpart
PerlInitHandler Apache::Reload
suffit d'ajouter
ReloadDebug on
juste après.


C'est justement ce que j'avais essayé et apache n'a pas du tout aime:

Syntax error on line 1161 of /etc/httpd/conf/httpd.conf:
Invalid command 'ReloadDebug', perhaps mis-spelled or defined by a
module not included in the server configuration
1
Accessoirement, prenez la liste des modules concernés (qui doivent
apparaître en PerlModule et équivalent dans la configuration Apache, plus
tous les use/require présents dedans), et faites un perl -cw dessus pour
voir lequel ne compile pas.


# perl -cw
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm

/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Reload.pm
syntax OK

# perl -cw
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Const.pm

/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Const.pm
syntax OK

# perl -cw
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/ServerUtil.pm

/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/ServerUtil.pm
syntax OK

# perl -cw
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/RequestUtil.pm

/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/RequestUtil.pm
syntax OK

Tout semble pourtant Ok...

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net



Avatar
Patrick Mevzek
Dans la configuration Apache.
Vous devez avoir déjà qqpart
PerlInitHandler Apache::Reload
suffit d'ajouter
ReloadDebug on
juste après.


C'est justement ce que j'avais essayé et apache n'a pas du tout aime:


Peut-être qu'il n'y a pas de ReloadDebug dans votre version
d'Apache::Reload
Ca y est pourtant dans la dernière du CPAN.

Accessoirement, prenez la liste des modules concernés (qui doivent
apparaître en PerlModule et équivalent dans la configuration Apache,
plus tous les use/require présents dedans), et faites un perl -cw
dessus pour voir lequel ne compile pas.



Si il y a que ca comme modules, Apache::Reload ne sert strictement à
rien, vu que ces modules ne bougent pas.
Donc soit il y a d'autres modules (en particulier ceux que vous avez
développé) auquel cas ce sont ces derniers à utiliser
Soit vous n'avez pas besoin d'Apache::Reload.

De toute façon, dans tous les cas, essayez de commenter tout ce qui est
relatif à Apache::REload dans votre configuration Apache pour voir si
tout fonctionne bien déjà comme ca.

Apache::Reload n'est pas du tout nécessaire au fonctionnement de
mod_perl.
C'est juste une aide qui évite d'avoir à redémarrer Apache dès qu'on
change un module Perl, ce qui arrive souvent en phase de développement,
mais qui ne devrait pas arriver en phase de production.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>


Avatar
Raphaël 'SurcouF' Bordet
Patrick Mevzek wrote:

Dans la configuration Apache.
Vous devez avoir déjà qqpart
PerlInitHandler Apache::Reload
suffit d'ajouter
ReloadDebug on
juste après.


C'est justement ce que j'avais essayé et apache n'a pas du tout aime:



Peut-être qu'il n'y a pas de ReloadDebug dans votre version
d'Apache::Reload
Ca y est pourtant dans la dernière du CPAN.


Accessoirement, prenez la liste des modules concernés (qui doivent
apparaître en PerlModule et équivalent dans la configuration Apache,
plus tous les use/require présents dedans), et faites un perl -cw
dessus pour voir lequel ne compile pas.




Si il y a que ca comme modules, Apache::Reload ne sert strictement à
rien, vu que ces modules ne bougent pas.
Donc soit il y a d'autres modules (en particulier ceux que vous avez
développé) auquel cas ce sont ces derniers à utiliser
Soit vous n'avez pas besoin d'Apache::Reload.


L'application en question n'a pas été développée par mes soins: il
s'agit d'OTRS[1] (Open Ticket Request System). Voici, d'ailleurs, la
structure qu'il emploie:

# agent, admin and customer frontend
ScriptAlias /otrs/ "/opt/otrs/bin/cgi-bin/"
Alias /otrs-web/ "/opt/otrs/var/httpd/htdocs/"
# load all otrs modules
Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl
# Apache::Reload - Reload Perl Modules when Changed on Disk
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
# set mod_perl2 options
<Location /otrs>
# ErrorDocument 403 /otrs/customer.pl
ErrorDocument 403 /otrs/index.pl
SetHandler perl-script
PerlHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
</Location>

__END__

A part un warning à cause d'un fichier encodé en UTF-8, le script
apache2-perl-startup.pl passe bien le test du perl -wc ...
En fait, je pense qu'OTRS en a besoin, uniquement parce qu'ils ont placé
toute leur application dans /opt, y compris leurs propres modules Perl.

De toute façon, dans tous les cas, essayez de commenter tout ce qui est
relatif à Apache::REload dans votre configuration Apache pour voir si
tout fonctionne bien déjà comme ca.


Hélas, ça ne fonctionne pas mieux sans Apache::Reload:

[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat


Merci de ton aide, en tout cas.

[1]: http://otrs.org/
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net



Avatar
Patrick Mevzek

L'application en question n'a pas été développée par mes soins: il
s'agit d'OTRS[1] (Open Ticket Request System). Voici, d'ailleurs, la
structure qu'il emploie:

# agent, admin and customer frontend
ScriptAlias /otrs/ "/opt/otrs/bin/cgi-bin/"


[..]

A part un warning à cause d'un fichier encodé en UTF-8, le script
apache2-perl-startup.pl passe bien le test du perl -wc ...


(Il faudrait regarder tout ce qu'il y a dans /opt/otrs/bin/cgi-bin/ en
fait)

De toute façon, dans tous les cas, essayez de commenter tout ce qui est
relatif à Apache::REload dans votre configuration Apache pour voir si
tout fonctionne bien déjà comme ca.


Hélas, ça ne fonctionne pas mieux sans Apache::Reload:


Donc Apache::Reload n'y est pour rien, aux problèmes rencontrés.

[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat


C'est mieux comme message d'erreur :-)

Il faudrait donc vérifier que /opt/otrs/bin/cgi-bin/ existe et est
atteignable par Apache (droits corrects).

Peut-être un find malheureux par effet de bord a fait changer certains
droits, d'où impossibilité après d'exécution correcte.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>


Avatar
Raphaël 'SurcouF' Bordet
Patrick Mevzek wrote:


L'application en question n'a pas été développée par mes soins: il
s'agit d'OTRS[1] (Open Ticket Request System). Voici, d'ailleurs, la
structure qu'il emploie:

# agent, admin and customer frontend
ScriptAlias /otrs/ "/opt/otrs/bin/cgi-bin/"



[..]


A part un warning à cause d'un fichier encodé en UTF-8, le script
apache2-perl-startup.pl passe bien le test du perl -wc ...



(Il faudrait regarder tout ce qu'il y a dans /opt/otrs/bin/cgi-bin/ en
fait)


Le but de ce script est justement de faire des use en grand nombre...


De toute façon, dans tous les cas, essayez de commenter tout ce qui est
relatif à Apache::REload dans votre configuration Apache pour voir si
tout fonctionne bien déjà comme ca.


Hélas, ça ne fonctionne pas mieux sans Apache::Reload:



Donc Apache::Reload n'y est pour rien, aux problèmes rencontrés.


[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat



C'est mieux comme message d'erreur :-)

Il faudrait donc vérifier que /opt/otrs/bin/cgi-bin/ existe et est
atteignable par Apache (droits corrects).

Peut-être un find malheureux par effet de bord a fait changer certains
droits, d'où impossibilité après d'exécution correcte.


Bien que tout appartienne à root, n'importe qui peut les lire et les
exécuter et, donc, à fortieri, apache le peut égalemment.

--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net



1 2