Cron et script lancé à la main

[UsagiYojimbo]

Bonjour à tous,

J'aurai besoin de quelques pistes pour les ténors de l'administration serveur, ce que je ne suis pas.

Sur un site sur lequel je taffe, on a mis en place un Zend Lucene, pour le moteur de recherche. On a donc un script qui requête en base de donnée pour indexer les contenus.

Lorsque je lance ca script à la mano (en ligne de commande via putty), je n'ai pas de soucis (le moteur de recherche public, qui ouvre les index Zend et les parcours fonctionne parfaitement), mais quand il s'agit du cron, les index ne se génèrent pas correctement (le moteur de recherche public na parvient a priori pas à ouvrir les index Lucene, qui sont pourtant bien générés lors di passage du cron).

Quelqu'un connaît ce genre de problématique et a des idées/suggestions ?

 

[dmathieu]

Généralement, il peut y avoir plusieurs possibilités :
- L'utilisateur avec lequel est fait le cron n'est pas le même que celui avec lequel tu lance le script manuellement et il n'a pas accès à l'exécution du fichier.
- Tu requiert une librairie à laquelle l'utilisateur n'a pas accès (ça se vois surtout en Python. Si ton truc est en PHP, tu a peu de chances).

Pour trouver d'ou cela vient, j'ai configuré ma machine pour recevoir un email contenant la sortie console de la crontab à chaque fois que l'une d'elle est exécutée.
Vois avec ton administrateur système si il peut pas te mettre ça en place.

 

[forty]

chez OVH j'ai eu des soucis avec un cron car des variables comme $_SERVER['HTTP_HOST'] n'étaient pas alimentées.

 

[UsagiYojimbo]

J'ai fait quelques tests cet après-midi et j'ai notamment relevé certains soucis dans mon script, qui ne fonctionnait de toutes façon pas si on le lançait plusieurs fois de suite. Au première passage tout est ok, mais au second j'ouvre l'index Lucene sans le fermer par la suite, alors que je n'insère rien dedans. Par ailleurs je supprimais manuellement les fichiers de lock après avoir ouvert l'index, ce qui doit pas être très top.

 

[dmathieu]

Et du coup maintenant ça fonctionne ?

 

[jcaron]

chez OVH j'ai eu des soucis avec un cron car des variables comme $_SERVER['HTTP_HOST'] n'étaient pas alimentées.

Ce qui est assez normal: ces variables correspondent à des informations liées à une requête http (et sont fournies par Apache ou autre serveur web). Une commande lancée en cron (ou à partir de la ligne de commande) n'est pas une requête http, donc aucune de ces variables ne sera renseignée.

Pour le cas général "marche en ligne de commande mais pas en cron", un grand classique ce sont les variables d'environnement (export en sh/bash/etc, setenv en csh/tcsh/etc) qui ne sont pas initialisées de la même façon (cron n'exécute pas les .login/.cshrc/.profile etc.).

Jacques.

 

[screuscreu]

J'ai une question toute autre ...
Pourquoi devoir relancer l'indexation de lucene dans un cron ?
Une fois fait à la main au lancement, il suffit de modifier les clé de ton index à chaque update/insert/delete de ta bdd, cela sera moins consommateur (pas de pic) et toujours à jour.

 

[UsagiYojimbo]

Et du coup maintenant ça fonctionne ?

Yep le CRON est passé cette nuit sans souci.

@screuscreu : je note la proposition avec intérêt pour un futur projet. N'étant pas le développeur de cette partie du truc, j'ai juste du me plonger dans cette partie du site pour le remettre sur les rails.