1

Недавно я купил SSD для моего ноутбука и установил на него свежую Debian Jessie (я раньше пользовался Wheezy). В результате большинство операций на ноутбуке ускорились, а одна операция, в частности, даже резко. Фактически, теперь для sudo shutdown now требуется около 1 секунды. Даже в системах реального времени, таких как QNX, остановка на 1 секунду считается поспешной, особенно если какие-либо сетевые интерфейсы были включены, поэтому я не думаю, что это может быть нормально. Проблема в том, что я нигде не могу найти никаких соответствующих сообщений об ошибках. Последняя секунда syslog показывает ничего особенного (я позволил себе удалить сообщения openobex которые, я считаю, не важны):

Oct 12 23:58:21 hostname kernel: [17080.034445] wlan0: deauthenticating from XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING)
Oct 12 23:58:21 hostname kernel: [17080.050734] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: disassociated
Oct 12 23:58:21 hostname kernel: [17080.050754] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
Oct 12 23:58:21 hostname kernel: [17080.050763] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement)
Oct 12 23:58:21 hostname kernel: [17080.052458] cfg80211: Calling CRDA to update world regulatory domain
Oct 12 23:58:21 hostname kernel: [17080.098666] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Oct 12 23:58:21 hostname rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="574" x-info="http://www.rsyslog.com"] exiting on signal 15.

Я проверил эту ошибку systemd которая кажется не связанной при проверке. Ошибка исправлена в моем выпуске systemd 215-17+deb8u2 , и rsyslog сообщает о выходе на SIGTERM , а не на SIGKILL .

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

РЕДАКТИРОВАТЬ:

Поскольку я установил sshd , я воспользовался возможностью, чтобы исследовать его поведение. Действительно, когда я запускаю и останавливаю службу вручную (например, service ssh stop), соответствующие сообщения появляются в /var/log/auth . Также есть заметная задержка, когда служба запускается или останавливается. Но когда я shutdown или systemctl isolate runlevel1.target не появляется сообщение о sshd идет вниз.

Служба настроена с параметрами конфигурации по умолчанию и управляется через /etc/systemd/system/sshd.service:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Мой shutdown.target это:

[Unit]
Description=Shutdown
Documentation=man:systemd.special(7)
DefaultDependencies=no
RefuseManualStart=yes

Добавление символической ссылки /etc/rc1.d/K00ssh заставляет sshd корректно останавливаться, когда система переходит на уровень выполнения 1, но это ненастоящее решение: я не должен создавать такие символические ссылки вручную в недавно установленной системе, и такие символические ссылки в любом случае не рекомендуется использовать файлы .service .

1 ответ1

0

В качестве быстрого и грязного решения я переключился на System V (которая создала соответствующие символические ссылки в /etc/rcX.d/), а затем снова на SystemD:

sudo apt-get install sysvinit
sudo apt-get remove systemd
reboot
sudo apt-get install systemd systemd-ui
sudo apt-get remove sysvinit

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .