Eu comprei recentemente um SSD para o meu laptop e instalei o novo Debian Jessie nele (eu usei o Wheezy antes). Como resultado, a maioria das operações no laptop se acelerou, e uma operação em particular, até mesmo drasticamente. Na verdade, agora leva cerca de 1 segundo para que um sudo shutdown now seja concluído. Mesmo em sistemas em tempo real como o QNX, um desligamento de 1 segundo é considerado apressado, especialmente se qualquer interface de rede estiver ativa, então não acho que isso seja normal. O problema é que não consigo encontrar mensagens de erro relevantes em nenhum lugar. O último segundo de syslog não mostra nada especial (tomei a liberdade de remover openobex mensagens que acredito não serem importantes):
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.
Eu verifiquei este bug systemd que parece não estar relacionado com a inspeção. O bug foi corrigido na minha versão systemd 215-17+deb8u2 e rsyslog reporta a saída em SIGTERM , não em SIGKILL .
Alguém mais encontrou esse problema? Eu percebo que parece mais um bom recurso para muitos usuários, então eles não vão google por ele ou denunciá-lo em qualquer lugar até que eles perdem dados. Alguma sugestão sobre como diagnosticar ou onde procurar mais informações?
Como tenho sshd instalado, aproveitei a oportunidade para investigar seu comportamento. De fato, quando eu inicio e paro o serviço manualmente (por exemplo, service ssh stop ), mensagens apropriadas aparecem em /var/log/auth . Há também um atraso perceptível quando o serviço é iniciado ou interrompido. Mas quando eu shutdown ou systemctl isolate runlevel1.target , nenhuma mensagem sobre sshd descendo aparece.
O serviço é configurado com parâmetros de configuração padrão e é gerenciado por meio de /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
Meu shutdown.target é:
[Unit]
Description=Shutdown
Documentation=man:systemd.special(7)
DefaultDependencies=no
RefuseManualStart=yes
Adicionar um link simbólico /etc/rc1.d/K00ssh faz sshd parar corretamente quando o sistema for para o nível de execução 1, mas isso não é uma solução real: não devo criar tais links simbólicos manualmente em um sistema recém-instalado, e esses links simbólicos depreciado de qualquer maneira em favor dos arquivos .service .
Como solução rápida e suja, mudei para System V (que criou links simbólicos apropriados em /etc/rcX.d/ ) e depois voltei para SystemD :
sudo apt-get install sysvinit
sudo apt-get remove systemd
reboot
sudo apt-get install systemd systemd-ui
sudo apt-get remove sysvinit