BunsenLabs (Debian derrivative) nie chce się zamknąć (nie udało się uruchomić poweroff.target: Transakcja jest destrukcyjna)

11

Natknąłem się na dziwne zachowanie mojego BunsenLabs GNU / Linux (opartego na Debianie).

Czasami nie mogę wyłączyć systemu operacyjnego. Nie ważne, czy używam, sudo poweroffczy GUI.

Oto co otrzymuję po uruchomieniu sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

Czy jest w pobliżu praca? Dlaczego tak się dzieje?

Oto treść mojego /lib/udev/rules.d/70-power-switch.rules:

ACTION=="remove", GOTO="power_switch_end"

SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"
SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="thinkpad_acpi", TAG+="power-switch"

LABEL="power_switch_end"
systemd udev shutdown bunsenlabs Mateusz Piotrowski
źródło
1
Plik konfiguracyjny jest OK. Być może uzyskasz najlepszą odpowiedź, wyszukując.
GAD3R

Odpowiedzi:

8

Przez jakiś czas szukałem rozwiązania i wreszcie znalazłem rozwiązanie. To zadziałało dla mnie. Nie wiem jednak, co powoduje to dziwne zachowanie.

Oto przepis na zamknięcie twojego Debiana:

  1. Uruchom ps aux | grep suspend.

  2. Jeden z wyników powinien wyglądać tak

    root 3651 0.0 0.0 8668 1716 ? Ss 07:18 0:00 /lib/systemd/systemd-sleep suspend

  3. Uruchom sudo kill 3651lub cokolwiek pid wyniku.

  4. Po raz pierwszy udało mi się zamknąć komputer. Za drugim razem komputer poszedł spać natychmiast po wydaniu killpolecenia.

Zaleca się wylogowanie ze środowiska graficznego przed zabiciem procesu.

Źródło: Fora Ubuntu .

Mateusz Piotrowski
źródło
6

Dodaję kolejną odpowiedź na to pytanie, ponieważ w moim przypadku systemd-sleepproces nie był uruchomiony, ale nie mogłem się zatrzymać, zamknąć, wyłączyć ani zrestartować komputera. (Myślę, że to zachowanie jest kolejnym dowodem, że w systemdpełni kwalifikuje się jako złośliwe oprogramowanie , ale zostawmy tę dyskusję na inny czas).

W końcu zwróciłem się do jądra o pomoc w mojej walce z systemd. Poniższe czynności nie różnią się tak bardzo od ponownego uruchomienia komputera (naciśnięcie przycisku zasilania), ale mogą pomóc, jeśli nie masz fizycznego dostępu do komputera:

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Po ponownym uruchomieniu przejdź dalej , usuwając spawn z piekła.

Alberto Santini
źródło
1
To naprawdę ostatnia opcja. Unikaj, jeśli masz uruchomioną bazę danych lub masz duże szanse na uszkodzenie danych. Naprawdę chcesz zsynchronizować bufory IO systemu przed ponownym uruchomieniem w echo bnastępujący sposób: echo s > /proc/sysrq-trigger(i poczekaj trochę czasu). Następnie może spróbuj podłączyć wszystkie systemy plików echo u(ostrożnie, ten nie wiem, czy może to spowodować utratę zdalnego połączenia z maszyną).
Totor
1
@Totor masz rację ... w końcu napisałem skrypt, który robi wszystko, o czym wspomniałeś, i wyłączam niektóre usługi. Wtedy zdałem sobie sprawę, że w zasadzie systemd zmusił mnie do napisania własnego skryptu init do zamknięcia! Witamy w 2016 ...
Alberto Santini,
1

Miałem ten sam problem. 

# systemctl status poweroff.target 
● poweroff.target - Power-Off
  Loaded: loaded (/lib/systemd/system/poweroff.target; enabled; vendor preset: 
  Active: inactive (dead)
    Docs: man:systemd.special(7)

Potem pobiegłem, systemctl start poweroff.target

I to się skończyło.

Miati
źródło
nie działa dla mnie: „Nie udało się uruchomić poweroff.target: Transakcja jest destrukcyjna”.
Ben Aveling,