[Ludo.H]

Bonjour @m4rc,

J'ai regardé vos logs : http://logs.ovh.net/***********/osl/...12-01-2016.log

Et je n'ai rien trouvé en erreur :

[2016-01-12 00:33:02] ## OVH ## START - 2016-01-12 00:33:02.927936 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 00:33:02]
[2016-01-12 00:33:02] ## OVH ## END - 2016-01-12 00:33:02.972884 exitcode: 0
[2016-01-12 01:33:02] ## OVH ## START - 2016-01-12 01:33:02.852268 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 01:33:02]
[2016-01-12 01:33:02] ## OVH ## END - 2016-01-12 01:33:03.046123 exitcode: 0
[2016-01-12 02:33:03] ## OVH ## START - 2016-01-12 02:33:03.134039 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 02:33:03]
[2016-01-12 02:33:03] ## OVH ## END - 2016-01-12 02:33:03.204214 exitcode: 0
[2016-01-12 03:33:03] ## OVH ## START - 2016-01-12 03:33:03.865069 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 03:33:03]
[2016-01-12 03:33:03] ## OVH ## END - 2016-01-12 03:33:03.926624 exitcode: 0
[2016-01-12 04:33:02] ## OVH ## START - 2016-01-12 04:33:02.987064 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 04:33:02]
[2016-01-12 04:33:02] ## OVH ## END - 2016-01-12 04:33:03.033464 exitcode: 0
[2016-01-12 05:33:03] ## OVH ## START - 2016-01-12 05:33:03.184803 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 05:33:03]
[2016-01-12 05:33:03] ## OVH ## END - 2016-01-12 05:33:03.321157 exitcode: 0
[2016-01-12 06:33:03] ## OVH ## START - 2016-01-12 06:33:03.467006 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 06:33:03]
[2016-01-12 06:33:03] ## OVH ## END - 2016-01-12 06:33:03.540624 exitcode: 0
[2016-01-12 07:33:03] ## OVH ## START - 2016-01-12 07:33:03.033350 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 07:33:03]
[2016-01-12 07:33:03] ## OVH ## END - 2016-01-12 07:33:03.078933 exitcode: 0
[2016-01-12 08:33:03] ## OVH ## START - 2016-01-12 08:33:03.272954 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 08:33:03]
[2016-01-12 08:33:03] ## OVH ## END - 2016-01-12 08:33:03.318168 exitcode: 0
[2016-01-12 09:33:03] ## OVH ## START - 2016-01-12 09:33:03.297862 executing: /usr/local/php5.5/bin/php /homez.551/**********/cam/index.php
[2016-01-12 09:33:03]
[2016-01-12 09:33:03] ## OVH ## END - 2016-01-12 09:33:03.403028 exitcode: 0

Cdt,

[coug]

Bonjour,

Pour ma part je n'ai pas creusé plus. Donc pas vraiment de solution.

Cordialement,
Sylvian

[jmgrange]

Bonjour,
J'ai exactement le même problème avec un script PHP qui s'exécute sans erreur (exit code 0 et effectivement le job est correct et le résultat bon) mais toujours cette erreur dans le log.
Quelqu'un a-t-il trouvé une solution, ou faut-il laisser tomber et ignorer.
Cordialement
Jean-Michel Grange

[m4rc]

oui, si tu as un dédié sous le coude.
pour comparer avec ce que produit un cron hébergé sur mutu (et donc en passer par le manager ovh pour programmer le cron)

voir si tu reproduis le log d'erreur apache ?

cdlt

[janus57]

peut etre que janus a un dédié pour tenter un cron.?

Bonjour,

Tu veux que je test un script en cron ?

Cordialement, jnaus57

[m4rc]

peut etre que janus a un dédié pour tenter un cron.?

[coug]

Bonjour,

effectivement on a corrigé le problème ioncube et l'erreur header est toujours là. Aucune idée pourquoi ça fait ça.

[m4rc]

je n'ai aucune erreur retournée par mon script, et donc rien ne remonte dans le log cron (exit code=0)

il serait intéressant d'essayer de corriger cette erreur ioncube d'abord, mais je pense que tu te retrouveras alors dans le meme cas que moi.
je me rappelle que j'avais également un autre script croné, qui cette fois était hébergé dans l'espace publié, qui cette fois produisait une sortie (sans erreurs), et qui laissait aussi cette même erreur apache, sans pour autant poser de pb d'execution.

aussi je crois que c'est vraiment au niveau de la commande cron elle meme, et peut etre de la façon dont elle est intégrée aux espaces mutu, interfacé dans le manager ovh ..?

=> un test interessant serait de faire tourné un cron sur un hébergement dédié linux, voir si on y retrouve aussi cette erreur..?

[coug]

tes logs correspondent aussi sans doute a un job cron aux vues des timestamps, espacés d'une heure.
que fait ton cron ?
qu y a t il dans ton log "cron" ?
cdlt

- - - Mise à jour - - -

dans tes logs d'erreur d'avant hier (quand tu n'avais pas encore derreur avec tes pdf), il n'y avait pas déjà ces erreurs là ?

Alors pour l'export PDF c'est la MAJ de mysql en 5.5 qui me faisait planter les requêtes. Là c'est résolu.

Effectivement c'est bien un cron qui me génère les erreurs error reading header. Dans les logs cron j'ai comme erreur requires the ionCube PHP Loader et ça date de quelques mois. On a fait des tests au printemps qu'on a pas fini.

Tu n'as aucune erreur dans les logs cron ?

[m4rc]

tes logs correspondent aussi sans doute a un job cron aux vues des timestamps, espacés d'une heure.
que fait ton cron ?
qu y a t il dans ton log "cron" ?
cdlt

- - - Mise à jour - - -

dans tes logs d'erreur d'avant hier (quand tu n'avais pas encore derreur avec tes pdf), il n'y avait pas déjà ces erreurs là ?

[coug]

Salut à tous,

J'ai le même soucis : jusqu'à hier 18h30 tout fonctionnait bien. Ce matin, impossible d'exporter un fichier pdf

Voilà les logs:

[Tue Sep 01 02:17:02 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 02:24:02 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 03:17:01 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 04:17:02 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 05:17:01 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 06:17:02 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 07:17:03 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers
[Tue Sep 01 09:17:02 2015] [error] [client 10.0.55.81] [host machin.cluster007.ovh.net] request failed: error reading the headers

Je sais pas ce qu'OVH a modifié mais pour moi c'est pénalisant : impossible de récupérer les factures et les devis.

Si quelqu'un a une idée ou si quelqu'un de OVH passe....

[m4rc]

bon ben je vais continuer de l'ignorer pour le moment..
que le support se concentre d'abord a répondre à mes demandes plus pressantes d'abord
=> recréation d'un hébergement expiré sur une offre inférieure (ils font tout pour qu'on sorte la CB => là action immédiatement prise en compte) pour une offre inférieure, vous devez attendre l'expiration de l'offre, puis +10j après l'expiration; perdant au passage vos comptes mails- ensuite, envoyer un mail au support .... (le ticket doit être en niveau "très très très bas") et après..? là ca fait plus de 15j, heureusement que j'ai un autre hébergement ovh, sinon ils aurait laissé mon site à poil en code 503. sympa.

bref ne les emcombront pas..

et le mystère deumeure donc ;s

[janus57]

Bonjour,

En tout cas je vois pas d'autre cas que ceux évoqué plus haut, maintenant soit suffit d'ignorer cette erreur (après tout le script fonctionne) soit le remonter au support.
Je vois pas comment tester autrement vu que y aucun accès à la config apache.

Cordialement, janus57

[m4rc]

1- en l'occurence, comme il n'y a pas de sortie, la seule histoire d'encoding ou de "mauvais caractère" possible résiderait dans le listing des noms de fichiers par l'itérator.
mais tous les noms de fichiers ont cette tete, seuls les timestamps changent :
00626E4FE8CC(FOSCAM (wifi))_1_20150830065628_256.jpg
2- non plus
3- ca y ressemble certes, pourtant j'appelle le fichier par cron, et ne gère donc aucun appel ni get ni post juste une ligne dans la table cron. le script c'est juste (par ex):

$limit = "2 days";
$clean = new CleanOld( $limit );

et un appel a une classe qui fait (cas le plus bateau) - on est dans un directoryIterator php:

if ( $v!="."
&& $v!=".."
&& !is_dir($v)
&& (
strcasecmp( $extension, "jpg")==0
OR strcasecmp( $extension, "jpeg")==0
OR strcasecmp( $extension, "png")==0
)
&& filemtime(self::SRV_PATH.$v) < strtotime("-".$this->limit)
)
unlink(self::SRV_PATH.$v);

rien de très sorcier bref.

4- le cron ne remonte pas dans le log apache d'accès web, ce qui est normal, et le log cron ne fait pas état du code d'erreur. mais normalement le code de retour exit 0, doit signifier un HTTP 200 si je ne m'abuse. bref un code 4xx devrait renvoyer un autre code cron que 0 je crois.

les logs cron ne montrent que les lignes indiquées, une par occurence cron et rien d'autre.
:s

[janus57]

Bonjour,

la version PHP c'était surtout pour savoir l'encodage interne de PHP qui a commencé à changer en 5.4 et maintenant (PHP5.6) 100% en UTF-8, donc certaisn script qui traite des données ISO-8859-1 se pête la gueule à cause de ça (vécu).

Bref donc les multiples possibilité pour que apache renvoi ce genre d'erreur sont :
1 - mauvais caractère (pour une raison X) apache recoit des "^@^@" par exemple
2 - timeout apache (ici c'est pas le cas).
3 - la requête GET/POST qui appel ce fichier qui est mal formé (suffit de tester en appelant un simple fichier qui affiche Hello World via un echo).
4 - autre ? (ceci est équivalent à une erreur HTTP 400 normalement).

Aucune réécriture ou directive dans un .htaccess ne touche le fichier de cron ?

Dans les logs d'accès au passage du cron y a rien d'autre ?

Cordialement, janus57

[m4rc]

les fichiers sont encodés, comme tous les autres, en utf8 sans support BOM
pas de soucis d'encodage
la version php ne devrait pas etre en cause, simple appel a une classe directoryIterator, qui est en natif php depuis.. ? fort assez longtemps.
quoi qu'il en la version actuelle est PHP 5.5 ; mais n'étant pas dépendant de la version , il me semble avoir déjà fait le tour des versions proposées dans le manager. et puisqu'elles sont proposées par le manager pour l'exe du cron, ET que la classe directoryIterator existe dans chacune d'elle.. ce n'est pas là.
d'ailleurs, les erreurs de script de ce type, s'il y a, sont relayées dans les logs cron d'ovh, comme toute sortie de scripts cronés.

le temps d'execution des scripts, comme tu peux le voir dans les logs cron fournis, sont de l'ordre de 0,09 secondes..

l'erreur apparait invariablement, qu'il y ait des fichiers à effacer répondant aux conditions, ou aucun.

[janus57]

Bonjour,

pas un soucis d'encodage du script ?
Le fichier encodé comment ? quel version de PHP du cron ?
Temps d’exécution du script ?

Cordialement, janus57

[m4rc]

sur mon mutu cluster011, j'ai un petit script php appelé en cron qui fait un peu de nettoyage en supprimant des fichiers selon conditions (dépassés une certaine date, etc..)

notons que seule exhubérance, le script est hébergé en dehors de l'espace web publié. (inutile pour un usage via cron exclusivement).

ensuite, le script ne gènère pas de sortie, là encore, à quoi bon.

le script fonctionne bien, il fait correctement le travail attendu pour ce qui est du nettoyage. A vrai dire, voila bien des mois qu'il tourne merveilleusement.

en revanche, une mystérieuse erreur apache deumeure, à CHAQUE passage du job (c'est vraiment constant) :

[Mon Aug 31 11:33:02 2015] [error] [client 10.0.55.31] [host machin.cluster011.ovh.net] request failed: error reading the headers

le job s'execute en retournant TOUJOURS un code 0, qui me semble-t-il signifie que tout va pour le mieux dans le meilleur des mondes.

[2015-08-31 03:33:03] ## OVH ## START - 2015-08-31 03:33:03.689871 executing: /usr/local/php5.5/bin/php /homez.551/machin//index.php 
[2015-08-31 03:33:03] 
[2015-08-31 03:33:03] ## OVH ## END - 2015-08-31 03:33:03.774146 exitcode: 0

j'ai lu et relu des articles à n'en plus finir régulièrement, mais -à part peut être le manque de sortie, et encore, je vois pas pourquoi- je ne comprends pas cette erreur ni sa cause.