Чому cron вимагає MTA для ведення журналу? Чи є якась певна перевага цьому? Чому він не може створити файл журналу, як більшість інших утиліт?
Чому cron вимагає MTA для ведення журналу? Чи є якась певна перевага цьому? Чому він не може створити файл журналу, як більшість інших утиліт?
Відповіді:
Врахуйте, що традиційним "стандартним" способом реєстрації даних є syslog , де метадані, що входять у повідомлення, - це "код об'єкта" та рівень пріоритету. Код об'єкта може використовуватися для відділення потоків журналів від різних служб, щоб їх можна було розділити на різні файли журналів тощо (навіть якщо коди об'єктів дещо обмежені тим, що вони фіксують традиційні значення.)
Що у syslog не існує, це спосіб розділити повідомлення для або від різних користувачів, і це те, що cron
потрібно в традиційній багатокористувацькій системі. Немає сенсу збирати повідомлення з усіх завдань cron усіх користувачів у загальний файл журналу, де їх може бачити лише адміністратор системи. З іншого боку, електронна пошта, природно, передбачає надсилання повідомлень різним користувачам, тому це логічний вибір тут. Альтернативою було б cron виконувати роботу вручну та створювати логістичні дані до домашнього каталогу кожного користувача, але традиційна багатокористувацька система Unix, як вважається, має працюючу MTA, тому реалізація її в cron була б переважно марні вправи.
У сучасних системах, звичайно, можуть бути альтернативні варіанти.
Я припускаю, що під «реєстрацією» ви маєте на увазі збереження фактичного випуску робочих місць. Хід робіт вже реєструється в журналі хрон в /var/cron/log
(шлях може відрізнятися між системами). Для цього журналу не потрібно вимагати MTA.
Завдання cron виконується як той користувач, до якого входить завдання crontab.
У загальному випадку немає гарантії, що цей користувач зможе створювати файли в системі (користувач може не бути інтерактивним користувачем), особливо не за /var
ієрархією, де зазвичай створюються журнали. Отже, найбезпечніший спосіб сповістити користувача про помилки та інший вихід із завдання - це зібрати їх та надіслати їх електронною поштою користувачеві. Це також дозволить користувачеві налаштувати переадресацію електронної пошти для акаунта, щоб він міг бачити, наприклад, помилки у своєму бажаному місці.
Якщо користувач хоче зберегти вихідний файл у файл, він може зробити це за допомогою простого перенаправлення в crontab:
0 */2 * * * "$HOME/scripts/myscript" >"$HOME/logs/myscript.log" 2>&1
Це буде працювати "$HOME/scripts/myscript"
кожну другу годину, в годину, і збереже весь вихід "$HOME/logs/myscript.log"
. Не буде створено жодної електронної пошти при виконанні цього завдання, оскільки весь вихід буде переспрямований. Без цього 2>&1
повідомлення про помилки все одно надсилатимуться електронною поштою.
Це дозволяє користувачеві вибрати, куди йде вихід.