BunsenLabs (Debian derrivative) kapanmıyor (poweroff.target başlatılamadı: İşlem yıkıcı)

11

BunsenLabs GNU / Linux'umun (Debian'a dayanan) garip bir davranışına rastladım.

Bazen işletim sistemini kapatamıyorum. sudo poweroffGUI yaklaşımını kullanmamın önemi yok .

Bu çalıştırdıktan sonra olsun sudo poweroff:

Failed to start poweroff.target: Transaction is destructive

Bir çözüm var mı? Neden oluyor?

İşte benim içeriği /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
kaynak

1

Yapılandırma dosyası tamam, belki en iyi cevabı arayarak alabilirsiniz.

— GAD3R

8

Bir süredir çözüm için ıslanıyorum ve sonunda bir çözüm buldum. Benim için çalıştı. Bu garip davranışı neyin tetiklediğini bilmiyorum.

Debian'ınızı kapatmak için tarif:

Koş ps aux | grep suspend.

Sonuçlardan biri şöyle görünmelidir

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

Koş sudo kill 3651ya da sonuç pidiniz ne olursa olsun.
İlk defa bilgisayarı kapatabildim. İkinci kez killkomuttan hemen sonra bilgisayar uykuya daldı .

İşlemi öldürmeden önce grafik masaüstü ortamından çıkış yapmanız önerilir.

Kaynak: Ubuntu Forumları .

— Mateusz Piotrowski
kaynak

6

Bu soruya başka bir cevap ekliyorum, çünkü benim durumumda systemd-sleepçalışan bir süreç yoktu , ancak makinemi durduramıyorum, kapatamıyorum, güç kesemedim veya yeniden başlatamadım. (Bu davranışın systemdtamamen kötü amaçlı yazılım olarak nitelendirildiğini bir kez daha kanıtlıyoruz , ancak bu tartışmayı bir süre daha bırakalım.)

Sonunda, çekişmeme yardımcı olması için çekirdeğe başvurdum systemd. Aşağıdakiler, donanımın yeniden başlatılmasından çok farklı değildir (güç düğmesine basarak), ancak makineye fiziksel erişiminiz yoksa yardımcı olabilir:

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

Yeniden sonra devam tarafından dışarı silerek cehennem spawn.

— Alberto Santini
kaynak

1

Bu gerçekten son çare seçeneğidir. Çalışan bir veritabanınız veya veri bozulma olasılığınız yüksekse kaçının. Bu şekilde yeniden başlatmadan önce sistemin IO arabelleklerini gerçekten senkronize etmek echo bistersiniz: echo s > /proc/sysrq-trigger(ve bir süre bekleyin). Sonra, belki tüm dosya sistemlerini uydurmaya çalışın echo u(dikkatli, bu makineye uzak bağlantınızı kaybetmenize neden olup olmadığını bilmiyorum).

— Totor

1

@Totor haklısın ... sonunda kendinize bahsettiğiniz her şeyi yapan bir senaryo yazarken, ayrıca bazı hizmetleri kapatarak buldum. İşte o zaman temelde systemd beni kendi init betiğimi kapatmaya zorladı! 2016'ya hoş geldiniz ...

— Alberto Santini

1

Aynı sorun vardı.

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

Sonra koştum, systemctl start poweroff.target

Ve kapandı.

— Miati
kaynak

benim için çalışmıyor: "poweroff.target başlatılamadı: İşlem yıkıcı."

— Ben Aveling