Recentemente, comprei um SSD para o meu laptop e instalei o Debian Jessie novo (usei o Wheezy antes). Como resultado, a maioria das operações no laptop acelerou, e uma operação em particular, mesmo que drasticamente. Na verdade, agora leva cerca de 1 segundo para que um sudo shutdown nowseja concluído. Mesmo em sistemas em tempo real como o QNX, um desligamento de 1 segundo é considerado apressado, especialmente se alguma interface de rede estiver ativa, por isso não acho que isso possa ser normal. O problema é que não consigo encontrar nenhuma mensagem de erro relevante em nenhum lugar. O último segundo dos syslogprogramas não mostra nada de especial (tomei a liberdade de remover openobexmensagens 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.
Fiz o check-out deste systemdbug, que parece não ter relação com a inspeção. O bug foi corrigido na minha versão systemd 215-17+deb8u2e rsyslogreporta para sair SIGTERM, não para SIGKILL.
Alguém mais encontrou esse problema? Sei que parece mais um recurso interessante para muitos usuários, para que eles não pesquisem no Google nem o denunciem em lugar nenhum até perderem dados. Alguma sugestão sobre como diagnosticá-lo ou onde procurar mais informações?
EDITAR:
Desde que sshdinstalei, aproveitei a oportunidade para investigar seu comportamento. De fato, quando inicio e paro o serviço manualmente (por exemplo service ssh stop), as mensagens apropriadas aparecem em /var/log/auth. Também há um atraso perceptível quando o serviço é iniciado ou parado. Mas quando eu shutdownou systemctl isolate runlevel1.target, nenhuma mensagem sobre sshda queda aparece.
O serviço é configurado com parâmetros de configuração padrão e é gerenciado por /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
Adicionando um link simbólico /etc/rc1.d/K00sshfaz sshdparar corretamente quando o sistema entra no nível de execução 1, mas isso não é uma solução real: Eu não deveria criar tais links simbólicos manualmente em um sistema recém-instalado, e esses links simbólicos são preteridos qualquer maneira em favor de .servicearquivos.
shutdowndestino com nome semelhante que você possa editar. Bem perto do final, basta adicionar algo como sleep 600(600s = 10 minutos); isso deve lhe dar tempo para revisar qualquer saída na tela em busca de anomalias.
/etc/init.dscripts são executados, mas não systemdé assim que deve funcionar (e eu não tenho os links simbólicos necessários para todos os meus serviços). O problema é que os *.servicearquivos parecem ser levados em consideração na inicialização, mas não no desligamento.
etc/init.dcom o objetivo de ver se tudo está bem executado quando você faz o desligamento. Talvezsleep 1malguns e algunsechoem algum registro ... Siga esta resposta para obter algumas dicas.