Недавно я купил SSD для своего ноутбука и установил на него свежий Debian Jessie (раньше я использовал Wheezy). В результате большинство операций на ноутбуке ускорились, а одна операция, в частности, даже радикально. Фактически, теперь для завершения требуется около 1 секунды sudo shutdown now. Даже в системах реального времени, таких как 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.
Кто-нибудь еще сталкивался с этой проблемой? Я понимаю, что для многих пользователей это выглядит скорее как приятная функция, поэтому они не будут искать ее в Google или сообщать о ней где-либо, пока не потеряют данные. Есть какие-нибудь предложения по диагностике или где искать больше информации?
РЕДАКТИРОВАТЬ:
После установки 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
В качестве быстрого и грубого решения я переключился на 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