Назад в прошлое, или как системная дата влияет на загрузку операционной системы.
Исправления от 13 марта, 2009 13:22:37
Сегодня на работу поздно вечером пожаловал коллега сисадмин. Задача состояла в апгрейде сервера, который, кроме того, что является маршрутизатором еще исполняет достаточно много функций. Апгрейд заключался в том, чтобы добавить в него еще планочку оперативной памяти и одну сетевую карту, поскольку его функции должны в ближайшем будущем стать еще шире. Как ни прискорбно было говорить консольке shutdown -p now, это сделать пришлось. Машина пошла в шатдаун, а товарищ уже держал на готове планочку мозгов и сетевуху…
Установив значит все это добро в слоты, включил питание. Машинка вроде начала бутиться, да вот только что-то пошло не так… 
Посыпались на консоль матюки от named’а:
Mar 31 01:18:03 somehost named[959]: starting BIND 9.3.1 -u bind -t /var/named Mar 31 01:18:04 somehost named[959]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/ unix/../entropy.c:374: fatal error: Mar 31 01:18:04 somehost named[959]: RUNTIME_CHECK(isc_time_now((&t)) == 0) failed Mar 31 01:18:04 somehost kernel: pid 959 (named), uid 0: exited on signal 6 Mar 31 01:18:04 somehost named[959]: exiting (due to fatal error in library)
Named не запустился. По этой причине возникли проблемы у Apache, у почтовика и еще у пачки демонов. Кроме того, в логи сыпалось еще куча разного рода не совсем понятных ошибок. Задумались: “Какого фига?” Вариантов много было разных. Все перепробовали, но ни коллега, ни я не обратили внимания на странную дату в логах. Каждый уселся на свое место, уткнулся в консоль и ушел в свои мысли. И тут, после нескольких безуспешных попыток вернуть named к жизни, мне почему то приспичило посмотреть время. То ли потому что в голове крутились мысли “а причем здесь entropy.c:374: fatal error“, то ли потому что собирался написать отчет о текущей смене, что в такой-то промежуток времени были проблемы, и нужно было знать время, а в трей посмотреть обломился, но я увидел вот такое:
# date день_недели, 31 марта 1918 г. 01:13:56
Откуда еще в системе взялся 1918 год??? Ну, вот вобщем, потому и не захотели стартовать ни named, ни другие сервисы, которым видать не все-равно что творится в мире. 
Вобщем, в BIOS’е поставили правильную дату/время, загрузились, поехали. Остается только по-прежнему загадкой, откуда взялась такая дата, и почему именно 31 марта 1918, а не 01 января 1970? Порывшись немного в Интернете, я нашел интересный факт, о котором никогда не знал. Оказывается, 31 марта 1918 года, общепринятый День Геноцида против азербайджанского народа.
30 – 31 марта 1918 года остались в памяти азербайджанского народа благодаря неслыханному террору, истреблению мирного населения города Баку и других районов Азербайджана. В 1918 году власть в Баку была захвачена большевиками. С благословения руководителей Бакинской комунны вооруженные дашнакские отряды, бесчинствуя в тюркских кварталах города, убили 12 тысяч горожан, которые были затем были похоронены в Нагорном парке Баку.
Вот такие пироги (более подробно о геноциде можно ). Коллега пошел домой, я на работе на смене, а в голове крутится мысль, что все это неспроста… Звякнул ему по телефону. Оба подумали об одном и том же: вредоносный код?.. Ну просто больше ничего на ум не приходит. Будем искать.
P.S.: Вот еще что нашел в логах:
Oct 21 22:58:36 hostname pop3_server: Time just moved backwards by 20 seconds. This might cause a lot of problems, so I'll just kill myself now.
После окончательной загрузки системы, когда уже время было настроено и осуществлен контрольный ребут, с целью проверить, все ли запустилось, увидели, что упал почтовик. Ну, а в лог накатал: “Че-то у Вас разница во времени на аж 20 секунд. И поскольку, это может создать много проблем, я щас просто себя убью”. Ну, и убивает 
На самом деле, запустился ntpd, обновил время, убрав разницу в 20 секунд. А в это время демон POP3 сервера, видимо, немного удивился, от столь “большого” расхождения во времени и пожелал всем всего хорошего. Правда, после следущего запуска больше, не падал, и в логи не ругался.
Резюме: Не знаю точно, в неверной “дате/время” была ли на самом деле проблема. Посмотрим как оно дальше будет себя вести. И не стоит забывать, что иметь в своей системе точное время - залог стабильной работы.
Похожие публикации
Теги: dovecot, error, FreeBSD, pop3/imap сервер, лог, ошибка в логах, проблема с dovecot, системная дата
ЛЕНТУ ЭТОГО БЛОГА В ЛЮБИМУЮ 
Loading ...