Recientemente compré un SSD para mi computadora portátil e instalé Debian Jessie nuevo en él (antes usé Wheezy). Como resultado, la mayoría de las operaciones en el portátil se han acelerado, y una operación en particular lo ha hecho incluso de forma drástica. De hecho, ahora tarda aproximadamente 1 segundo en sudo shutdown nowcompletarse. Incluso en sistemas en tiempo real como QNX, un apagado de 1 segundo se considera apresurado, especialmente si alguna interfaz de red ha estado activa, por lo que no creo que esto pueda ser normal. El problema es que no puedo encontrar ningún mensaje de error relevante en ninguna parte. El último segundo syslogno muestra nada especial (me tomé la libertad de eliminar openobexmensajes que creo que no son 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.
reviséeste systemderrorque parece no tener relación tras la inspección. El error se corrigió en mi versión systemd 215-17+deb8u2y rsyslogse informa que sale el SIGTERM, no el SIGKILL.
¿Alguien más ha encontrado este problema? Me doy cuenta de que a muchos usuarios les parece más una característica interesante, por lo que no la buscarán en Google ni la informarán en ningún lado hasta que pierdan datos. ¿Alguna sugerencia sobre cómo diagnosticarlo o dónde buscar más información?
EDITAR:
Desde que lo instalé sshd, aproveché para investigar su comportamiento. De hecho, cuando inicio y detengo el servicio manualmente (por ejemplo service ssh stop), aparecen mensajes apropiados en /var/log/auth. También hay un retraso notable cuando se inicia o se detiene el servicio. Pero cuando yo shutdowno systemctl isolate runlevel1.target, no sshdaparece ningún mensaje sobre cómo bajar.
El servicio se configura con parámetros de configuración predeterminados y se gestiona a través 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
Mi shutdown.targetes:
[Unit]
Description=Shutdown
Documentation=man:systemd.special(7)
DefaultDependencies=no
RefuseManualStart=yes
Agregar un enlace simbólico /etc/rc1.d/K00sshhace que sshdse detenga correctamente cuando el sistema pasa al nivel de ejecución 1, pero esa no es una solución real: se supone que no debo crear dichos enlaces simbólicos manualmente en un sistema recién instalado, y dichos enlaces simbólicos están obsoletos de todos modos en favor de .servicelos archivos.
Respuesta1
Como solución rápida y sucia, cambié a System V(que creó enlaces simbólicos apropiados en /etc/rcX.d/) y luego volví a SystemD:
sudo apt-get install sysvinit
sudo apt-get remove systemd
reboot
sudo apt-get install systemd systemd-ui
sudo apt-get remove sysvinit