web-dev-qa-db-fra.com

Les tâches cron apparaissent dans le planificateur GNOME mais ne s'exécutent pas

J'ai configuré Back In Time et l'administrateur MySQL pour effectuer une sauvegarde tous les jours à 15h00. Afin de m'assurer que j'ai installé Gnome Scheduler pour voir si ces deux applications sont enregistrées là-bas. Ils sont enregistrés dans le planificateur gnome mais ils n'effectuent pas d'opération de sauvegarde.

Voici la capture d'écran de Gnome Scheduler.

alt text Comment puis-je résoudre ce problème?

UPDATE

La sortie de la commande crontab -l est la suivante:

bakhtiyor@ubuntu-vm:~$ crontab -l
0 15 * * * /usr/bin/mabackup -d /home/bakhtiyor/backup/MySQL -x my-backup profile # JOB_ID_3
0 15 * * * Nice -n 19 /usr/bin/backintime --backup-job # JOB_ID_2

PDATE 2

La sortie de la commande grep CRON /var/log/syslog est la suivante:

Nov 30 11:39:01 ubuntu-vm CRON[7663]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Nov 30 11:39:02 ubuntu-vm CRON[7661]: (CRON) info (No MTA installed, discarding output)
backupcronbackintime
3
Bakhtiyor

Gnome Scheduler est juste un joli front-end pour at et crontab. Et par défaut, Ubuntu, cron exécute principalement anacron, qui est chargé d'exécuter des tâches périodiques sur des ordinateurs qui ne sont peut-être pas allumés au moment où la tâche est censée être déclenchée.

Les choses à vérifier sont:

  • cron est-il en cours d'exécution? ps -C cron
  • cron est-il configuré? cat /etc/crontab
  • cron appelle-t-il anacron à partir de/etc/crontab?
  • anacron est-il installé? ls /usr/sbin/anacron
  • cron ou anacron enregistre-t-il des messages? grep CRON /var/log/syslog

Pour la dernière étape, logrotate peut avoir archivé d'anciens syslogs, donc si grep ne donne aucun résultat, essayez

(cat /var/log/syslog.[0-9] ; zcat /var/log/syslog.*.gz) | grep CRON

Mon hypothèse est que gnome-scheduler configure des tâches avec des autorisations incorrectes (probablement en tant que personne et non en tant que superutilisateur) et que, par conséquent, les réclamations apparaîtront dans les syslogs.

réponse à mettre à jour

Étant donné l'invite du shell dans votre exemple crontab -l, vous avez certainement indiqué la crontab de bakhtiyor par utilisateur, qui ne dispose peut-être pas des autorisations nécessaires pour exécuter vos travaux (quelque peu opaques).

Les entrées de syslog indiqueront si les travaux sont en cours d'exécution et, le cas échéant, si les travaux se plaignent.

5
msw

Selon vos entrées de journal, il semble que vos tâches ne se soient pas exécutées récemment.

Vous devriez également consulter les journaux cron archivés, car ils pourraient avoir été retournés depuis leur dernière exécution.

Pour déboguer plus loin, j'ajouterais ce travail en utilisant crontab -e

*/5 * * * * echo hello

et voyez si cela vous envoie du courrier et s'il apparaît dans le fichier journal.

pdate: S'il apparaît dans le fichier journal mais ne vous envoie pas de courrier, vous devrez peut-être installer un agent de messagerie pour voir la sortie de vos tâches de sauvegarde ou les exécuter avec la sortie redirigée vers un journal. fichier. Par exemple, vous pouvez utiliser crontab -e pour modifier une ligne en

0 15 * * * Nice -n 19 /usr/bin/backintime --backup-job >> ~/log/backup.log 2>&1

vous devrez créer le répertoire ~/log.

2
poolie

Cette solution a fonctionné pour moi: https://answers.launchpad.net/backintime/+question/9051

Ma configuration de travail a été enregistrée sous mon utilisateur et non sous root car j'utilisais Sudo backintime-gnome et non gksu backintime-gnome.

Sudo ne changera pas ACCUEIL environ ce qui pose problème:

$ Sudo env | grep ^HOME
HOME=/home/user
$ gksu env | grep ^HOME
HOME=/root
1
Bjopp

J'avais le même problème et je l'ai résolu en ajoutant mon nom d'utilisateur au groupe crontab.

  1. Éditer /etc/group
  2. Localisez la ligne contenant crontab (il ne devrait y avoir qu'une seule ligne)
  3. Ajoutez votre nom d'utilisateur à la fin (si d'autres utilisateurs sont sur la ligne, séparez-les par une virgule)
  4. redémarrer
0
user149711

J'ai eu un problème similaire qui m'a donné tout un parcours. En supposant que cron, crontab et anacron soient sains, le symptôme clé est que la tâche s'exécute correctement si elle est appelée à l'aide du bouton "Exécuter maintenant" de gnome-schedule, mais qu'elle ne s'exécute pas comme prévu une fois laissée seule.

Cela s'avère être principalement un problème d'environnement graphique. Ma recommandation est de créer un wrapper pour le script de tâche, par exemple. "tâche-wrapper":

#!/bin/sh
gnome-terminal -x /home/username/task

Assurez-vous que le fichier de gestionnaire de tâches est exécutable et créez la tâche dans gnome-schedule en tant qu'application X. Alternativement, écrivez-le comme ceci:

#!/bin/sh
export DISPLAY=:0
gnome-terminal -x /home/username/task

Le script/home/nom d'utilisateur/tâche sera maintenant exécuté dans une fenêtre de la console qui se fermera à la fin. Mes scripts nécessitent généralement une authentification Sudo, je lance donc le script "task" comme suit:

#!/bin/sh
set -e
MESSAGE="The task script wants to ..."
gksudo --message "$MESSAGE" cd /whatever

La commande cd est inhabituelle, le MESSAGE explique pourquoi le script demande une autorisation et 'set -e' veille à ce que le script soit abandonné si l'utilisateur clique sur 'Annuler'. Le reste du script peut utiliser de simples appels 'Sudo' qui réussiront à moins que beaucoup de temps s'écoule entre les commandes.

Sous Ubuntu 12.04, l’appartenance à un groupe crontab ne semble pas nécessaire.

0
Urhixidur