crontab все ще надсилає повідомлення електронної пошти навіть за допомогою / / dev / null


3

У мене є crontab (root), який запускає скрипт, а вивід - & gt; / dev / null, але я завжди отримую електронні листи, коли він запускається. Я лише хочу отримувати повідомлення про помилки.

# Rackspace driveclient update (12pm MST)
0 12 * * * /root/scripts/driveclient-update > /dev/null

Єдиний спосіб, який я можу отримати, щоб його вимкнути - це використовувати & gt; / dev / null 2 ​​& gt; & amp; 1, але потім не отримуватимуть повідомлення про помилки. Це відбувається на трьох різних серверах CentOS, два - 6.3, а один - 6.4.

ПРИМІТКА : Я читав знову і знову & gt; / dev / null повинен надсилати stdout там і запобігати електронній пошті, якщо немає нічого крім stdout з скрипта, так що працює принаймні для деяких людей; Я не можу зрозуміти, чому він не працює на цих серверах.

Ось приклад того, де & gt; / dev / null має працювати:

http://www.alphadevx.com/a/384-Suppressing-Cron-Job-Email-Notifications


Ось прекрасний приклад поведінки, яку я шукаю: alphadevx.com/a/384-Заборонені-Cron-Job-Email-Notifications Зокрема, розділ: "Якщо ви хочете отримувати лише повідомлення про помилки, але не успіхи ..." Чому це не працює на наших серверах CentOS?
user2344668

Щоб переконатися, ваш сценарій дійсно робить те, що потрібно, чи не так? Будь ласка, перенаправте STDOUT і STDERR до різних файлів і перевірте їх після цього. Це, мабуть, просто пише все до STDERR.
Daniel B

Сценарій просто виконує yum і wget; всі виходи з цих програм надсилаються електронною поштою, і це звичайний висновок, який вони друкують при ручному запуску в командному рядку. У мене немає пояснення, чому cron ігнорує & gt; / dev / null для stdout для програм, але не тоді, коли я використовую 2 & gt; & amp; 1 після цього; не було б сенсу, що yum і wget вихід скрипта обробляються як STDERR, якщо це просто нормальний вихід, так? Я думав, що його "так це працює" вихід був STDOUT.
user2344668

1
Просто для уточнення, це ВСІ АБО НІЧОГО з цим кронтабом. Все, що використовує & gt; / dev / null (чи ні) завжди надсилає всі повідомлення; все, що використовує 2 & gt; 1 ПІСЛЯ того, що ніколи нічого не надсилає електронною поштою. Я не можу пояснити цю поведінку. Там повинна бути якась конфігурація, де я не знаю, або я не набираю його саме так.
user2344668

Так Так. Тепер додайте >/var/log/mycron.log 2>/var/log/mycron.err і подивіться, де це потрапляє. :)
Daniel B

Відповіді:


3

Встановіть MAILTO = "you@me.com" у файлі crontab. І нехай ваш сценарій " луна 'stderr або stderr, коли виключення викидаються a $ (дочірня) . Все може статися, тому робота з повернутими значеннями (0 - це нормально, все інше - виняток), як у цьому прикладі:

#!/bin/bash
return=$(/usr/bin/curl --silent --show-error --fail "http://server/somestate" 2>&1)
exitcode=$?
if [ $exitcode != 0 ]
then
    echo "ERROR $HOSTNAME $0 $exitcode $return"
    logger "ERROR $HOSTNAME $0 $exitcode $return"
    exit $exitcode
else
    logger "INFO $HOSTNAME $0 $exitcode $return"
    exit 0
fi

MAILTO добре, це те, що ми хочемо. Проблема полягає в тому, що crontab посилає кожен вивід, а не просто stderr, так що незалежно від того, що я повторюю в сценарії, він буде виводитися, навіть якщо він виходить з підпроцесу, над яким я не контролюю. Наприклад, я запускаю yum check update або wget, і він виводить всі свої звичайні висновки і посилає мені електронну пошту. Я читаю всюди, що & gt; / dev / null має запобігти цьому, але це не так.
user2344668

Фокус в тому, щоб запустити свої скрипти або підпроцеси тихо, з тихим / тихим прапором і перенаправити нормальний висновок до nirwana за допомогою & gt; / dev / null. Якщо ви все ще отримуєте пошту, це висновок stderr, винятки, які потрібно вирішити.
bbaassssiiee

Таким чином, кожен скрипт у кожному cron, який запускається, повинен мати тихий прапор, а не просто поводитися так, як кажуть всі підручники, які я читаю? Перевірте, що посилання я додав у своєму початковому повідомленні. Чому він працює там, але не тут? Ваше рішення може працювати, але це багато речей, які я повинен додати для кожного cron, який повинен просто поводитися так, як система повинна працювати. Якщо cron перенаправлятиме 2 & gt; 1, то я не розумію, чому він не перенаправляє & gt; / dev / null. Це не stderr, що в даний час по електронній пошті, це нормальний stdout, саме те, що виходить від yum і wget, коли все працює нормально.
user2344668

Якщо ви встановите MAILTO = "" ви його не отримаєте.
bbaassssiiee

Давайте хлопці прочитали оригінальний пост. Я хочу отримувати листи лише тоді, коли виникла помилка.
user2344668

1

> тільки перенаправляє std out / err, електронна пошта є внутрішньою функцією самого сценарію. перевірити сценарій -h для додаткових параметрів або документів утиліти Rackspace


& gt; просто перенаправлення; & gt; / dev / null має перенаправляти stdout в / dev / null; 2 & amp; 1 перенаправляє stderr на stdout, який я не хочу. Я написав скрипт, не додав рядок, щоб надіслати електронний лист. Електронна пошта надходить від Cron Daemon. Будь ласка, поясніть. Запуск сценарію з -h просто запускає скрипт (тому що я не програмував цей варіант).
user2344668

електронна пошта не має ніякого відношення до stdout або stderr, тому перенаправлення не вплине на електронні листи. Перевірте змінні середовища; встановлено MAILTO? env
EkriirkE

Ви не розумієте; Я хочу ТІЛЬКИ помилки, надіслані через електронну пошту. В іншому випадку я не хочу надсилати електронний лист.
user2344668

0

Я виявив wget і yum відправити stdout до stderr так що мені довелося трубочки все, щоб журнал файлів.


0

Для подальшого використання. Вам не доведеться відправляти все в файл журналу. Можна сказати bash також відправити висновок на STDERR в / dev / null.

# Rackspace driveclient update (12pm MST)
0 12 * * * /root/scripts/driveclient-update > /dev/null 2>&1

Зверніть увагу, що все, що я робив, було додано 2>&1 до кінця файлу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.