Recentemente, comprei um SSD para meu laptop e instalei o Debian Jessie novo nele (usei o Wheezy antes). Como resultado, a maioria das operações no laptop foram aceleradas, e uma operação em particular foi drasticamente acelerada. Na verdade, agora leva cerca de 1 segundo para ser sudo shutdown nowconcluído. Mesmo em sistemas em tempo real como o QNX, um desligamento de 1 segundo é considerado precipitado, especialmente se alguma interface de rede estiver ativa, então não acho que isso possa ser normal. O problema é que não consigo encontrar nenhuma mensagem de erro relevante em lugar nenhum. O último segundo syslognão mostra nada de especial (tomei a liberdade de retirar openobexmensagens que considero não 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 verifiqueiesse systemdbugque parece não relacionado após a inspeção. O bug foi corrigido em meu release systemd 215-17+deb8u2e rsyslogrelata para sair em SIGTERM, não em SIGKILL.
Alguém mais encontrou esse problema? Sei que parece mais um recurso interessante para muitos usuários, então eles não vão procurar no Google ou reportá-lo em lugar nenhum até perderem dados. Alguma sugestão sobre como diagnosticar ou onde procurar mais informações?
EDITAR:
Desde que instalei sshd, aproveitei para investigar seu comportamento. Na verdade, quando inicio e paro o serviço manualmente (por exemplo service ssh stop), mensagens apropriadas aparecem em /var/log/auth. Também há um atraso perceptível quando o serviço é iniciado ou interrompido. 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 via /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/K00sshinterrompe sshdcorretamente quando o sistema vai para o nível de execução 1, mas isso não é uma solução real: não devo criar esses links simbólicos manualmente em um sistema recém-instalado, e esses links simbólicos estão obsoletos de qualquer maneira em favor dos .servicearquivos.
Responder1
Como uma 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