Pekerjaan berhenti sedang berjalan untuk Sesi c2 pengguna

56

Pesan berikut ini muncul hampir setiap kali saya mematikan komputer saya:

A stop job is running for Session c2 of user ... (1min 30s)

Ia menunggu 1 menit 30-an kemudian melanjutkan proses penutupan. Saya mengikuti panduan diagnosis shutdown systemd ini dan mendapatkan shutdown-log.txt (saya tidak bisa menempel langsung log di sini karena sangat panjang). Sayangnya, saya tidak mengerti log itu sendiri. Adakah yang bisa membantu saya mencari tahu apa yang membuat sistem saya tidak mati dengan benar?

Saya menjalankan Arch Linux dengan kernel 4.4.5-1-ARCH, systemdversi saya adalah 229-3.

Tambahan 1: Saya mengamati bahwa setiap kali saya keluar, dan kemudian mematikan komputer saya dari layar masuk, itu tidak mendapatkan pesan A stop job is running.... Saya mencoba keluar sebelum shutdown berkali-kali, jadi saya pikir itu tidak terjadi secara kebetulan. Semoga informasi itu dapat membantu.

Tambahan 2: Itu selalu sesi c2 yang menyebabkan shutdown hanging. Sehingga @ n.st menyarankan, saya melihat Masalah Shutdown Mendiagnosis lagi dan disimpan loginctl session-status c2bukan dmesg, tapi kemudian tidak ada di shutdown-log.txt. Saya diganti loginctl session-status c2oleh systemd-cglsdan mendapat log berikut:

Control group /:
-.slice
└─init.scope
  ├─   1 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1069 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1071 /bin/sh /usr/lib/systemd/system-shutdown/debug.sh reboot
  └─1074 systemd-cgls

Ada ide?

Catatan: Setelah saya perbarui ke kernel 4.6.4-1-ARCHdan systemd 230-7, kesalahan tidak lagi terjadi.

systemd shutdown

— macnguyen
sumber

Sayangnya dmesgoutput yang Anda tempel tidak terlalu informatif - ini menunjukkan WiFi terputus ketika Anda menekan tombol shutdown (3048 detik setelah boot sistem) dan kemudian tidak ada sampai timer 1m30an berakhir dan sistem terus mematikan (pada 3139 detik).

— n.st

1

Untuk memeriksa apa yang sedang berjalan di sesi c2 yang tidak menyenangkan itu yang tidak berakhir dengan sendirinya, gunakan loginctl session-status c2. Saya tidak yakin apakah Anda masih dapat beralih ke getty selama shutdown, tetapi cobalah menekan Ctrl + Alt + F2 ketika "Stop job sedang berjalan ..." muncul. Jika berhasil, Anda akan mendapatkan prompt masuk dan akan dapat menggunakan loginctlperintah. Jika Anda tidak mendapatkan prompt masuk, ikuti langkah yang sama dengan yang Anda gunakan dmesg, tetapi simpan hasilnya loginctl session-status c2sebagai gantinya. (Itu semua dengan asumsi bahwa itu selalu "c2" yang menggantung, bukan sesi lain setiap kali.)

— n.st

1

Anda mungkin mendapatkan perbaikan (sementara) oleh peretasan ini: Buat /etc/sysctl.d/50-coredump.confdengan konten :,kernel.core_pattern=core ref: github.com/systemd/systemd/issues/1615#issuecomment-203507283

— Runium

1

github.com/systemd/systemd/issues/2691 Ini mungkin relevan

— Natecat

2

@aurelien Apakah selalu c2 yang menyebabkan timer mati? Jika demikian, Anda bisa mengikuti Masalah Shutdown Mendiagnosis lagi dan toko loginctl session-status c2bukan dmesg.

— n.st

45

Solusi untuk masalah ini adalah untuk mengurangi batas waktu ini /etc/systemd/system.confdari 90-an menjadi misalnya 10-an:

DefaultTimeoutStopSec=10s

dan jalankan perintah berikut di terminal setelah melakukan perubahan

$ systemctl daemon-reload

— MightyPork
sumber

9

ini tidak menjelaskan atau menyelesaikan masalah, juga menunggu 10-an dan bahkan tidak memiliki shutdown bersih tidak bagus sama sekali

— jcora

Apakah ada pekerjaan yang harus diselesaikan lebih dari 10 detik?

— Jared Chu

10

Masalah ini dapat memiliki banyak penyebab, jadi jawaban spesifik tidak berfungsi dengan baik. Coba ini untuk pemecahan masalah:

tunggu pesan "Pekerjaan berhenti sedang berjalan untuk Sesi c2 ..." muncul di shutdown dan reboot setelah shutdown selesai
jalankan journalctl -p5di terminal dan tekan ENDuntuk sampai ke akhir jurnal systemd ( -p5menyaring banyak sampah)
memulai pencarian dengan menekan /dan memasukkan istilah pencariantimed out. Killing.
cari mundur dengan menekan SHIFT+Nberulang kali
baris di bawah setiap pertandingan memberi tahu Anda aplikasi mana yang bermasalah:Killing process 1234 (jack_thru) with signal SIGKILL.

Jika selalu aplikasi yang sama, Anda ingin mencari tahu apa fungsinya dan mengapa itu tidak berhenti saat shutdown. Kalau tidak, bisa jadi lebih rumit untuk menyelesaikan masalah, tetapi Anda mungkin masih mendapatkan satu atau dua petunjuk.

Semoga berhasil! :)

— mzuther
sumber

1

Terima kasih atas jawaban yang benar ini. Saya menggunakannya untuk menemukan bahwa dalam kasus saya, Fedora 30 pemberitahuan "lpf" adalah penyebabnya, dan dalam lpf-gui batal pilih Notifikasi | Aktifkan notifikasi.

— vk5tu

5

Saya memiliki masalah yang sama, mencari saya menemukan posting di forum reddit dari Arch Linux.

Berikut adalah solusi yang berfungsi untuk saya https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u

Instal pengawas

# pacman -S watchdog

Dan kemudian mulai layanan saat boot:

# systemctl enable watchdog.service

Mulai layanan untuk tidak melihat pesan lagi

# systemctl start watchdog.service

Saya membuat inti untuk ini https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3

— Diego Juliao
sumber

Saya mengikuti panduan Anda, tetapi itu tidak menyelesaikan masalah. Terima kasih.

— macnguyen

2

Apakah ada implikasi lain untuk perbaikan ini? Tampaknya watchdog perangkat keras akan mengatur ulang sistem jika tertinggal atau gagal dalam pengujian lainnya. Jadi ketika batas waktu dalam pertanyaan terjadi, anjing penjaga akan mengatur ulang komputer. Saya bertanya-tanya apakah sistem akan shutdown lebih bersih jika kita hanya mengurangi batas waktu sesuai jawaban yang lain . Saya juga bertanya-tanya apakah watchdogakan memaksa reset dalam situasi lain yang tidak diinginkan.

— Sparhawk

Saya membaca halaman manual Anda . Saya pikir pengawas mencegah reset memberitahu kernel linux bahwa semuanya OK,

— Diego Juliao

> Ini membuka / dev / watchdog, dan terus menulis cukup sering untuk menjaga kernel tidak mengatur ulang, setidaknya sekali per menit.

— Diego Juliao

Tidak ada paket bernama watchdog di OpenSuSE, jadi ini tidak benar-benar membantu saya :(

— David Faure

4

Saya menemukan solusi di sini yang bekerja untuk saya dengan Debian 9 di vbox. Saya mendapatkan penundaan 120 detik pada saat shutdown atau restart.

https://forums.kali.org/showthread.php?32498-Delay-90-seconds-on-shutdown

Lakukan persis seperti yang dikatakan Ironman:

Solusinya adalah dengan membuka shell dan "shutdown sekarang" kemudian ketika mesin kembali hidup kemudian lakukan "reboot" dan pesannya hilang dan reboot di masa depan tidak hang lagi.

Saya menggunakan "sudo shutdown sekarang" dan penundaan restart sekarang hilang. Tampaknya terlalu sederhana, tetapi itu berhasil untuk saya (dan yang lainnya).

HTH

— Dennis Cote
sumber

8

Mengapa jawaban ini memiliki banyak upvotes? Itu tidak bekerja untuk saya, dan tidak memberikan petunjuk mengapa itu harus bekerja.

— Rodrigo

Bekerja untuk saya, tetapi masih belum jelas mengapa itu terjadi.

— pstryk

3

Setelah memiliki masalah yang sama pada Kali [2017.01], dengan penundaan logout ditampilkan oleh:

"Pekerjaan berhenti sedang berjalan untuk Sesi c1 dari pengguna Debian-gdm"

"Pekerjaan berhenti sedang berjalan untuk Manajer pengguna untuk UID 132"

Saya berhasil menghapus satu kesalahan dengan terlebih dahulu berhenti NetworkManagersebelum mematikan atau menonaktifkannya, dengan:

# To get rid of: "A stop job is running for User manager for UID 132"
systemctl disable NetworkManager 
systemctl stop NetworkManager

Ini mungkin harus diperbaiki atau dimasukkan dengan cara lain saat me-reboot.

Adapun keterlambatan lainnya, saya belum berhasil. Sepertinya itu terkait dengan GDM ( Gnome Display Manager ), pulseaudioatau dbus. Jadi karena saya tidak dapat mengisolasi masalah, satu-satunya cara adalah mengatur DefaultTimeout*Sec=5sentri system.confseperti yang telah disebutkan dalam posting lain.

Masalah lain yang mungkin diselidiki ditunjukkan dalam:

# systemctl --state=masked --state=not-found --state=failed

  UNIT                           LOAD      ACTIVE   SUB  DESCRIPTION                   
● tmp.mount                      not-found inactive dead tmp.mount                     
● auditd.service                 not-found inactive dead auditd.service                
● console-screen.service         not-found inactive dead console-screen.service        
● festival.service               not-found inactive dead festival.service              
● kbd.service                    not-found inactive dead kbd.service                   
● live-tools.service             masked    inactive dead live-tools.service            
● plymouth-quit-wait.service     not-found inactive dead plymouth-quit-wait.service    
● plymouth-quit.service          not-found inactive dead plymouth-quit.service         
● plymouth-start.service         not-found inactive dead plymouth-start.service        
● systemd-sysusers.service       not-found inactive dead systemd-sysusers.service      
● systemd-update-done.service    not-found inactive dead systemd-update-done.service   
● systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service
● syslog.target                  not-found inactive dead syslog.target                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

dan:

# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
├─user@132.service
│ ├─pulseaudio.service
│ │ └─739 /usr/bin/pulseaudio --daemonize=no
│ ├─at-spi-dbus-bus.service
│ │ ├─704 /usr/lib/at-spi2-core/at-spi-bus-launcher
│ │ ├─709 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
│ │ └─712 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
│ ├─dbus.service
│ │ └─694 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
│ └─init.scope
│   ├─597 /lib/systemd/systemd --user
│   └─600 (sd-pam)
└─session-c1.scope
  ├─577 gdm-session-worker [pam/gdm-launch-environment]
  ├─613 /usr/lib/gdm3/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
  ├─618 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/132/gdm/Xauthority -background none -noreset -keeptty -verbose 3
  ├─697 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
  ├─721 /usr/bin/gnome-shell
  └─752 /usr/lib/gnome-settings-daemon/gnome-settings-daemon

— not2qubit
sumber

2

Jawaban ini setidaknya memberi kita beberapa informasi tentang bagaimana menemukan apa (dari banyak kemungkinan) yang mungkin menyebabkan masalah pada mesin individual kita. Namun masalah lain adalah bahwa setelah poweroffatau shutdownkita tidak bisa masuk untuk melihat penyebab sebenarnya. systemd perlu mencatat output dari cgls ketika masalah ini terjadi. Yang terbaik yang dapat kita lakukan untuk saat ini adalah menyimpan output dari systemd-cglsdan berkonsultasi nanti jika / ketika hang terjadi lagi.

— duanev

2

Karena ini adalah salah satu hasil pertama di mesin pencari paling ramah yang pernah ada, saya akan menambahkan solusi saya di sini: Saya menggunakan Arch Linux dengan desktop Gnome; kernel saat ini pada hari ini: 4.16.

Saya menerima pesan itu A stop job is running for Session c2 of user ... (1min 30s)setiap kali Remote Logindiaktifkan Settings > Sharing, dan Sharingdiaktifkan.

Setiap kali saya menonaktifkannya, komputer saya akan dimatikan dengan baik menggunakan tombol Gnome shutdown.

Karena "Remote Login" tidak lain adalah SSH, saya berasumsi bahwa jawaban not2qubit juga akan berfungsi, karena menonaktifkan NetworkManager mungkin juga akan menonaktifkan SSH.

— stueja
sumber

1

Terkadang ini bisa disebabkan oleh satu aplikasi. Mengingat perubahan yang dibuat sesaat sebelum mulai terjadi dapat membantu menentukan penyebabnya. Saya memiliki masalah yang sama setelah menginstal skypeforlinux-stable-bindi Arch Linux. Menutup aplikasi itu sebelum mematikan menyelesaikan masalah (saya menulis sebuah skrip untuk melakukan ini secara otomatis sebelum mematikan).

— prosoitos
sumber

0

Saya memiliki masalah ini untuk waktu yang lama, jadi saya pikir saya akan membagikan solusi saya.

Masalahnya adalah bahwa Google Chrome berjalan di latar belakang dan tidak menutup saat mematikan komputer. Jadi solusi terbaik adalah mematikan fitur itu.

Buka pengaturan Google Chrome.
Klik pada "Advanced".
Pergi ke "Sistem".
Nonaktifkan "Lanjutkan menjalankan aplikasi latar belakang ketika Google Chrome ditutup".

Ini menyelesaikannya untuk saya. Semoga ini bisa membantu.

— ArianJM
sumber