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
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not found or unable to stat
|..]
Bien que tout appartienne à root, n'importe qui peut les lire et les exécuter et, donc, à fortieri, apache le peut égalemment.
D'après le code source: unless (-r $r->my_finfo && -s _) { $self->log_error("$self->[FILENAME] not found or unable to stat"); return Apache::NOT_FOUND; }
Le problème semble donc en fait ailleurs: pour une raison X le /otrs du web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche pas au bon endroit.
Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin dans ScriptAlias, mais pas dans le message d'erreur) : http://www.example.com/otrs/ ^
Si c'est ca le problème, alors votre ServerName n'est pas bon. Vous pouvez aussi corriger en enlevant les slashs finaux dans ScriptAlias/Alias (des deux côtés).
BTW, je pense qu'on est plus dans un problème de configuration Apache que (mod)perl là, je vous laisse soin de rediriger.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat
|..]
Bien que tout appartienne à root, n'importe qui peut les lire et les
exécuter et, donc, à fortieri, apache le peut égalemment.
D'après le code source:
unless (-r $r->my_finfo && -s _) {
$self->log_error("$self->[FILENAME] not found or unable to stat");
return Apache::NOT_FOUND;
}
Le problème semble donc en fait ailleurs: pour une raison X le /otrs du
web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche
pas au bon endroit.
Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin
dans ScriptAlias, mais pas dans le message d'erreur) :
http://www.example.com/otrs/
^
Si c'est ca le problème, alors votre ServerName n'est pas bon.
Vous pouvez aussi corriger en enlevant les slashs finaux dans
ScriptAlias/Alias (des deux côtés).
BTW, je pense qu'on est plus dans un problème de configuration Apache que
(mod)perl là, je vous laisse soin de rediriger.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not found or unable to stat
|..]
Bien que tout appartienne à root, n'importe qui peut les lire et les exécuter et, donc, à fortieri, apache le peut égalemment.
D'après le code source: unless (-r $r->my_finfo && -s _) { $self->log_error("$self->[FILENAME] not found or unable to stat"); return Apache::NOT_FOUND; }
Le problème semble donc en fait ailleurs: pour une raison X le /otrs du web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche pas au bon endroit.
Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin dans ScriptAlias, mais pas dans le message d'erreur) : http://www.example.com/otrs/ ^
Si c'est ca le problème, alors votre ServerName n'est pas bon. Vous pouvez aussi corriger en enlevant les slashs finaux dans ScriptAlias/Alias (des deux côtés).
BTW, je pense qu'on est plus dans un problème de configuration Apache que (mod)perl là, je vous laisse soin de rediriger.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Raphaël 'SurcouF' Bordet
Patrick Mevzek wrote:
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not found or unable to stat
|..]
Bien que tout appartienne à root, n'importe qui peut les lire et les exécuter et, donc, à fortieri, apache le peut égalemment.
D'après le code source: unless (-r $r->my_finfo && -s _) { $self->log_error("$self->[FILENAME] not found or unable to stat"); return Apache::NOT_FOUND; }
Le problème semble donc en fait ailleurs: pour une raison X le /otrs du web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche pas au bon endroit.
Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin dans ScriptAlias, mais pas dans le message d'erreur) : http://www.example.com/otrs/
Le problème survient que j'ajoute ou pas un slash final.
Si c'est ca le problème, alors votre ServerName n'est pas bon. Vous pouvez aussi corriger en enlevant les slashs finaux dans ScriptAlias/Alias (des deux côtés).
Evidemment, cela ne change rien au problème...
BTW, je pense qu'on est plus dans un problème de configuration Apache que (mod)perl là, je vous laisse soin de rediriger.
Pour l'instant, je ne sais pas encore si ça vient de mod_perl ou d'apache...
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Patrick Mevzek wrote:
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not
found or unable to stat
|..]
Bien que tout appartienne à root, n'importe qui peut les lire et les
exécuter et, donc, à fortieri, apache le peut égalemment.
D'après le code source:
unless (-r $r->my_finfo && -s _) {
$self->log_error("$self->[FILENAME] not found or unable to stat");
return Apache::NOT_FOUND;
}
Le problème semble donc en fait ailleurs: pour une raison X le /otrs du
web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche
pas au bon endroit.
Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin
dans ScriptAlias, mais pas dans le message d'erreur) :
http://www.example.com/otrs/
Le problème survient que j'ajoute ou pas un slash final.
Si c'est ca le problème, alors votre ServerName n'est pas bon.
Vous pouvez aussi corriger en enlevant les slashs finaux dans
ScriptAlias/Alias (des deux côtés).
Evidemment, cela ne change rien au problème...
BTW, je pense qu'on est plus dans un problème de configuration Apache que
(mod)perl là, je vous laisse soin de rediriger.
Pour l'instant, je ne sais pas encore si ça vient de mod_perl ou d'apache...
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
[Fri Oct 08 12:54:28 2004] [error] 459: ModPerl::Registry: /otrs not found or unable to stat
|..]
Bien que tout appartienne à root, n'importe qui peut les lire et les exécuter et, donc, à fortieri, apache le peut égalemment.
D'après le code source: unless (-r $r->my_finfo && -s _) { $self->log_error("$self->[FILENAME] not found or unable to stat"); return Apache::NOT_FOUND; }
Le problème semble donc en fait ailleurs: pour une raison X le /otrs du web n'est pas transcrit en chemin physique, et donc ModPerl ne cherche pas au bon endroit.
Essayez la même URL mais avec un / à la fin (vu qu'il y a un / à la fin dans ScriptAlias, mais pas dans le message d'erreur) : http://www.example.com/otrs/
Le problème survient que j'ajoute ou pas un slash final.
Si c'est ca le problème, alors votre ServerName n'est pas bon. Vous pouvez aussi corriger en enlevant les slashs finaux dans ScriptAlias/Alias (des deux côtés).
Evidemment, cela ne change rien au problème...
BTW, je pense qu'on est plus dans un problème de configuration Apache que (mod)perl là, je vous laisse soin de rediriger.
Pour l'instant, je ne sais pas encore si ça vient de mod_perl ou d'apache...
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Raphaël 'SurcouF' Bordet
Raphaël 'SurcouF' Bordet wrote:
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...
Bien, finalement, on a décidé de se passer de mod_perl, l'application fonctionne égalemment sans et pour l'usage qu'on projette d'en faire les améliorations de performances qu'apporteraient mod_perl ne sont , finalement, pas primordiales.
Merci à toi, Paul ;-)
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
Raphaël 'SurcouF' Bordet wrote:
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...
Bien, finalement, on a décidé de se passer de mod_perl, l'application
fonctionne égalemment sans et pour l'usage qu'on projette d'en faire les
améliorations de performances qu'apporteraient mod_perl ne sont ,
finalement, pas primordiales.
Merci à toi, Paul ;-)
--
Raphaël 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net
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...
Bien, finalement, on a décidé de se passer de mod_perl, l'application fonctionne égalemment sans et pour l'usage qu'on projette d'en faire les améliorations de performances qu'apporteraient mod_perl ne sont , finalement, pas primordiales.
Merci à toi, Paul ;-)
-- Raphaël 'SurcouF' Bordet http://debianfr.net/ | surcouf at debianfr dot net
