BunsenLabs (dérive Debian) ne s'arrêtera pas (échec du démarrage de poweroff.target: la transaction est destructrice)

11

Je suis tombé sur un comportement étrange de mes BunsenLabs GNU / Linux (qui est basé sur Debian).

Parfois, je ne peux pas désactiver le système d'exploitation. Peu importe que j'utilise sudo poweroffou l'approche GUI.

Voici ce que j'obtiens après avoir couru sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

Y at-il un travail autour? Pourquoi cela se produit-il?

Voici le contenu de mon /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
la source
1
Le fichier de configuration est OK, vous obtenez peut-être la meilleure réponse en recherchant.
GAD3R

Réponses:

8

J'ai esquivé la solution pendant un certain temps et finalement j'ai trouvé une solution. Ça a marché pour moi. Je ne sais pas ce qui déclenche ce comportement étrange.

Voici la recette pour arrêter votre Debian:

  1. Courez ps aux | grep suspend.

  2. L'un des résultats devrait ressembler à ceci

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

  3. Exécutez sudo kill 3651ou quel que soit le pid de votre résultat.

  4. À la première fois, j'ai pu arrêter le PC. La deuxième fois, le PC s'est endormi immédiatement après la killcommande.

Il est conseillé de vous déconnecter de l'environnement de bureau graphique avant de tuer le processus.

Source: Forums Ubuntu .

Mateusz Piotrowski
la source
6

J'ajoute une autre réponse à cette question, car dans mon cas, aucun systemd-sleepprocessus n'était en cours d'exécution, mais je ne pouvais pas arrêter, arrêter, éteindre ni redémarrer ma machine. (Je pense que ce comportement est une fois de plus une preuve qui systemdse qualifie pleinement comme un malware , mais laissons cette discussion pour une autre fois.)

Finalement, j'ai recouru au noyau pour obtenir de l'aide dans ma lutte contre systemd. Ce qui suit n'est pas si différent d'un redémarrage matériel (en appuyant sur le bouton d'alimentation), mais peut vous aider, si vous n'avez pas d'accès physique à la machine:

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

Une fois redémarré, procédez en éliminant le rejeton de l'enfer.

Alberto Santini
la source
1
C'est vraiment la dernière option. À éviter si vous avez une base de données en cours d'exécution ou si vous avez de bonnes chances de corruption des données. Vous voulez vraiment synchroniser les tampons d'E / S du système avant de redémarrer avec echo bcomme ceci: echo s > /proc/sysrq-trigger(et attendez un certain temps). Ensuite, essayez peut-être de démonter tous les systèmes de fichiers avec echo u(attention, celui-ci, je ne sais pas si cela pourrait vous faire perdre votre connexion à distance à la machine).
Totor
1
@Totor vous avez raison ... à la fin, je me suis retrouvé à écrire un script qui fait tout ce que vous avez mentionné, en plus de fermer certains services. C'est à ce moment-là que j'ai réalisé que fondamentalement systemd m'obligeait à écrire mon propre script d'initialisation pour arrêter! Bienvenue en 2016 ...
Alberto Santini
1

Eu ce même problème. 

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

J'ai ensuite couru, systemctl start poweroff.target

Et ça s'est arrêté.

Miati
la source
ne fonctionne pas pour moi: "Impossible de démarrer poweroff.target: la transaction est destructrice."
Ben Aveling