Интересную фишку подкинул Ubuntu Server после обновления до 20.04 LTS. Сервера через некоторый промежуток времени переставал быть доступным по сети и отвечать на пинги. Чтобы его "разбудить", нужно было нажатие (короткое) на кнопку включения сервера (у меня старичок HP Microserver G7).
Выяснилось, что в ОС добавился демон по "убаюкиванию" сервера. Сервера, Карл! Как проверить? Заглянуть в журнал событий system:
microserver:~$ sudo less /var/log/syslog |grep sleep
Jan 3 00:31:25 microserver NetworkManager[717]: <info> [1609623085.5485] manager: sleep: sleep requested (sleeping: no enabled: yes)
Jan 3 00:31:25 microserver systemd-sleep[2329]: Suspending system...
Jan 3 11:08:38 microserver systemd-sleep[2329]: System resumed.
Jan 3 11:08:43 microserver systemd-sleep[2519]: /dev/sdc:
Jan 3 11:08:43 microserver systemd-sleep[2519]: setting Advanced Power Management level to 0xfe (254)
Jan 3 11:08:43 microserver systemd-sleep[2519]: APM_level#011= off
Jan 3 11:08:44 microserver systemd-sleep[2826]: /dev/sdd:
Jan 3 11:08:44 microserver systemd-sleep[2826]: setting Advanced Power Management level to 0xfe (254)
Jan 3 11:08:44 microserver systemd-sleep[2826]: APM_level#011= off
Jan 3 11:08:44 microserver NetworkManager[717]: <info> [1609661324.3631] manager: sleep: wake requested (sleeping: yes enabled: yes)
Jan 3 11:28:44 microserver NetworkManager[717]: <info> [1609662524.4045] manager: sleep: sleep requested (sleeping: no enabled: yes)
Jan 3 11:28:44 microserver systemd-sleep[3413]: Suspending system...
Jan 3 16:32:03 microserver systemd-sleep[3413]: System resumed.
Jan 3 16:32:08 microserver systemd-sleep[3587]: /dev/sdc:
Jan 3 16:32:08 microserver systemd-sleep[3587]: setting Advanced Power Management level to 0xfe (254)
Jan 3 16:32:08 microserver systemd-sleep[3587]: APM_level#011= off
Jan 3 16:32:08 microserver systemd-sleep[3831]: /dev/sdd:
Jan 3 16:32:08 microserver systemd-sleep[3831]: setting Advanced Power Management level to 0xfe (254)
Jan 3 16:32:08 microserver systemd-sleep[3831]: APM_level#011= off
Jan 3 16:32:09 microserver NetworkManager[717]: <info> [1609680729.1749] manager: sleep: wake requested (sleeping: yes enabled: yes)
Я вполне допускаю, что если ставить сервер с нуля, то эта функция не активируется, либо вам дают возможность настройки во время установки. Но я-то свой сервер обновляю не помню уже с какой версии (минимум с 14.04).
Ответ найден тут.
Делаем еще одну проверку:
microserver:~$ systemctl status sleep.target
● sleep.target - Sleep
Loaded: loaded (/lib/systemd/system/sleep.target; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd.special(7)
Отключаем:
microserver:~$ sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
Created symlink /etc/systemd/system/sleep.target → /dev/null.
Created symlink /etc/systemd/system/suspend.target → /dev/null.
Created symlink /etc/systemd/system/hibernate.target → /dev/null.
Created symlink /etc/systemd/system/hybrid-sleep.target → /dev/null.
Проверяем:
microserver:~$ systemctl status sleep.target
● sleep.target
Loaded: masked (Reason: Unit sleep.target is masked.)
Active: inactive (dead)
Всё.
Как включить обратно (ну мало ли):
microserver:~$ sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
Removed /etc/systemd/system/sleep.target.
Removed /etc/systemd/system/suspend.target.
Removed /etc/systemd/system/hibernate.target.
Removed /etc/systemd/system/hybrid-sleep.target.
microserver:~$ systemctl status sleep.target
● sleep.target - Sleep
Loaded: loaded (/lib/systemd/system/sleep.target; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd.special(7)
10 комментариев:
Спасибо, добрый человек. Взял сервер на селектеле и с такой же штукой столкнулся.
Рад, что помогло :)
Огромное спасибо!
Ставил сервер с нуля. Утром прихожу - недоступен. Расстроился. Думал с железом что то, а оно вон оно что оказалось. Хотелось бы посмотреть в глаза тому человеку, который додумался усыплять сервер...
Согласен :)
Спасибо добрый человек. Думал с кабелем проблема или с сетевой картой. Порт на роутере кладешь/поднимаешь сервер возвращается, а расположение на другом конце города. А тут вон оно что))
Рад, что помогло :)
Мил человек. а подскажи с чем может быть связана интересная проблема. Есть виртулака на базе гипер-в. в нутри убунту 18 LTS. после обновления до 20.04 lts машина переодически (минут через 15 после запуска) начинает отказывать в подключении. причем не важно чем (ssh, http).
Добрый день.
С таким не сталкивался. Но если это не "сон", как в моей статье, то я бы проверил, не включен ли сетевой экран, для проверки отключить его, если он активен.
sudo systemctl status ufw.service
sudo systemctl stop ufw.service
Также проверить сетевые настройки (шлюз, DNS). Не может ли быть такого, что у кого-то в сети такой же IP?
Или, например, не отсылаются ли BPDU от STP-протокола. Но проблема может быть не только в самом сервере, а в настройке коммутатора.
Еще маловероятный но вариант - что у вас используется xinitd. И после обновления с ним что-то не так.
ха.... похоже что все таки UFW... а давно его в базовую поставку включили? в 18й не припомнил такой фичи...
Не знаю. Я просто предположил, что проблема может быть вызвана межсетевым экраном. А дальше нашел поиском, что стоит в 20.04.
Отправить комментарий