SystemD не сумел выключить машину

1

2

Отвалился usb-hub с флешкой воткнутой, и не захотел реиницилизироваться.
Восьмое чувство подсказало, что не стоит удалённо перезагружать машину.

Внезапно, оказалось что я угадал, и systemd был не готов к серверному юзкейсу: https://i.imgur.com/xTBtiVJ.jpg

systemd зомбанул машину: потушил все сервисы, и не выключил.

Лог отключения до последней записи:

Feb 12 08:10:51 optiplex pulseaudio[12272]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
Feb 12 08:10:51 optiplex pulseaudio[12272]:       after 12 requests (12 known processed) with 0 events remaining.
Feb 12 08:10:51 optiplex org.kde.kded5[12192]: The X11 connection broke (error 1). Did the X11 server die?
Feb 12 08:10:51 optiplex NetworkManager[860]: ((src/settings/nm-settings-connection.c:361)): assertion '<dropped>' failed
Feb 12 08:10:51 optiplex org.kde.kglobalaccel[12192]: The X11 connection broke (error 1). Did the X11 server die?
Feb 12 08:10:51 optiplex org.kde.kwalletd5[12192]: The X11 connection broke (error 1). Did the X11 server die?
Feb 12 08:10:51 optiplex org.kde.kuiserver[12192]: The X11 connection broke (error 1). Did the X11 server die?
Feb 12 08:10:51 optiplex org.kde.kdeconnect[12192]: The X11 connection broke (error 1). Did the X11 server die?
Feb 12 08:10:51 optiplex org.kde.ActivityManager[12192]: The X11 connection broke (error 1). Did the X11 server die?
Feb 12 08:10:51 optiplex at-spi-bus-launcher[12342]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
Feb 12 08:10:51 optiplex at-spi-bus-launcher[12342]:       after 909045 requests (909045 known processed) with 0 events remaining.
Feb 12 08:10:51 optiplex bluetoothd[1406]: Endpoint unregistered: sender=:1.2167 path=/MediaEndpoint/A2DPSource
Feb 12 08:10:51 optiplex bluetoothd[1406]: Endpoint unregistered: sender=:1.2167 path=/MediaEndpoint/A2DPSink
Feb 12 08:10:51 optiplex systemd[12163]: pulseaudio.service: Main process exited, code=exited, status=1/FAILURE
Feb 12 08:10:51 optiplex systemd[12163]: pulseaudio.service: Failed with result 'exit-code'.
Feb 12 08:10:52 optiplex systemd[12163]: pulseaudio.service: Service RestartSec=100ms expired, scheduling restart.
Feb 12 08:10:52 optiplex systemd[12163]: pulseaudio.service: Scheduled restart job, restart counter is at 1.
Feb 12 08:10:52 optiplex systemd[12163]: Stopped Sound Service.
Feb 12 08:10:52 optiplex systemd[12163]: Failed to create compat systemd cgroup /user.slice/user-1000.slice/user@1000.service/pulseaudio.service: Permission denied
Feb 12 08:10:52 optiplex systemd[12163]: Failed to attach 26188 to compat systemd cgroup /user.slice/user-1000.slice/user@1000.service/pulseaudio.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[12163]: Starting Sound Service...
Feb 12 08:10:52 optiplex systemd[26188]: Failed to attach 26188 to compat systemd cgroup /user.slice/user-1000.slice/user@1000.service/pulseaudio.service: No such file or directory
Feb 12 08:10:52 optiplex pulseaudio[26188]: W: [pulseaudio] pid.c: Stale PID file, overwriting.
Feb 12 08:10:52 optiplex NetworkManager[860]: ((src/settings/nm-settings-connection.c:361)): assertion '<dropped>' failed
Feb 12 08:10:52 optiplex systemd[1]: Stopping Authorization Manager...
Feb 12 08:10:52 optiplex systemd[1]: systemd-rfkill.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Closed Load/Save RF Kill Switch Status /dev/rfkill Watch.
Feb 12 08:10:52 optiplex systemd[1]: Stopping Session 1 of user root.
Feb 12 08:10:52 optiplex watchdog[2532]: stopping daemon (5.15)
Feb 12 08:10:52 optiplex systemd[1]: Stopped target Sound Card.
Feb 12 08:10:52 optiplex tincd[31321]: Got TERM signal
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 19753 (pager) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 3311 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex Tor[1921]: Interrupt: exiting cleanly.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 9288 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 9659 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 11616 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 19985 (su) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 19995 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 20081 (tail) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21139 (tmux: server) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21140 (htop) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21142 (su) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21146 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21149 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21152 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 25210 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 28347 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 28734 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12243 (mpd) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 9763 (mysql) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 25182 (wcalc) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12218 (ssh-agent) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12554 (dbus-daemon) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12567 (dbus-daemon) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 13917 (thumbnail.so) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21144 (watch) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 28624 (watch) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 28858 (cgrulesengd) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 8433 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 26151 (tdeinit) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 24852 (gpg-agent) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 19969 (aptitude) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 30608 (emacs) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 30629 (aspell) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 7311 (jediepcserver) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 15546 (jediepcserver) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 18533 (jediepcserver) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 31963 (jediepcserver) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12706 (jediepcserver) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12707 (jediepcserver) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 19743 (man) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 4547 (adb) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 2136 (bash) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 14846 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 7324 (python2) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 15549 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 18538 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 30012 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 31972 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12680 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12681 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12685 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12712 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12714 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 21121 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 30138 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 30417 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 6190 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 2866 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 22505 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 312 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 25712 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 1896 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 10249 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 18597 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 28332 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 17411 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 8876 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 18673 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 3870 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 12170 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 20356 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 29165 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 5544 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: session-c2.scope: Killing process 19331 (python) with signal SIGTERM.
Feb 12 08:10:52 optiplex systemd[1]: Stopping Session c2 of user aidaho.
Feb 12 08:10:52 optiplex systemd[1]: Stopping Tinc net vaultnet...
Feb 12 08:10:52 optiplex systemd[1]: Stopping Save/Restore Sound Card State...
Feb 12 08:10:52 optiplex systemd[1]: Stopping Daemon for power management...
Feb 12 08:10:52 optiplex systemd[1]: Stopping Daemon for generating UUIDs...
Feb 12 08:10:52 optiplex systemd[1]: Stopping Anonymizing overlay network for TCP...
Feb 12 08:10:52 optiplex systemd[1]: Stopping watchdog daemon...
Feb 12 08:10:52 optiplex systemd[1]: Stopped target Graphical Interface.
Feb 12 08:10:52 optiplex systemd[1]: Stopping Disk Manager...
Feb 12 08:10:52 optiplex systemd[1]: Stopping Trinity Display Manager...
Feb 12 08:10:52 optiplex systemd[1]: Stopping RealtimeKit Scheduling Policy Service...
Feb 12 08:10:52 optiplex bluetoothd[1406]: Terminating
Feb 12 08:10:52 optiplex systemd[1]: Stopped target Bluetooth.
Feb 12 08:10:52 optiplex systemd[1]: Stopping Bluetooth service...
Feb 12 08:10:52 optiplex systemd[1]: Stopped target Timers.
Feb 12 08:10:52 optiplex systemd[1]: systemd-tmpfiles-clean.timer: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daily Cleanup of Temporary Directories.
Feb 12 08:10:52 optiplex systemd[1]: man-db.timer: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daily man-db regeneration.
Feb 12 08:10:52 optiplex systemd[1]: apt-daily-upgrade.timer: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daily apt upgrade and clean activities.
Feb 12 08:10:52 optiplex systemd[1]: anacron.timer: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Trigger anacron every hour.
Feb 12 08:10:52 optiplex systemd[1]: apt-daily.timer: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daily apt download activities.
Feb 12 08:10:52 optiplex systemd[1]: logrotate.timer: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daily rotation of log files.
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26195 to compat systemd cgroup /system.slice/system-zram\x2dsetup.slice/zram-setup@zram0.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping Setup zram based device zram0...
Feb 12 08:10:52 optiplex systemd[26195]: Failed to attach 26195 to compat systemd cgroup /system.slice/system-zram\x2dsetup.slice/zram-setup@zram0.service: No such file or directory
Feb 12 08:10:52 optiplex bluetoothd[1406]: Stopping SDP server
Feb 12 08:10:52 optiplex bluetoothd[1406]: Exit
Feb 12 08:10:52 optiplex sh[26195]: /bin/sh: 1: echo: echo: I/O error
Feb 12 08:10:52 optiplex systemd[1]: getty@tty1.service: Main process exited, code=killed, status=15/TERM
Feb 12 08:10:52 optiplex systemd[1]: getty@tty1.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Getty on tty1.
Feb 12 08:10:52 optiplex systemd[1]: uuidd.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daemon for generating UUIDs.
Feb 12 08:10:52 optiplex systemd[1]: zram-setup@zram0.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Setup zram based device zram0.
Feb 12 08:10:52 optiplex systemd[1]: session-1.scope: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Session 1 of user root.
Feb 12 08:10:52 optiplex systemd[1]: Stopping User Manager for UID 0...
Feb 12 08:10:52 optiplex systemd[1]: Removed slice system-zram\x2dsetup.slice.
Feb 12 08:10:52 optiplex systemd[1]: Removed slice system-getty.slice.
Feb 12 08:10:52 optiplex systemd[2884]: Stopped target Default.
Feb 12 08:10:52 optiplex systemd[2884]: Stopped target Basic System.
Feb 12 08:10:52 optiplex systemd[2884]: Stopped target Timers.
Feb 12 08:10:52 optiplex systemd[2884]: Stopped target Sockets.
Feb 12 08:10:52 optiplex systemd[2884]: gpg-agent-browser.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Feb 12 08:10:52 optiplex systemd[2884]: gpg-agent-extra.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Feb 12 08:10:52 optiplex systemd[2884]: gpg-agent.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Closed GnuPG cryptographic agent and passphrase cache.
Feb 12 08:10:52 optiplex systemd[2884]: gpg-agent-ssh.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Feb 12 08:10:52 optiplex systemd[2884]: Stopped target Paths.
Feb 12 08:10:52 optiplex systemd[2884]: dbus.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Closed D-Bus User Message Bus Socket.
Feb 12 08:10:52 optiplex systemd[2884]: dirmngr.socket: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Closed GnuPG network certificate management daemon.
Feb 12 08:10:52 optiplex systemd[2884]: Reached target Shutdown.
Feb 12 08:10:52 optiplex systemd[2884]: systemd-exit.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[2884]: Started Exit the Session.
Feb 12 08:10:52 optiplex systemd[2884]: Reached target Exit the Session.
Feb 12 08:10:52 optiplex NetworkManager[860]: <info>  [1581487852.5798] device (22:22:B4:71:1B:24): state change: disconnected -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Feb 12 08:10:52 optiplex systemd[1]: rtkit-daemon.service: Main process exited, code=killed, status=15/TERM
Feb 12 08:10:52 optiplex systemd[1]: rtkit-daemon.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped RealtimeKit Scheduling Policy Service.
Feb 12 08:10:52 optiplex systemd[1]: tor@default.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Anonymizing overlay network for TCP.
Feb 12 08:10:52 optiplex systemd[1]: upower.service: Main process exited, code=killed, status=15/TERM
Feb 12 08:10:52 optiplex systemd[1]: upower.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Daemon for power management.
Feb 12 08:10:52 optiplex systemd[1]: Removed slice system-tor.slice.
Feb 12 08:10:52 optiplex NetworkManager[860]: ((src/settings/nm-settings-connection.c:361)): assertion '<dropped>' failed
Feb 12 08:10:52 optiplex systemd[1]: polkit.service: Main process exited, code=killed, status=15/TERM
Feb 12 08:10:52 optiplex systemd[1]: polkit.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Authorization Manager.
Feb 12 08:10:52 optiplex udisksd[517]: udisks daemon version 2.8.1 exiting
Feb 12 08:10:52 optiplex systemd[1]: bluetooth.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Bluetooth service.
Feb 12 08:10:52 optiplex systemd[1]: tdm.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Trinity Display Manager.
Feb 12 08:10:52 optiplex systemd[1]: user@0.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped User Manager for UID 0.
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26209 to compat systemd cgroup /user.slice/user-0.slice/user-runtime-dir@0.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping User Runtime Directory /run/user/0...
Feb 12 08:10:52 optiplex systemd[26209]: Failed to attach 26209 to compat systemd cgroup /user.slice/user-0.slice/user-runtime-dir@0.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[12163]: run-user-0.mount: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: run-user-0.mount: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Unmounted /run/user/0.
Feb 12 08:10:52 optiplex systemd[1]: udisks2.service: Succeeded.
Feb 12 08:10:52 optiplex systemd[1]: Stopped Disk Manager.
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26213 to compat systemd cgroup /system.slice/watchdog.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[26213]: Failed to attach 26213 to compat systemd cgroup /system.slice/watchdog.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: watchdog.service: Control process exited, code=exited, status=1/FAILURE
Feb 12 08:10:52 optiplex systemd[1]: watchdog.service: Failed with result 'exit-code'.
Feb 12 08:10:52 optiplex systemd[1]: Stopped watchdog daemon.
Feb 12 08:10:52 optiplex systemd[1]: watchdog.service: Triggering OnFailure= dependencies.
Feb 12 08:10:52 optiplex systemd[1]: Requested transaction contradicts existing jobs: Transaction for wd_keepalive.service/start is destructive (time-sync.target has 'stop' job queued, but 'start' is included in transaction).
Feb 12 08:10:52 optiplex systemd[1]: watchdog.service: Failed to enqueue OnFailure= job, ignoring: Transaction for wd_keepalive.service/start is destructive (time-sync.target has 'stop' job queued, but 'start' is included in transaction).
Feb 12 08:10:52 optiplex systemd[1]: Stopped target Multi-User System.
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26214 to compat systemd cgroup /system.slice/speech-dispatcher.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping LSB: Speech Dispatcher...
Feb 12 08:10:52 optiplex systemd[26214]: Failed to attach 26214 to compat systemd cgroup /system.slice/speech-dispatcher.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26215 to compat systemd cgroup /system.slice/fail2ban.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping Fail2Ban Service...
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26216 to compat systemd cgroup /system.slice/lightdm.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping LSB: Light Display Manager...
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26217 to compat systemd cgroup /system.slice/virtualbox.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping LSB: VirtualBox Linux kernel module...
Feb 12 08:10:52 optiplex systemd[1]: Failed to attach 26219 to compat systemd cgroup /system.slice/fam.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[1]: Stopping LSB: File Alteration Monitor...
Feb 12 08:10:52 optiplex systemd[26216]: Failed to attach 26216 to compat systemd cgroup /system.slice/lightdm.service: No such file or directory
Feb 12 08:10:52 optiplex systemd[26215]: Failed to attach 26215 to compat systemd cgroup /system.slice/fail2ban.service: No such file or directory

Почему-то хардварный watchdog тоже не сработал.
Нужно будет разбираться, почему. Он должен был спасти.

P.S. система не зависла, перезагрузил с помощью magic keys.

Ссылка

←	Как использовать jwilder/nginx-proxy

как это работает ospf vlan

→

← 1 2 3 →

У меня комп есть такой конченый Китай типа импортозамещение промышленных ПК от гнилой конторки. Вот в нём если в биосе тип ОС не сменить - он не выключается точно так же как на скриншоте.

К чему это я? А причём здесь systemd?

system-root ★★★★★
(19.11.20 14:52:31 MSK)
Последнее исправление: system-root 19.11.20 14:53:23 MSK (всего исправлений: 1)

Ссылка

Ответ на: комментарий от intelfx 18.11.20 14:14:35 MSK

Тот самый анон. Ну всё я при своём мнении. Но справедливости ради скажу. Что да в тот момент когда начался переход на тот момент ещё спорный и с идеями поддерживать сразу всё. То случился конфуз, конечные маинтейнеры просто не знали как им быть так как ещё было неясно будет ли поддержка всего и только системаД поэтому вроде как логично никто не стал трогать инит скрипты ведь зачем ихменять если поддержка должна была в теории остаться, а некоторые в дополнение к этому добавили ещё и юниты, но с тем условием что использоваться будет или то или то в зависимости от выбраного инита. По итогу были случаи когда сначло стартовало /etc/init.d/blabla а потом падал при запуске юнит пускавший тоже самое. В тот момент был полный дурдом, но это была проблема колебающегося решения как же всё же будет. Случилось то что случилось. Но опять же до сих пор можно и по старинке и по новому и в большинстве случаев всё живо. Но в отдельных доносятся отгласки. И ещё раз уж говорим Debian это не только linux. В этом важность, вот сейчас по факту только, но в целом нет. И именно для этого есть абстракция над всем в виде service для того что в случае появления нового например завтра появится новый системZ делающий похожие вещи интерфейс был бы прежним. СистемД не стандарт и через несколько лет может случится рождение «нового».

anonymous
(19.11.20 14:53:22 MSK)

Ссылка

Ответ на: комментарий от mazdai 19.11.20 14:34:12 MSK

На каком девайсе корень, проверял ли ты целостность ФС и состояние накопителя?

NVME, в полном здравии.
Я вообще хз зачем этот старый топик подняли.

Это конечно был довольно зачётный фейл, но решать тут особо нечего.
Свежий топик интереснее: Перестали монтироваться LUKS контейнеры

Там с cryptroot потенциально на этапе загрузки можно было бы получить кирпич.

aidaho ★★★★★
(19.11.20 14:57:31 MSK) автор топика

Ссылка

Ответ на: комментарий от intelfx 18.11.20 14:02:02 MSK

это непременно происходит с каким-то нездоровым фетишем на высокоуровневую обратную совместимость.

Сволочи! Нет бы выкинуть всё нахрен!

P.S. Debian, если что, - это набор «высокоуровневых» скриптов для худо-бедно вменяемого управления всей этой опенсорс-помойкой. Ну и плюс бэкпорты, да.

LamerOk ★★★★★
(19.11.20 15:01:41 MSK)

Ссылка

Ответ на: комментарий от intelfx 18.11.20 14:14:35 MSK

есть такой забавный психологический феномен: когда у тебя номинально есть обратная совместимость, это как бы означает, что нативной поддержкой новых технологий можно как бы и не запариваться вовсе. И плевать, что работать оно будет через пень-колоду. В итоге Debian 8 зарелизился в таком состоянии, что огромная часть демонов даже из основного репозитория поставлялись не с юнитами, а со скриптами,

Слова не мальчика, но школоторна.

Кто тебе все эти 100500 скриптов запуска будет переписывать и проверять на баги? Лётчик Пушкин? Или, может, ты вызовешься добровольцем? Раз не вызвался, значит бери то, что сделало сообщество. И вот тут как раз видно как сообществу были нужны ~~те же яйца, только в профиль~~ «новая технология».

LamerOk ★★★★★
(19.11.20 15:56:45 MSK)

Ответ на: комментарий от LamerOk 19.11.20 15:56:45 MSK

Слова не мальчика, но школоторна.

Уж лучше школотрон, чем старпёр.

то тебе все эти 100500 скриптов запуска будет переписывать и проверять на баги?

Ответственные за пакеты, очевидно. На то они и ответственные.

Или, может, ты вызовешься добровольцем? Раз не вызвался, значит бери то, что сделало сообщество.

Сам придумал — сам ответил, молодец-то какой. Есть только одна проблема, я не пользуюсь Debian (что не мешает мне его критиковать). А в жизни своего дистрибутива я вполне себе активно участвую, спасибо.

И вот тут как раз видно как сообществу были нужны

Ну да, отлично видно, из кого состоит «сообщество» дебиан_овец-легасилюбов. Этим ничего не нужно, пока на локалхосте работает.

intelfx ★★★★★
(19.11.20 16:16:25 MSK)
Последнее исправление: intelfx 19.11.20 16:29:20 MSK (всего исправлений: 2)

Ответ на: комментарий от intelfx 19.11.20 16:16:25 MSK

Уж лучше школотрон, чем старпёр.

Чем лучше? И давай уже, взрослей. А то смотрю годы идут, а ты всё такой же психопат и нигилист как в 16 лет. Закончишь дуркой.

anonymous
(19.11.20 16:47:48 MSK)

Ссылка

Полчаса назад столкнулся с этим на Debian 10.

Разом сошли с ума NetworkManager.service, nm-applet и DBus, последний ВСЕГДА триггерит кучу проблем с systemd.

systemctl poweroff говорит что уже в процессе (почти час с_ка!), systemctl poweroff --force поставил всё раком.

Зато модно-молодёжно!

mord0d ★★★★★
(19.11.20 16:58:22 MSK)

Ответ на: комментарий от mord0d 19.11.20 16:58:22 MSK

NetworkManager.service, nm-applet

А зачем это говно в дебиане? Я даже вафлёй и модемом через ifup/ifdown рулю.

anonymous
(19.11.20 17:12:31 MSK)

Ответ на: комментарий от anonymous 19.11.20 17:12:31 MSK

А зачем это говно в дебиане?

Потому что юзер ниасилил, он даже пароль рута запомнить не смог. Там стоит Debian 10 с дефолтным MATE из официального репозитория, никаких допилов не проводилось. Юзер прибежал с таким вот чозанахом.

Хардресет — лучший инструмент починки ~~Windows~~ Linux!

// В родной FreeBSD такой херни нет!

mord0d ★★★★★
(19.11.20 17:33:11 MSK)

Ссылка

Ответ на: комментарий от aidaho 19.11.20 14:30:46 MSK

Бомбит от того, что не решил проблему? Так ты валидола выпей, а то инфаркт схватишь.

~~RedEyedMan666~~ ★
(19.11.20 18:04:07 MSK)

Ответ на: комментарий от mord0d 19.11.20 16:58:22 MSK

DBus, последний ВСЕГДА триггерит кучу проблем с systemd

Проблемный dbus в 2020 пол-системы приведёт в полурабочий вид. Сегодня слишком много на него завязано.
Так же было и с его предком dcop, который в случае чего разваливал kdeшную сессию.
От того и справедливо предъявлять «неадекватно» высокие требования к таким компонентам, которые хотят рулить всем.

В это всё входят в том числе и «плохие и нехорошие» конфигурации debian.

systemctl poweroff говорит что уже в процессе (почти час с_ка!) systemctl poweroff –force поставил всё раком.

Много чего можно о достоинствах и недостатках systemd говорить, но для init’а такое, как ни крути, провал.

Может, конечно, подобное и до systemd можно было поймать, но мне не доводилось.
После небольшого таймаута прилетали SIGTERM, SIGKILL и цикл по питанию.
Обработал, не обработал процесс, всё равно была уверенность, что коробка не останется в подвешенном виде.

Теперь уверенности нет.

aidaho ★★★★★
(19.11.20 18:06:50 MSK) автор топика

Ответ на: комментарий от aidaho 19.11.20 18:06:50 MSK

Debian и у меня машину не всегда выключал. Что характерно, с другими дистрибутивом у меня таких проблем нет. Может, дело всё-таки в уникальном наборе костылей демьяна?

anonymous
(19.11.20 18:11:51 MSK)

Ответ на: комментарий от RedEyedMan666 19.11.20 18:04:07 MSK

Руками машешь, только воздух мешаешь.
Открой глаза, топик почитай, глядишь с открытыми и получится во что-то попасть.

Пока мимо.

aidaho ★★★★★
(19.11.20 18:12:21 MSK) автор топика

Ответ на: комментарий от aidaho 19.11.20 18:12:21 MSK

Дистр смени, тогда будет не мимо.

~~RedEyedMan666~~ ★
(19.11.20 18:13:06 MSK)

Ответ на: комментарий от anonymous 19.11.20 18:11:51 MSK

может дело в самой машине? ну нет у демьяна костылей к оригинальному железу (увы). они там на ширпотреб ориентируются.

anonymous
(19.11.20 18:15:26 MSK)

Ответ на: комментарий от RedEyedMan666 19.11.20 18:13:06 MSK

Если два релиза подряд будут такого качества, то задумаюсь.
Прыгать по дистрам от скуки я закончил давно.

Тут мнения как-то поделились на то что systemd говно, или debian говно.
Я, если что, в обоих лагерях, и вижу это как тандемный фейл.

aidaho ★★★★★
(19.11.20 18:17:14 MSK) автор топика

Ответ на: комментарий от aidaho 19.11.20 18:17:14 MSK

В Дебиане с системд такое часто бывало. На Gentoo всё нормально, но она тебе не нужна. Бери любой другой, где системду лучше готовят (скорее всего Fedora).

~~RedEyedMan666~~ ★
(19.11.20 18:21:13 MSK)

Ссылка

/bin/sh: 1: echo: echo: I/O error

Это не хорошо ))

З.Ы. Пользуясь случаем хочу передать привет всем любителям некропостинга

vasily_pupkin ★★★★★
(19.11.20 18:45:54 MSK)
Последнее исправление: vasily_pupkin 19.11.20 18:47:09 MSK (всего исправлений: 1)

Ссылка

Не раз сталкивался с невозможностью перегрузить удаленно даже на ровном месте.

Логика sysvinit мне нравилась больше: остановил всё что останавливается, всем кто остался - kill -TERM, sleep, kill -KILL и reboot/poweroff.

А в этом системд аж семикратное c-a-del придумали. Как мне это нажать удаленно, особенно после команды reboot?

sergej ★★★★★
(19.11.20 18:52:07 MSK)

Ссылка

Ответ на: комментарий от intelfx 19.11.20 16:16:25 MSK

Ответственные за пакеты, очевидно. На то они и ответственные.

Сообщество Debian - это не твой любимый ГУЛАГ, по которому ты так скучаешь. Ты не можешь заставить людей делать то, что они не хотят.

Этим ничего не нужно, пока на локалхосте работает.

Да-да, именно по этому Debian - первая опция установки линукса в любом ДЦ и в любом VPS. Потому что на локалхостах работает.

LamerOk ★★★★★
(19.11.20 19:10:13 MSK)

Ссылка

Ответ на: комментарий от intelfx 19.11.20 10:40:19 MSK

К счастью, это постепенно уходит в прошлое. В актуальном гноме, например, для управления сессией полностью переехали на systemd. Теперь в гноме всё аккуратно запускается и завершается в правильном порядке.

В KDE тоже на systemd переезжают: http://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/.

Ja-Ja-Hey-Ho ★★★★★
(19.11.20 19:44:48 MSK)

Ссылка

Ответ на: комментарий от anonymous 19.11.20 18:15:26 MSK

может дело в самой машине?

Если остальные дистрибутивы работают, а демьян нет, то дело в машине. Ну, конечно! Кто бы мог подумать?

anonymous
(19.11.20 19:47:35 MSK)

Ссылка

Ответ на: комментарий от aidaho 19.11.20 18:06:50 MSK

Проблемный dbus в 2020 пол-системы приведёт в полурабочий вид. Сегодня слишком много на него завязано.

Но завязывать на него инит — это надо быть больным.

В это всё входят в том числе и «плохие и нехорошие» конфигурации debian.

Debian или нет, а dbus — это сервис, который может отвалиться. Причём не обязательно упасть а просто глюкануть.

для init’а такое, как ни крути, провал

Я добровольно использовал systemd в Gentoo. Достаточно долго использовал, чтобы иметь право сказать что этот инструмент не готов. Идея хорошая, реализация — говно.

Может, конечно, подобное и до systemd можно было поймать, но мне не доводилось.

Ну отвалится dbus с каким-нибудь ck2, не сможешь на горячую переключать юзеров или от юзера ребутнуться или нормально завершить сессию. Но когда из-за dbus невозможно вырубить/ребутнуть систему даже от рута — это 3.14-здец!

mord0d ★★★★★
(19.11.20 20:59:18 MSK)

Ссылка

Ответ на: комментарий от X512 19.11.20 09:49:51 MSK

Заставили меня перечитать тему 9-месячной давности…

Кто мешает делать релизы дистрибутивов из релизных исходников пакетов?

Ошибки, находимые уже после релиза той версии, что должна попасть в выпуск.

Одно из преимуществ таких релизных дистрибутивов как Debian в том, что ПО проходит достаточно длительный период тестирования перед выпуском. Разумеется, за этот период в нём находятся ошибки — в этом и смысл тестирования. Если исправлять эти ошибки путём обновления релизной версии ПО, то снова тестировать приходится не только исправление самой ошибки, но и всю вносимую новую функциональность. Если на каждую такую ошибку существенно обновлять ПО, то выпуск никогда не выйдет.

У большинства крупных проектов перед выпуском есть feature freeze — с чего бы у дистрибутивов было иначе?

Внесение изменений в оригинальные исходники пакетов это тоже самое, что и ZverCD в мире Windows.

Вообще-то, суть opensource как раз и состоит в возможности изменения оригинальных исходников пакетов. Если эти изменения открыты и касаются лишь исправления ошибок и интеграции в инфраструктуру дистрибутива — в чём проблема? Это же не Ubuntu, где изменения порой существенно меняют функциональность.

Rootlexx ★★★★★
(20.11.20 15:57:13 MSK)

Ответ на: комментарий от intelfx 13.02.20 19:29:58 MSK

Это я-то саппорт, лол. Так-то саппорт не имеет права говорить, что конечные юзеры дебилы. А я это как разработчик говорю. %)

intelfx ★★★★★ (13.02.20 19:29:58) Е*нутыйd нимбоносецd.

Ааа…вот теперь я вспомнил, почему я тебе такой комментарий поставил.

~~Oberstserj~~ ★★
(20.11.20 16:04:43 MSK)

Ответ на: комментарий от anonymous 13.02.20 19:37:57 MSK

Я как обычный юзер говорю, что разработчики дебилы. 🤭

ИЧСХ, ты до безобразия прав.

~~Oberstserj~~ ★★
(20.11.20 16:05:13 MSK)

Ссылка

Ответ на: комментарий от RedEyedMan666 19.11.20 14:22:17 MSK

До сих пор так и не решил проблему? 10-летним стажем юзера от топикстартера так и прет…

Ну так помоги, повысь свое ЧСВ, делов-то…

~~Oberstserj~~ ★★
(20.11.20 16:13:42 MSK)

Ссылка

Ответ на: комментарий от Oberstserj 20.11.20 16:04:43 MSK

Не волнуйся, у меня про тебя тоже есть комментарий.

intelfx ★★★★★
(20.11.20 17:57:14 MSK)

Ссылка

Ответ на: комментарий от Rootlexx 20.11.20 15:57:13 MSK

Ошибки, находимые уже после релиза той версии, что должна попасть в выпуск.

Если это релиз, то серьёзных ошибок там быть не должно. Иначе это проблема в компетенции авторов программы которые под видом релиза выкладывают непроверенную альфа версию.

Вообще-то, суть opensource как раз и состоит в возможности изменения оригинальных исходников пакетов.

Тогда делайте форк и не путайте людей. При виде программы с определённым названием я ожидаю видеть определённое содержание, а не хакерство со стороны авторов сборки. Всякие «готовка кедов» - это абсурд. Была даже история с Firefox, когда авторы дистрибутива включали неудаляемые плагины и Firefox отключил поддержку директории плагинов чтобы не допускать такой ситуации.

X512 ★★★★★
(20.11.20 19:16:37 MSK)
Последнее исправление: X512 20.11.20 19:20:33 MSK (всего исправлений: 1)

Ответ на: комментарий от X512 20.11.20 19:16:37 MSK

Если это релиз, то серьёзных ошибок там быть не должно.

В мире единорогов и розовых пони — возможно. Реальность — она немного иная, к сожалению.

Иначе это проблема в компетенции авторов программы которые под видом релиза выкладывают непроверенную альфа версию.

Абсолютно все сценарии использования для хоть сколь-нибудь крупного проекта проверить просто нереально. Поэтому цель тестирования не в полном исключении ошибок (что невозможно), а в минимизации их количества.

Достаточно посмотреть список изменений любого крупного проекта и увидеть там закрытые уязвимости, исправленные падения и проч.

Тогда делайте форк и не путайте людей.

Fork ради исправления пары ошибок? Серьёзно?

При виде программы с определённым названием я ожидаю видеть определённое содержание, а не хакерство со стороны авторов сборки.

Чем наложение патча, исправляющего, например, падение программы, мешает вам «видеть определённое содержание»?

Вы, вероятно, говорите об изменениях, существенно меняющих поведение программы — ну так я тоже против подобного волюнтаризма. Однако в Debian подобным не занимаются, и налагаемые патчи либо исправляют ошибки, либо интегрируют программу в окружение Debian.

Rootlexx ★★★★★
(21.11.20 23:47:16 MSK)

Ответ на: комментарий от LongLiveUbuntu 18.11.20 12:56:25 MSK

Некропостер, зачем ты существуешь?

dexpl ★★★★★
(22.11.20 00:05:09 MSK)

Ссылка

Ответ на: комментарий от Rootlexx 21.11.20 23:47:16 MSK

В мире единорогов и розовых пони — возможно.

Ошибки в исходниках проекта - это не область ответственности дистрибутива. Все вопросы должны быть к авторам проекта.

Поэтому цель тестирования не в полном исключении ошибок (что невозможно), а в минимизации их количества.

Можно отдельно выпускать дистрибутив из релизных версий пакетов и из тестовых альфа версий.

Fork ради исправления пары ошибок? Серьёзно?

Да, серьёзно. Исправления должны приниматься в сам проект, а не дистрибутив. Если исправления в упор не принимают (not a bug, wont fix), то авторы неадекваты и форк необходим.

Чем наложение патча, исправляющего, например, падение программы, мешает вам «видеть определённое содержание»?

Где гарантия, что там только такие патчи? Почему их нельзя отправить в основной проект?

либо интегрируют программу в окружение Debian

Мутная формулировка. Иногда это приводит к изменению поведения программы.

X512 ★★★★★
(22.11.20 00:39:45 MSK)

Ответ на: комментарий от X512 19.11.20 10:01:27 MSK

upstart, openrc. Sysvinit, да.

LongLiveUbuntu ★★★★★
(22.11.20 12:18:40 MSK)

Ссылка

Ответ на: комментарий от anonymous 19.11.20 13:25:12 MSK

А при недостатке ресурсов (диск, память, сеть и т.д.)

Плохой демон!

LongLiveUbuntu ★★★★★
(22.11.20 12:51:59 MSK)

Ответ на: комментарий от LamerOk 19.11.20 15:56:45 MSK

Лётчик Пушкин?

Ah, I see you’re man of culture as well.

eternal_sorrow ★★★★★
(22.11.20 17:15:14 MSK)

Ссылка

Ответ на: комментарий от lenin386 13.02.20 18:04:55 MSK

_Все «хардварные» вотчдоги - глюкло.

Только биметалличечкое тепловое реле, только хардкор!

atsym ★★★★★
(22.11.20 18:44:08 MSK)

Ссылка

Ответ на: комментарий от X512 22.11.20 00:39:45 MSK

Ошибки в исходниках проекта - это не область ответственности дистрибутива. Все вопросы должны быть к авторам проекта.

Так авторы их и исправляют — в новой версии программы. В которой также есть новая функциональность, изменения поведения и новые ошибки. Что тогда делать релизным дистрибутивам, если не накладывать исправляющие ошибки патчи на ту версию, которая в дистрибутиве?

Можно отдельно выпускать дистрибутив из релизных версий пакетов и из тестовых альфа версий.

Как это убережёт или поможет исправить ошибки в релизных версиях программ?

Исправления должны приниматься в сам проект, а не дистрибутив.

Да неужели, кто бы мог подумать…

Внезапно, ровно так и происходит. Второй раз в этой теме даю ссылку: https://www.debian.org/doc/debian-policy/ch-source.html#changes-to-the-upstream-sources

Где гарантия, что там только такие патчи?

В открытости этих патчей. Они даже в отдельном от оригинальных исходников архиве идут.

Почему их нельзя отправить в основной проект?

Вы эту глупость придумали — вы и отвечайте.

Мутная формулировка. Иногда это приводит к изменению поведения программы.

Пример существенного изменения в поведении программы — в студию!

Rootlexx ★★★★★
(22.11.20 23:35:50 MSK)
Последнее исправление: Rootlexx 22.11.20 23:37:05 MSK (всего исправлений: 1)

Ответ на: комментарий от Rootlexx 22.11.20 23:35:50 MSK

Так авторы их и исправляют — в новой версии программы.

Почему авторы программы не могут исправлять старые версии?

X512 ★★★★★
(23.11.20 00:27:30 MSK)

Ответ на: комментарий от LongLiveUbuntu 22.11.20 12:51:59 MSK

Плохой демон!

Демоны все плохие. Нечисть надо изгонять.

X512 ★★★★★
(23.11.20 00:36:34 MSK)

Ответ на: комментарий от X512 23.11.20 00:27:30 MSK

Почему авторы программы не могут исправлять старые версии?

Это точно ко мне вопрос?

Если вы хотите поговорить на тему «как хорошо было бы, если бы…» — то извините, но мне это неинтересно. Есть реальность, и она заключается в том, что у подавляющего числа проектов нет ветки с длительной поддержкой, которую можно было бы засунуть в дистрибутивы и просто обновлять в рамках минорных версий, не опасаясь всё сломать. Поэтому приходится переносить исправления из новых версий в старые силами сопровождающих, увы.

Rootlexx ★★★★★
(23.11.20 02:18:35 MSK)