Public Cloud-old - Exécuter un sript PHP avec cron (Debian 9)
... / Exécuter un sript PHP ave...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Frage

Exécuter un sript PHP avec cron (Debian 9)

Von
CorentinP3
Erstellungsdatum 2017-07-03 09:14:59 (edited on 2024-09-04 11:13:58) in Public Cloud-old

Bonjour,

Tout est dans le titre, j'aimerais exécuter un script PHP automatiquement avec cron mais ça ne fonctionne pas.
Je sais lancer le script manuellement mais pas automatiquement.
Voici un screen de ma commande sur le crontab et un screen du fichier sur mon FTP :
image

image

Voilà, je ne vois pas ce qui cloche :/
Merci d'avance :3


25 Antworten ( Latest reply on 2019-09-09 14:45:32 Von
CorentinP3
)

ton user est sudo ?

cron est exécuté en root, sudo inutile, donc ta ligne logiquement, comme indiqué dans les entêtes de crontab
```text
# m h dom mon dow user command
12 22 * * * root /home/path/snapshot.php
```

à moins vraiment que tu aies créé un user sudo?

Ah non mon user est "herobrix" et il n'est pas un user sudo.
Je devrais alors mettre 12 22 * * * herobrix /home/herobrix/server/snapshot.php ?

c'est ça, pour tester:
```text
*/x * * * *
```
cron toutes les x mn

Salut @CorentinP3

Je vois que tu es toujours sur ton script de Snap auto ^^

Je sais pas si ta vu, dans le nouveau manager, tu va dans la rubrique "workflow management"... Et la surprise, tu peux programmer des backups auto de tes instance \o/

En gros, le manager facilite l'interface avec la brique mistral d'openstack

Jalinn

Ca ne fonctionne toujours pas kyodev :/

Salut Jalinn ^^

Yep toujours dessus, il me semblait bien avoir réussi à le faire fonctionner avec le cron sauf qu'après réinstallation de mon serveur, pas moyen d’exécuter ce script automatiquement.

Je viens de créer la planification mais pas sûr que ce soit le plus opti, c'est marqué que ça fait une sauvegarde entre 22h00 et 06h00 (Pourquoi aussi imprécis ?) et surtout il faut que mon serveur soit éteint durant la sauvegarde pour éviter toute corruption.

pour la partie cron, je ne saurais trop te dire :/

Par contre, le workflow fait la meme chose que ton script...
Toi :
tu appel l'api qui va faire un snap (backup) de l'instance
Workflow Management :
Mistral va automatiquement faire un snap de l'instance.


c'est marqué que ça fait une sauvegarde entre 22h00 et 06h00 (Pourquoi aussi imprécis ?)


¯\\\_(ツ)_/¯
Après, tes pas obligé de passer par la rotation 7 ou 14 jours. Tu fais personnalisé et tu gère ton truc toi même.


il faut que mon serveur soit éteint durant la sauvegarde pour éviter toute corruption.


Non, c'est du live snapshot : le systeme prends l'image de ton serveur, crée un delta entre l'image et l'état actuel et fusionne le tout pour faire une image unique.
Lors de cette consolidation, si tu as un bdd avec beaucoup d'I/O, tu peux effectivement avoir des corruptions de tes data => assure toi juste de faire le snap durant tes périodes creuse ou de passer le site en maintenance qq minutes avant le snap)
Tu te dois de vérifier de temps à autre que les snap que tu fais sont fonctionnel (en créant une instance à l'heure depuis le snap par exemple).

Après, franchement, j'en utilise souvent et ça fonctionne plutôt bien dans tout les cas.

Jalinn

Merci pour ta réponse Jalinn !


Après, tes pas obligé de passer par la rotation 7 ou 14 jours. Tu fais personnalisé et tu gère ton truc toi même.


J'aimerais que ça se fasse par exemple à 00:52 tous les jours. Et je n'ai pas vu la possibilité de pouvoir personnaliser à ce point là.

Et je me rends compte surtout que ça fait une sauvegarde de mon instance et pas de mon volume x3

Bonjour,

Et quelle est la difficulté si tu fais le job cron toi-même? Si c'est le langage, je peux te donner des tuyaux, personnellement je ferais plutôt ce genre de job en shell, plutôt qu'en php.

Bonjour,

Eh bien le problème c'est que ma commande cron ne fonctionne pas justement. Pourtant le script fonctionne bien si je le lance manuellement. Je t'invite à regarder mon premier message pour voir la commande que j'ai entré dans le cron.

Et je suis obligé de passer par du PHP car j'utilise une API OVH et j'ai le choix entre du PHP et PYTHON.
https://api.ovh.com/console/#/cloud

Bonjour,

Eh bien le problème c'est que ma commande cron ne fonctionne pas justement. Pourtant le script fonctionne bien si je le lance manuellement. Je t'invite à regarder mon premier message pour voir la commande que j'ai entré dans le cron.

Et je suis obligé de passer par du PHP car j'utilise une API OVH et j'ai le choix entre du PHP et PYTHON.
https://api.ovh.com/console/#/cloud

Ps : désolé si tu reçois deux réponses, j'ai bugué x)

Tu peux tenter de mettre ça dans ta crontab du coup :
12 22 * * * /usr/bin/php /home/path/snapshot.php

Quand ta un doute sur la rédaction de ta cron, tu as des outils comme celui là qui peuvent t'aider :
https://1generator.org/generator.org/

Pour le workflow, oui, seul les instances sont backuper :/
Donc si tu intègre tes volumes add, faudra passer par du script...

jalinn

jalinn: tu ne mets pas le user?

pour connaître l'environnement dans cron, je fais ça:
```text
*/5 * * * * user ENV > /tmp/env.cron.txt
```
en 5mn, je peux alors lire le résultat:
```text
less /tmp/env.cron.txt
```
tu peux chercher des erreurs, dans *LE* shell (bash j'imagine) :
```text
su
grep -i 'cron' /var/log/syslog | less
exit
less /var/mail/user
less /var/mail/root
```


Eh bien le problème c'est que ma commande cron ne fonctionne pas justement. Pourtant le script fonctionne bien si je le lance manuellement. Je t'invite à regarder mon premier message pour voir la commande que j'ai entré dans le cron.


Donc ce qui ne marche pas c'est le fait de lancer un script php en cron? Envoi-moi le code php par un lien en MP, je pourrais te le traduire en Python.

php, ou autre ça ne change pas le cron...

Essaie de faire précéder le nom du script par php-cli, par exemple :

# Tous les jour de la semaine exepté le weekend de 8h à 18h
0 8-18 * * 1-5 php-cli -f script.php

```text
```text
$ php --version
PHP 7.3.8 (cli) (built: Aug 8 2019 08:37:41) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.8, Copyright (c) 1998-2018 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.3.2, Copyright (c) 2002-2018, by ionCube Ltd.

$ php-cli
bash: php-cli : commande introuvable
```

```text
cat /etc/crontab
...
# m h dom mon dow user command
...
``` ```

Alors plutôt php que php-cli, et il faut spécifier la string exacte du fichier, genre:

# Tous les jour de la semaine excepté le weekend de 8h à 18h
0 8-18 * * 1-5 php -f /home/utilisateur/script.php

Il faudrait aussi envoyer les sorties et les erreurs dans un fichier :

0 8-18 * * 1-5 php -f /home/utilisateur/script.php > /home/utilisateur/sorties.txt 2> /home/utilisateur/erreurs.txt

Si on veut tout mettre dans le même fichier:

0 8-18 * * 1-5 php -f /home/utilisateur/script.php > /home/utilisateur/sorties.txt 2> &1

> Le cron ne peut pas explorer le path.

ah bon?
comment peux tu affirmer sans connaître l'environnement?
j'ai montré comment le connaître

et **je ne parle pas de ça**, il suffit de lire, le cron est sur debian*, donc il manque des paramètres


cat /etc/crontab
# m h dom mon dow user command


oui, commande, mais commande OS, et toto.php n'est pas une commande os. Le cron ne peut pas explorer le path.

> Le cron ne peut pas explorer le path.

ah bon?
comment peux tu affirmer sans connaître l'environnement?
(j'ai montré comment le connaître)

et **je ne parle pas de ça**, il suffit de lire, le cron est sur debian*, donc il manque des paramètres

si corentin n'est pas sur debian like, alors oui ça changerait sa ligne initiale


jalinn: tu ne mets pas le user?


Pas forcement necessaire il me semble.
Dépends de l'OS et de l'utilisateurs qui lance la cron de base je crois (je peux me tromper aprés).

J'ai check rapidement sur google et plusieurs sites donnent la même info :

Voici un exemple de commande complet :
>php-cli -f /home/path/snapshot.php
ou
>/usr/local/bin/php -f /home/path/snapshot.php

Le " -f " permet de dire qu'on traite un fichier.

Reste plus qu'a @CorentinP3 de tester et nous dire ce que ça donne de son coté.

Jalinn

> Dépends de l'OS

oui, mais là c'est du debian, voire ubuntu (sudo), voir #1

le path /usr est donc accessible, php exécute par défaut le script
(c'est le comportement debian)

me reste à tester un cron sans user, mais à mon sens, ça ne peut marcher, car "php" (6e paramètre) sera traité comme le user, ou alors pour avoir une chance il faut quoter la commande:
`"php /home/path/snapshot.php"`

descriptif dans le crontab debian (les autres, je ne pratique pas):
```text
# * * * * * user-name command to be executed
```


si corentin n'est pas sur debian like, alors oui ça changerait sa ligne initiale

Hello :3 !
J'arrive un peu tard mais c'est pour vous prévenir que la commande sur le cron :
_12 22 * * * php -f /home/herobrix/server/snapshot.php_
fonctionne parfaitement :D !

Merci beaucoup !!!