Dans un projet personnel, j’ai eu besoin de lancer un script régulièrement sur mon hébergement mutualisé OVH. Et j’ai constaté que ce n’est pas simple ! Je décris ici un script test, qui fonctionne après de multiples essais.

Le principe

Je veux que OVH exécute un script PHP à fréquence régulière. Le script PHP présenté ici réalise différentes activités qui permettent de vérifier que mes réglages sont bons. Il s’agit en effet de répondre aux questions suivantes :

  • comment faire pour que OVH exécute régulièrement un script (PHP ici) ?
  • Si le script doit accéder à d’autres fichiers, comment lui “dire” où les trouver ?
  • Si le script doit envoyer un mail, quelles sont les spécifications pour que ça fonctionne ?
  • Comment faire pour deboguer et afficher ce qui se passe durant le script “croné” ?

Ecriture du script PHP

Le fichier “cron-test.php”final, qui fonctionne, contient les éléments suivants :

#!/usr/local/bin/php

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<title>Test de Cron</title>
	</head>
	<body>
		<h2> Le test commence </h2>
		<?php
		/**
		* test script
		**/

		$path = dirname( __FILE__ );
		
		// https://forum.ovh.com/showthread.php/101095-taches-planifi%C3%A9s-ne-s-executent-plus/page2

		define('ROOT',dirname( __FILE__ ));

		
		include_once ROOT . '/al-pi-cron-test.php';

		$line1 = $path ;
		$line2 = "ligne 2" ;
		$line3 = "ligne 3" ;

		date_default_timezone_set('CEST');
		$today = date("F j, Y, g:i a"); 


		$to      = 'adresse@gmail.com, autreadresse@hotmail.fr'; 
		$subject = 'cront-test.php  !!!';
		$message = $line1 . "\r\n" . $line2 . "\r\n" . $line3 . "\r\n" ;
	
		$send_mail = al_send_email( $to, $subject, $message) ;
			
		
		
		
		$fp = fopen( ROOT . '/My-pi/cron-pi.log', 'a' );  
		fwrite( $fp, "\r\n -----------------TEST----------------------------------- \r\n" );
		fwrite( $fp, $today . "\r\n" );
		fwrite( $fp, $line1 . "\r\n" );
		fwrite( $fp, $line2 . "\r\n" );
		fwrite( $fp, $line3 . "\r\n" );
		fwrite( $fp, "Résultat envoi Mail : " . $send_mail . "\r\n" );		
		fwrite( $fp, "\r\n -------------------------------------------------------- \r\n" );
		fclose($fp);
		?>
  
		<h2> Le test est terminé </h2> 

  
	</body>
	</html>

La partie html permet de visualiser (et lancer) le script à partir d’internet, en tapant l’adresse http://mon-site.com/cron-test.php, comme ci-dessous.
Affichage sur navigateur internet

Ce qui est réellement important, c’est le code php.

Pour que OVH puisse exécuter ce script en cron

Il vaut mieux (c’est optionnel pour du PHP), indiquer en toute première ligne du fichier comment il doit se décoder :

#!/usr/local/bin/php

Mais surtout, il faut comprendre que l’environnement dans lequel s’exécute un cron n’est pas celui dans lequel on exécute à la main (ou dans le navigateur comme ci-dessus). Le script ne sait pas où il est et il faut lui donner l’information ! On définit ainsi une variable ROOT avec la fonction define() puis on l’indique à chaque fois qu’il faut aller chercher un fichier, ici lorsqu’on veut utiliser un autre fichier pour définir les fonctions utilisées ou pour indiquer le chemin vers un fichier cron-pi.log que l’on veut ouvrir pour y ajouter du texte à la fin.

define('ROOT',dirname( __FILE__ ));

include_once ROOT . '/al-pi-cron-test.php';

$fp = fopen( ROOT . '/My-pi/cron-pi.log', 'a' );

Et voilà, les éléments indispensables pour qu’un script PHP puisse être exécuté en CRON sont identifiés !

Notez que la ligne ci-dessous fait appel à une fonction qui est écrite dans le fichier al-pi-cron-test.php appelé avec la fonction include_once.

$send_mail = al_send_email( $to, $subject, $message) ;

Réglage du Cron sur OVH mutualisé

Aller sur l’espace client OVH et sélectionner l’hébergement du nom de domaine correspondant. Cliquer sur l’onglet Cron puis choisir “ajouter une planification”.

Dans mon cas, le script est placé dans le répertoire pi-suivi/ .

cron job sur OVH (mutualisé) : étape 1

Après avoir cliqué sur suivant, il faut que je choisisses la fréquence de réalisation du script. Ici j’ai utilisé le mode simple et je n’ai rien modifié : je veux une exécution toutes les heures. Noter qu’on ne peut pas régler les minutes, même en mode expert. Sur un hébergement mutualisé OVH, ce n’est pas possible.

cron job sur OVH (mutualisé) : étape 2

Après avoir cliqué sur “suivant”, voici la synthèse de ce que j’ai choisi. Notez le “?” pour les minutes. C’est OVH qui va en décider la valeur.

cron job sur OVH (mutualisé) : étape 3

Je valide et j’attends 1 à 2 minutes. Je rafraichis la page de mon espace client OVH et la tâche Cron apparaît. J’avais déjà créé une autre tâche Cron. On voit que OVH a décidé qu’elle s’exécuterait à chaque fois qu’il est xh51. La deuxième tâche sera elle réalisée à chaque fois qu’il est xh40.

cron job sur OVH (mutualisé) : étape 4

J’attends qu’il soit xh40 et quelques, puis je vois que mon script s’est exécuté : j’ai reçu le mail généré par la fonction

Déboguage

Pour en arriver là, j’ai bien galéré et j’ai dû apprendre comment déboguer sur OVH.

En particulier, j’ai finalement trouvé où se trouvent les logs des hébergements mutualisés ! Il suffit de taper “https://logs.ovh.net/mon-site.com/ puis d’indiquer son identifiant OVH et son mot de passe (ceux qu’on utilise pour accéder à l’espace client). Par exemple, mes logs sont sur https://logs.ovh.net/parcours-performance.com/.

On trouve alors une ligne contenant “Cliquez ici pour voir les logs bruts en temps réel : web – ftp – error – cgi – out – ssh – cron”. On clique sur “cron” et on accède au dernier log des cron.

Les logs commencent par, et se terminent par ce qui suit. Entre les deux lignes, il y a le HTML. Ici j’ai remplacé le chemin vers mon répertoire par *** pour des raisons de sécurité.

Un cron s’est exécuté correctement s’il se termine par exitcode:0.

[2015-10-05 12:51:02] ## OVH ## START - 2015-10-05 11:23:02.575704 executing: /usr/local/php5.5/bin/php ***/pi-suivi/cron-test.php 
[2015-10-05 12:51:02] ## OVH ## END - 2015-10-05 12:51:03.454292 exitcode: 0

Mais évidemment, du point de vue du serveur un cron se termine correctement s’il n’y a pas d’erreur. De mon point de vue, il est terminé correctement s’il a réalisé ce que j’attendais….

Ecrire dans un fichier permet de vérifier ce qui se passe durant l’exécution du code. Ainsi j’ai défini $line1 puis je l’écris dans le fichier log défini. Ca me permet de savoir dans quel répertoire se déroule le travail.

Mais un des rôles les plus importants d’un tel fichier log est de nous dire si les choses se sont bien passées :

exemple 1 : écrire dans un log le résultat d’une interaction

Dans le script ci-dessus, j’appelle une fonction, al_send_email, par la commande :

$send_mail = al_send_email( $to, $subject, $message) ;

Cette fonction (non présentée ici ) gènère un mail à destination de $to, avec $subject comme objet et $message dans le corps du mail.  C’est bien beau de lancer une fonction. Mais ce qui est essentiel, c’est de savoir si le mail a effectivement été expédié.

Et bien $send_mail contient cette information maintenant que la fonction a été exécutée. En effet la fonction contient la ligne ‘return $result ;” et $result est réglé à  ” ### ” . $send_Mail . ” – Erreur envoi mail <br> \n” si le serveur de messagerie n’a pas répondu “true” lors de l’envoi. Je peux donc indiquer dans mon log si tout s’est bien passé.

exemple 2 : écrire dans un log le contenu d’un tableau (array)

Un autre exemple où la constitution d’un log est essentielle pour déboguer un script, c’est lorsqu’on manipule des tableaux (array).

Dans un autre script php j’utilise cette fonctionnalité en définissant $line1 comme contenant toutes les valeurs d’un array $list_pi :

$line1 = var_export( $list_pi, true ) ;

Le log correspondant va ainsi contenir le texte suivant pour $line1 :

array (
  0 => 'val1',
  1 => 'val2',
  2 => 'val3',
)

D’un coup d’oeil dans le log, je vois si le script tel que réalisé dans l’environnement cron s’est déroulé comme prévu.

Maintenant, il ne reste plus qu’à trouver d’autres actions à réaliser fréquemment. Il peut s’agir d’une sauvegarde de la base de données ou d’autres constructions plus sophistiquées.

0 0 vote
Article Rating
2
0
Would love your thoughts, please comment.x
()
x