{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Копытов Иван: заметки с тегом syslogd",
    "_rss_description": "Блог ленивого сисадмина",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/kini24.ru\/tags\/syslogd\/",
    "feed_url": "https:\/\/kini24.ru\/tags\/syslogd\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Копытов Иван",
            "url": "https:\/\/kini24.ru\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "97",
            "url": "https:\/\/kini24.ru\/all\/syslog-prodolzhaem-nablyudenie\/",
            "title": "Syslog. Продолжаем наблюдение",
            "content_html": "<p>Наблюдение показало, что «валится» syslogd в очень определенное время — в момент окончания работы logrotate. Пройдя через цепочку файлов, наткнулся на упоминание reload-syslog в папке \/sbin. Полез посмотреть что это за файл, а он представляет собой обычный скрипт, в котором есть такая строчка:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">\/sbin\/service $n reload &amp;&amp; break<\/code><\/pre><p>Мелькнула «шальная» мысль, которая заставила меня заменить <i>reload<\/i> на <i>restart<\/i>. Следом я удалил скрипт, который перезапускал syslogd через 1 час, после того, как он «вешался». День первый — полет нормальный. Продолжаем наблюдение...<\/p>\n",
            "date_published": "2017-10-03T17:43:19+07:00",
            "date_modified": "2017-10-03T17:43:14+07:00",
            "tags": [
                "syslogd",
                "исправление",
                "наблюдение",
                "ошибка"
            ],
            "_date_published_rfc2822": "Tue, 03 Oct 2017 17:43:19 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "97",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "94",
            "url": "https:\/\/kini24.ru\/all\/prodolzhaem-nablyudenie-za-syslog\/",
            "title": "Продолжаем наблюдение за syslog",
            "content_html": "<p>Как писал <a href=\"https:\/\/kini24.ru\/all\/problemy-s-zhurnalami-v-linux\/\">ранее<\/a> на сервере наблюдаются проблемы с syslog. Этот паршивец каждую ночь перестает писать журналы. Причины пока непонятны, надо будет задать вопрос разработчикам системы. В качестве временной меры выбран перезапуск службы в планировщике cron. Этого, по идее, должно быть достаточно. По крайней мере, пока что. Дальше будем разбираться. Ситуацию усложняет момент, что время в журналах записывается на тот момент, когда была перезапущена служба, а не то, когда что-то произошло. Иными словами, я не могу отследить кто или что «подвешивает» её. Но, с учетом вероятного времени «подвисания» syslogd, можно предположить, что это происходит после выполнения заданий в \/etc\/cron.daily. То есть, можно по одному удалять оттуда файлы и наблюдать после чего служба перестанет «вешаться».<br \/>\nЕсли выполнить команду<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">service syslogd status<\/code><\/pre><p>то система ответит «active». Но запись журналов начнется после перезапуска syslog. В общем, пока что «продолжаем наблюдение» и экспериментируем.<\/p>\n",
            "date_published": "2017-10-02T00:05:32+07:00",
            "date_modified": "2017-10-02T00:05:51+07:00",
            "tags": [
                "syslogd",
                "наблюдение",
                "проблема",
                "эксперимент"
            ],
            "_date_published_rfc2822": "Mon, 02 Oct 2017 00:05:32 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "94",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "92",
            "url": "https:\/\/kini24.ru\/all\/problemy-s-zhurnalami-v-linux\/",
            "title": "Проблемы с журналами в linux",
            "content_html": "<p>Давненько уже заметил, что перестали писаться некоторые журналы. Если быть точней, то, наверное, большинство. Поэтому правильней было бы сказать, что писались только некоторые. Потихоньку экспериментировал с journalctl, но результатов это не приносило. Да и другой работы было столько, что времени особо и не хватало. Сегодня в очередной раз вспомнил об этой проблеме, решил покопаться, пока рабочий день потихоньку подходил к концу — я ожидал окончания проверки диска.<br \/>\nВ какой-то момент в голове мелькнула мысль, что виной всему, скорее всего, настройки syslogd. Но файл конфигурации я до этого просматривал, криминала никакого не заметил. Впрочем, моих познаний в linux могло и не хватить. Поэтому решил снести syslogd, почистить конфиги и запустить его заново. Для этого хватило одного команды:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">apt-get install --purge --reinstall syslogd syslog-common<\/code><\/pre><p>Проверяем статус службы, перезапускаем на всякий случай еще раз, идем смотреть логи почты — они более важны, чем другие. Файл all изменил свой размер, перестал быть «нулевым». Пробуем отправить самому себе письмо, запустив перед этим команду<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">tail -f \/var\/log\/mail\/all<\/code><\/pre><p>И, о счастье, весь ход работы почты отображается, как и следует. Смотрим остальные логи — вроде все пишется. Пока что понаблюдаю еще, возможно, что некоторые все-таки будут «сопротивляться», хотя и маловероятно.<\/p>\n",
            "date_published": "2017-09-26T18:31:33+07:00",
            "date_modified": "2017-09-26T18:31:28+07:00",
            "tags": [
                "journalctl",
                "linux",
                "syslogd",
                "журнал",
                "не пишет",
                "пустой",
                "файл"
            ],
            "_date_published_rfc2822": "Tue, 26 Sep 2017 18:31:33 +0700",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "92",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4134,
    "_e2_ua_string": "Aegea 11.3 (v4134)"
}