Ich habe vor kurzem eine SSD für meinen Laptop gekauft und darauf ein neues Debian Jessie installiert (vorher hatte ich Wheezy verwendet). Dadurch sind die meisten Vorgänge auf dem Laptop schneller geworden, und ein Vorgang sogar drastisch. Tatsächlich dauert es jetzt etwa 1 Sekunde, bis ein Vorgang sudo shutdown nowabgeschlossen ist. Selbst in Echtzeitsystemen wie QNX wird ein Herunterfahren innerhalb einer Sekunde als übereilt angesehen, insbesondere wenn Netzwerkschnittstellen aktiv waren, daher glaube ich nicht, dass das normal sein kann. Das Problem ist, dass ich nirgends relevante Fehlermeldungen finden kann. Die letzte Sekunde syslogzeigt nichts Besonderes (ich habe mir erlaubt, openobexMeldungen zu entfernen, die meiner Meinung nach nicht wichtig sind):
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.
Ich habe ausgechecktdieser systemdFehlerwas bei näherer Betrachtung nichts damit zu tun zu haben scheint. Der Fehler ist in meiner Version behoben systemd 215-17+deb8u2und rsyslogwird am beendet SIGTERM, nicht am SIGKILL.
Ist dieses Problem sonst noch jemandem begegnet? Mir ist klar, dass es für viele Benutzer eher wie eine nette Funktion aussieht, sodass sie nicht danach googeln oder es irgendwo melden, bis sie Daten verlieren. Irgendwelche Vorschläge, wie man das Problem diagnostizieren oder wo man nach weiteren Informationen suchen kann?
BEARBEITEN:
Seit ich den sshdDienst installiert habe, habe ich die Gelegenheit genutzt, sein Verhalten zu untersuchen. Tatsächlich service ssh stoperscheinen beim manuellen Starten und Stoppen des Dienstes (z. B. ) entsprechende Meldungen in /var/log/auth. Es gibt auch eine merkliche Verzögerung beim Starten oder Stoppen des Dienstes. Aber wenn ich shutdownoder drücke systemctl isolate runlevel1.target, erscheint keine Meldung über sshddas Herunterfahren.
Der Dienst ist mit Standardkonfigurationsparametern konfiguriert und wird verwaltet über /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
Mein shutdown.targetist:
[Unit]
Description=Shutdown
Documentation=man:systemd.special(7)
DefaultDependencies=no
RefuseManualStart=yes
Durch das Hinzufügen eines symbolischen Links /etc/rc1.d/K00sshwird sshddas System korrekt gestoppt, wenn es in den Runlevel 1 wechselt. Dies ist jedoch keine echte Lösung: Auf einem frisch installierten System soll ich solche symbolischen Links nicht manuell erstellen, und außerdem werden solche symbolischen Links ohnehin zugunsten von .serviceDateien verworfen.
Antwort1
Als schnelle und einfache Lösung bin ich zu System V(wodurch entsprechende symbolische Links in erstellt wurden /etc/rcX.d/) und dann zurück zu gewechselt SystemD:
sudo apt-get install sysvinit
sudo apt-get remove systemd
reboot
sudo apt-get install systemd systemd-ui
sudo apt-get remove sysvinit