Опции за запис на Bash
Ежедневните административни задачи на Linux изискват автоматизация. По правило автоматизацията се свежда до писане на bash скриптове и „въртенето им през cron“ или ръчно изпълнение в зависимост от задачата. Тази бележка съдържа общи практики за регистриране на bash скриптове. Целевата аудитория са системните администратори на Linux. Най-лесният и очевиден начин за съхраняване на резултата от скрипт е просто да го пренасочите към файл.
Всъщност трябва да добавитеSTDERRкъм изхода, защото съобщенията за грешка се записват в него:
Това се счита за нормална практика и обикновено удовлетворява повечето системни администратори. Но ако има няколко сървъра (десетки, стотици) и регистрирането е централизирано, по-удобно е да използватеlogger. Нека ви напомня, чеloggerе помощна програма, която изпраща съобщения доsyslog.
Предимството на този подход е, че можете да пренасочите изхода не само на bash скриптове.
Минуси - невъзможно е да се отделят съобщенията за грешка от други информационни съобщения, тъй като в този пример изходът е заседнал в един поток и всичко отива къмsyslogс приоритет user.notice (приоритет по подразбиране).
За някои задачи е приемлива следната опция:
В този вариант се регистрира самоSTDERR(STDOUTсе пренасочва към/dev/null) с приоритетгрешка. Съобщенията също се маркират с етикет с името на скрипта. Всичко това може да улесни отстраняването на проблеми със скриптове.
Недостатъкът на този подход е, че губимSTDOUT. За да разрешите този проблем, можете да използвате пренасочване на изходните потоци директно в скрипта.
Този пример илюстрира как можетепренасочванеSTDOUTиSTDERRнезависимо. За съжаление, този подход въвежда неочакван проблем: съобщения от различни нишки може да се окажат вsyslogв различен ред от този, в който са били изпратени. Това поведение се дължи на факта, че нишките се третират като два независими процеса. Въпреки това, методът често се използва за регистриране на скриптове, изпълнявани отcron.
Но понякога трябва да стартирате скрипта ръчно и в този случай не винаги е удобно да наблюдавате работата му в syslog.
В този примерteeкопира "входящия" поток къмloggerи обратно къмSTDOUT(поведение по подразбиране), а във втория случай къмSTDERR. По този начин получаваме регистриране вsyslog+ конзолен изход по време на изпълнение, което е полезно за скриптове, изпълнявани ръчно.
Влизането вsyslogе лесно. Регистрации вsyslog- това е полезно, особено ако регистрирането е централизирано. Когато пренасочвате изходните потоци паралелно, трябва да сте наясно с възможно нарушаване на реда на съобщенията.