BunsenLabs (Debian derrivative) non si spegne (Impossibile avviare poweroff.target: la transazione è distruttiva)

11

Mi sono imbattuto in uno strano comportamento del mio GNU / Linux di BunsenLabs (basato su Debian).

A volte non riesco a spegnere il sistema operativo. Non importa se utilizzo sudo poweroffo l'approccio GUI.

Questo è quello che ottengo dopo l'esecuzione sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

C'è una soluzione? Perché sta succedendo?

Ecco il contenuto del mio /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"

— Mateusz Piotrowski
fonte

1

Il file di configurazione è OK, forse puoi ottenere la risposta migliore cercando.

— GAD3R,

8

Ho cercato la soluzione per un po 'e finalmente ho trovato una soluzione. Ha funzionato per me. Non so cosa scateni questo strano comportamento però.

Questa è la ricetta per spegnere Debian:

Corri ps aux | grep suspend.

Uno dei risultati dovrebbe apparire così

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

Esegui sudo kill 3651o qualunque sia il pid del tuo risultato.
Per la prima volta, sono stato in grado di spegnere il PC. La seconda volta che il PC è andato a dormire immediatamente dopo il killcomando.

Si consiglia di disconnettersi dall'ambiente desktop grafico prima di interrompere il processo.

Fonte: forum Ubuntu .

— Mateusz Piotrowski
fonte

6

Sto aggiungendo un'altra risposta a questa domanda, perché nel mio caso non c'era alcun systemd-sleepprocesso in esecuzione, eppure non sono riuscito a fermare, spegnere, spegnere e riavviare la mia macchina. (Penso che questo comportamento sia ancora una volta la prova che si systemdqualifica completamente come malware , ma lasciamo quella discussione per un'altra volta.)

Alla fine, ho fatto ricorso al kernel per un aiuto nella mia lotta contro systemd. Quanto segue non è così diverso da un riavvio forzato (premendo il pulsante di accensione), ma può aiutare, nel caso in cui non si abbia accesso fisico alla macchina:

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

Una volta riavviato, procedere dal spazzando via le uova di inferno.

— Alberto Santini
fonte

1

Questa è davvero l'ultima opzione da ricorrere. Evitare se si dispone di un database in esecuzione o buone possibilità di corruzione dei dati. Vuoi davvero sincronizzare i buffer IO del sistema prima di riavviare in echo bquesto modo: echo s > /proc/sysrq-trigger(e attendere qualche istante). Quindi, forse prova a smontare tutti i filesystem con echo u(attenzione, questo non so se potrebbe farti perdere la connessione remota alla macchina).

— Totor

1

@Totor hai ragione ... alla fine mi sono ritrovato a scrivere una sceneggiatura che fa tutto ciò che hai menzionato, oltre a chiudere qualche servizio. Fu allora che mi resi conto che fondamentalmente systemd mi costringeva a scrivere il mio script init per lo spegnimento! Benvenuti nel 2016 ...

— Alberto Santini,

1

Ha avuto lo stesso problema.

# 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)

Ho quindi eseguito, systemctl start poweroff.target

E si è spento.

— Miati
fonte

non funziona per me: "Impossibile avviare poweroff.target: la transazione è distruttiva."

— Ben Aveling,