Зависает NetworkManager при выключении.

тему на лоре поднимали тыщу раз. Он не зависает, а линух в первую очередь серверная система и прилежно ждет когда завершатся процессы и закроются соединения. Таймаут составляет по дефолту 90 сек. Чтобы убить скорее по таймауту смотри конфиг. Поиск по лору в помощь

90 секунд это в systemd. У меня OpenRC, это во-первых. А во-вторых, инит сейчас вообще не обсуждается, зависает NM, собственно вопрос в том, как его починить, а не про таймаут. Если мне надо срочно выключить - я могу это сделать кнопкой.

тогда вопрос на засыпку какой таймаут у твоей openrc? Или хочешь сказать ситема вообще не имеет таймаутов? Тупо ждет когда же все процессы помрут от старости ) Вот это я понимаю респект ))

Я не разбирался, но таймауты скорее всего есть. А вопрос не про то, как «закрыть NM», а про то, как сделать так, чтобы он завершался сам по-нормальномк.

читай выше про серверную систему и уменьшай таймауты. Это задача системы а не nm

Сетевые ресурсы монтируешь?

Нет

А логи что говорят?

А где их искать?

cat /var/log/messages | grep NetworkManager

А если просто службу NM останавливать, тоже добровольно не останавливается?

NetworkManager

Выкинь гадость. Для работы сети никаких демонов не нужно, сеть поддерживается ядром.

И как ты предлагаешь подключаться к wi-fi без демонов? Даже интересно. Плюс мне требуется несколько более сложный функционал, чем просто подключение к сети, а именно NAP по bluetooth. NetworkManager отлично выполняет свои задачи.

Тут ничего нет. Кстати, я понаблюдал, NM зависает не всегда, а только при стечении неблагоприятных обстоятельств(например если было срабатывание OOM киллера).

похоже народ из школы домой возвращается 🤡

Не знаю как в gentoo а в debian ifup/ifdown прекрасно поднимали wifi-линки если надо.

а именно NAP по bluetooth

Ну ладно, не знаю что это такое.

Еще возможен вариант, что сервисы не в том порядке останавливаются.

Например, системный логгер останавливается раньше, чем NM. Ну это так, предположение чисто в порядке генерации идей. Может не логгер, а что-то другое.

В общем, для диагностики нужно либо выцепить информативное сообщение об ошибке, либо найти точную последовательность действий, приводящую к багу. Чтобы можно было достоверно в ситуацию бага попадать и ставить опыты.

Так-то пальцем в небо можно долго гадать.

Логов нет? или записей в логе о NetworkManager?

NAP - Network Access Point, по сути роутер. И мне нужно поднимать такое соединение по bluetooth. NM позволяет это сделать без затруднений. А nmtui позволяет без пердолинга в консольном режиме подключаться к wi-fi в пару кликов.

об этой проблеме есть куча тредов не только на лоре. Очень часто процессы закрываются по таймауту, особенно сетевые соединения. Это ни для кого не секрет.

Если не хочется уменьшать таймауты можно ломится и перед закрытыем самому вручную размонтировать сетевые шары и позакрывать что закрывается. То что и так убьется по таймауту 🤡

зы wandrien недоволен я мешаю ему изобрести костыль )))) 🤡🤡🤡

В логе ничего интересного. От слова совсем. Просто набор цифр.

Странно. Демон логирования какой то установлен?

Вполне возможно, что и нет.

emerge syslog-ng && rc-update add syslog-ng default && rc-service syslog-ng start

Сделал новые наблюдения. Если перед выключением закрыть Firefox, то все спокойно выключается. Дело походу в незакрытых сетевых сокетах.

короче то о чем я писал еще вчера )

Таймаутов нет, это понятно

ps правил сейчас конфиги и просто обратил внимание, что федора в настоящих релизах укоротила сама время таймаута с 90 сек до 45. Видимо народ жаловался достаточно сильно

#DefaultTimeoutStopSec=45s

Таймаутов нет, это понятно

А ну-ка покажи, какие у меня тут таймауты, если у меня система по команде systemctl poweroff выключается мгновенно.

# systemctl show NetworkManager | grep -i timeout
TimeoutStartUSec=1min 30s
TimeoutStopUSec=40s
TimeoutAbortUSec=40s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
TimeoutCleanUSec=infinity
JobTimeoutUSec=infinity
JobRunningTimeoutUSec=infinity
JobTimeoutAction=none

Клоуна в реакцию я тебе потом поставлю, после развлечения в толксах у меня рейт лимит на реакции сработал.

причем тут твое умвр?? Это аргумент школоты. Люди поднимают эту тему постоянно на форумах, реддитах и прочих сайтах, значит у других не работает. А совет всегда был один уменьшать таймауты

Иди им доказывай что у тебя все работает значит они лохи )) 🤡

причем тут твое умвр??

При том, что тайм-аут в супервизоре служб - это предохранитель на случай зависшего сервиса, а не опция для штатной работы ПО.

В корректно настроенной системе NM, как и любая служба, должен корректно отрабатывать своё завершение, а не убиваться супервизором по kill -KILL.

У ТСа баг, который надо локализовать и прижучить, а не лечить его подорожниками.

школоты

Ну ты с такими советами именно такое впечатление производишь, да.

зы ты вообще куда смотришь? Я имел ввиду

/etc/systemd/system.conf

🤡🤡🤡

зы ты вообще куда смотришь? Я имел ввиду /etc/systemd/system.conf

RTFM, неуч.

Ровно тот случай, когда чел не понимает, что он тупой, потому что он тупой.

В корректно настроенной системе NM, как и любая служба, должен корректно отрабатывать своё завершение, а не убиваться супервизором по kill -KILL.

)) понятное дело должна корректно отрабатывать свое завершение, поэтому когда выключаешь систему с открытыми сетевыми соединениям она ждет ТАЙМАУТА 🤡

жду когда уч допрет причем тут вообще NM и его таймауты)

/etc/systemd/system.conf

NM и его таймауты

Понятно. Эффект Даннинга — Крюгера в действии.

все что мог сказать по делу? )))

Я имел ввиду /etc/systemd/system.conf

Я те ща магию покажу. Хочешь? Смотри:

[root@aquila ~]# systemctl show NetworkManager | grep TimeoutStopUSec
TimeoutStopUSec=40s
[root@aquila ~]# sed -i -e 's/^DefaultTimeoutStopSec=40s/DefaultTimeoutStopSec=50s/' /etc/systemd/system.conf
[root@aquila ~]# systemctl daemon-reload 
[root@aquila ~]# systemctl show NetworkManager | grep TimeoutStopUSec
TimeoutStopUSec=50s
[root@aquila ~]# 

https://www.youtube.com/watch?v=UzPx4Qme5hs

и шо это должно доказать?

Человек прилепил видосик к своему комменту для увеличения его типа достоверности и при этом кидается эффектами Даннинга — Крюгера. Да еще sed приплел как будто други не в состоянии сами посмотреть ). ОМГ он волшебник ) Яснопонятно.

На этом все 🤡

Ага: https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer

Да еще sed приплел

Ололошечка. Ты еще скажи, что я тебя этим унизил и оскорбил. Юзеры при виде sed-а пугаются. sed, чтобы переменную в конфиге поменять, это неинклюзивно. Неполиткорректно. Унижает альтернативно умных.

и шо это должно доказать?

Тебе - ничего. Не по Сеньке.

Вообще, NM и systemd странно взаимодействуют, хотя казалось бы.

NM, например, может сообщить SD о том, что сеть поднята, ещё до того, как сеть будет поднята — сразу после инициализации сетевой карты, но до получения настроек по DHCP. Вот и тут — NM не хочет выходить, пока есть соединения в состоянии CLOSE_WAIT, хотя казалось бы.

NM, например, может сообщить SD о том, что сеть поднята, ещё до того, как сеть будет поднята — сразу после инициализации сетевой карты, но до получения настроек по DHCP.

Так-то звучит как баг. А в багтрекере где-то есть это?

Кстати, если смотреть по стартовым логам OpenRC - то OpenRC NM при запуске помечает как остановленный, а пометку снимает тогда, когда появляется сеть.

у меня 1 минуту 30 секунд ждет!

/etc/systemd/system.conf has a line

#DefaultTimeoutStopSec=90s

UPD: Увидел, что там OpenRC… Ну тут как г-тся: «наши полномочия - всё!»

значит у меня версия системды новее твоей. Я на последней федоре, так что.. У арчеводов скорее всего вообще чуть ли не девел версия

да то рофл 90 секунд и есть 1 минута и 30 секунд

После обновления баг исчез.

Обычно процессы с openrc просто завершаются корректно.

Как ты выяснил, что проблема с NM? На основе логов или системных сообщений?

Надпись в консоли Stopping NetworkManager, я не знаю, как её можно интерпретировать иначе.