У меня свежая установка debian 8.3 jessie на новом сервере со всеми обновлениями
Однако каждый раз, когда я пытаюсь перезагрузить машину, debian входит в аварийный режим.
Экран застревал на "Начальное задание для LSB: поднять сетевые интерфейсы"
С оригиналом / и т.д. / сеть / интерфейсы (содержащий 1 IPv4 и IPv6) загрузка занимает 2 мин 30, 99% из-за network.service (проверено с помощью systemd-analysis виноват), все остальное занимает менее 200 мс
Однако настоящая / и т.д. / сеть / интерфейсы имеет более 100 IP-адресов, и с этим файлом конфигурации сервер вообще не может загрузиться, даже после нескольких часов работы в сети.
Я также должен упомянуть, что когда я загружаюсь в минимальном / etc / network / interfaces и заменяю файл на правильный и перезапускаю сеть, все в порядке (занимает 20 минут, но, по крайней мере, он работает)
Я понятия не имею, что происходит, вот что journalctl -b -u network.service возвращает:
Feb 15 00:09:38 systemd[1]: Starting LSB: Raise network interfaces....
Feb 15 00:09:48 networking[691]: Configuring network interfaces...RTNETLINK answers: File exists
Feb 15 00:09:48 networking[691]: RTNETLINK answers: File exists
Feb 15 00:09:50 networking[691]: Waiting for DAD... Done
Feb 15 00:09:50 networking[691]: RTNETLINK answers: File exists
Feb 15 00:09:50 networking[691]: Failed to bring up eth0.
Feb 15 00:09:55 networking[691]: RTNETLINK answers: File exists
Feb 15 00:09:55 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:00 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:00 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:06 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:06 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:09 ntpdate[1009]: 37.187.98.51 rate limit response from server.
Feb 15 00:10:11 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:11 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:16 ntpdate[1059]: 130.236.254.17 rate limit response from server.
Feb 15 00:10:16 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:16 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:18 ntpdate[1009]: step time server 213.251.128.249 offset -0.100865 sec
Feb 15 00:10:21 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:21 networking[691]: RTNETLINK answers: File exists
Feb 15 00:10:23 ntpdate[1059]: step time server 213.251.128.249 offset -0.100906 sec
Feb 15 00:10:26 ntpdate[1155]: 130.236.254.17 rate limit response from server.
Любая помощь будет очень оценена
С уважением
Этот отчет об ошибке: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218 кажется довольно актуальным. Пользователь описывает аналогичную проблему, когда его система зависает с сообщением «Выполняется задание для LSB: поднять сетевые интерфейсы».
Они используют следующие шаги, чтобы определить причину проблемы:
systemctl enable debug-shell.service
/etc/network/if-up.d/local-firewall
Этот пользователь использовал shorewall, но несколько других пользователей сообщают об аналогичных проблемах с другими брандмауэрами позже в этом потоке. Если в сеансе отладки выясняется, что проблема связана с инициализацией брандмауэра, эти шаги могут решить проблему:
killall local-firewall
После загрузки ОС пользователь редактировал скрипт /etc/network/if-up.d/local-firewall из:
#!/bin/sh
FIREWALL=shorewall
FIREWALL6=shorewall6
service $FIREWALL restart
service $FIREWALL6 restart
кому:
#!/bin/sh
if [ -d /run/systemd/system ]; then
systemctl list-jobs | grep -q network.target && exit 0
fi
service shorewall restart
service shorewall6 restart
Эта модификация решает проблему, поскольку условие «if» позволяет инициализации брандмауэра ждать, пока сетевой адаптер не будет полностью инициализирован, что позволяет заполнить несколько переменных среды, от которых зависит брандмауэр.
Если вы не используете локальный брандмауэр, есть еще один аналогичный отчет об ошибке, но проблема вызвана монтированием NFS во время загрузки. Если это ближе к вашей среде, это может оказаться интересным: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746358