"(CRON) info (aucun MTA installé, suppression de la sortie)" erreur dans le journal système

142

J'ai une nouvelle installation d'Ubuntu 12.04.1 LTS sur plusieurs serveurs.

Je n'ai pas ajouté de tâches cron ni édité mon crontab sur ces serveurs. Cependant, à la même heure pour chaque machine, j'obtiens un pic de processeur de 75% et les informations suivantes dans mon syslog au moment du pic:

CRON[8380]: (CRON) info (No MTA installed, discarding output)

J'ai installé mono-complet et exécute un serveur Web de pile de services.

Quelle est la meilleure façon pour moi d’empêcher que cela se produise? Je voudrais pouvoir supprimer le pic du processeur.

    
posée sungiant 27.11.2012 - 11:25
la source

9 réponses

136

Linux utilise le courrier pour envoyer des notifications à l'utilisateur. La plupart des distributions Linux ont un service de messagerie (y compris un MTA) installé. Ubuntu ne fait pas si.

Vous pouvez installer un service de messagerie, postfix par exemple, pour résoudre ce problème.

sudo apt-get install postfix

Ou vous pouvez l'ignorer. Je ne pense pas que l'incapacité de cron à envoyer des messages ait quelque chose à voir avec le pic du processeur (lié au travail sous-jacent que cron exécute). Il peut être plus sûr d'installer un MTA et de lire ensuite les messages ( mutt est un bon lecteur de courrier système).

    
réponse donnée martin 01.01.2013 - 09:56
la source
62

Cela se produit parce que vos tâches cron produisent des résultats, puis le démon cron essaie de vous envoyer cette sortie par courrier électronique (par exemple, root). Si vous n'avez pas besoin de cette sortie, la manière la plus simple de résoudre ce problème est de la supprimer au niveau de la crontab:

sudo crontab -e

et ajoutez >/dev/null 2>&1 à chaque travail:

* * * * * yourCommand >/dev/null 2>&1
    
réponse donnée rob 26.04.2013 - 12:27
la source
40

Dans mon cas, le message faisait allusion à un problème d’autorisations avec le script bash, mais je ne pouvais pas le voir avant d’avoir installé un MTA.

Comme suggéré, j'ai couru:

sudo aptitude install postfix

J'ai choisi "Local" pendant l'installation et après avoir exécuté à nouveau le job cron:

sudo tail -f /var/mail/<user>

Dans mon cas, j'ai remplacé

<user>

avec "root".

J'ai ensuite pu voir la sortie d'erreur liée aux permissions.

    
réponse donnée Martin Carstens 10.07.2015 - 16:28
la source
20

Dans crontab, ajoutez ceci comme première ligne:

MAILTO=""

Cela empêchera cron d’essayer d’envoyer un courrier électronique.

    
réponse donnée 88weighed 27.08.2015 - 15:06
la source
19

Si vous ne souhaitez pas installer un MTA (dont je n’ai pas besoin), vous pouvez diriger les résultats du job cron vers un fichier journal.

sudo crontab -e

alors avec votre travail cron ressemblerait à ceci.

0 3 * * * /cmd/to/run >> /var/log/somelogfile.log

alors vous pouvez simplement suivre le journal et voir ce qui s'est passé

sudo tail -f -n 50 /var/log/somelogfile.log

C'est ce que je fais sur n'importe quel serveur que je vois dans Syslog

    
réponse donnée Andrew MacNaughton 17.04.2016 - 21:37
la source
13

Comme indiqué dans une réponse précédente, cela se produit parce que vos tâches cron produisent des résultats, et puis le démon cron essaie de vous envoyer cette sortie par courrier électronique. Si vous ne voulez pas (ou ne pouvez pas) installer un MTA, mais vous voulez voir la sortie, vous pouvez rediriger la sortie du job cron vers un fichier journal. Modifiez votre fichier crontab avec

crontab -e

(utilisez sudo si le problème est lié à la crontab de la racine) et ajoutez >> /some/log/file 2>&1 après chaque commande, comme ceci:

0 3 * * * cmd  >> /some/log/file 2>&1

S'il y a plusieurs commandes sur une ligne, séparés par ; , && ou || , Vous devriez faire ce qui suit pour chaque commande, comme ceci:

0 3 * * * cmd1  >> /some/log/file 2>&1;  cmd2  >> /some/log/file 2>&1

ou regroupez-les, comme ceci:

0 3 * * * (cmd1;  cmd2)  >> /some/log/file 2>&1

Si vous voulez ignorer stdout et capturer uniquement stderr, utilisez plutôt > /dev/null 2>> /some/log/file . Placez le fichier journal où vous voulez - votre répertoire personnel, /var/log , ou même /tmp si vous êtes sûr de ne pas avoir besoin de le conserver.

Ensuite, regardez le fichier journal après l'exécution du travail.

    
réponse donnée G-Man 29.07.2016 - 04:40
la source
10

L’ajout de /dev/null 2>&1 à la commande de travail cron a pour effet secondaire de supprimer STDERR et STDOUT (erreur standard et sortie). Cela fonctionne bien si vous ne voulez pas de courriels de la part de cron. Mais si vous souhaitez que vos erreurs vous soient envoyées par courrier électronique, utilisez plutôt >/dev/null . Lisez cet article sur le blog pour plus d’explications .

Vous devrez quand même installer un agent de transfert de messages (MTA) pour envoyer les messages d'erreur. Postfix est assez simple à installer avec: sudo apt-get install postfix

    
réponse donnée paneer_tikka 30.12.2013 - 18:27
la source
8

Il s’agit d’une ancienne question mais il existe une réponse supplémentaire utile dans certaines circonstances.

Passez la sortie de votre commande cron dans logger pour qu'ils se retrouvent dans le journal système.

C'est légèrement plus facile que d'installer postfix, et il place cette sortie dans syslog avec vos autres journaux. Cette commande va capturer stdout AND stderr, vous ne verrez donc pas le message No MTA installed et vous verrez toutes vos sorties dans le syslog.

Exemple d’entrée cron:

0 3 * * * (cmd1;  cmd2) 2>&1 | logger -t mycmd

Vous pouvez afficher les journaux avec votre tag mycmd en utilisant:

grep 'mycmd' /var/log/syslog
    
réponse donnée Michael Hunter 23.10.2017 - 00:44
la source
1

Vous pouvez définir la variable MAILTO=”” au début de votre fichier crontab . Cela désactivera également l'alerte par courrier électronique. Modifier / Ouvrir vos tâches cron:

$ crontab -e

En haut du fichier, entrez:

MAILTO=""

lien

    
réponse donnée Damien Cuvillier 19.02.2018 - 06:18
la source

Lire d'autres questions sur les étiquettes