Apa sebenarnya "pekerjaan berhenti", seperti dalam "Pekerjaan berhenti sedang berjalan ..."?

Setelah perintah shutdown dikeluarkan, terkadang seseorang mendapat pesan status seperti ini:

A stop job is running for Session 1 of user xy

dan kemudian sistem hang untuk sementara, atau selamanya tergantung pada ???

Jadi apa sebenarnya "pekerjaan yang berhenti"?

Juga, mengapa kadang-kadang memperkirakan waktu yang dibutuhkan, cukup akurat, dan lain kali bisa berjalan selamanya?

systemd beroperasi secara internal dalam hal antrian "pekerjaan". Setiap pekerjaan (menyederhanakan sedikit) adalah tindakan yang harus diambil: berhenti, periksa, mulai, atau mulai ulang unit tertentu .

Ketika (misalnya) Anda menginstruksikan systemd untuk memulai unit layanan , ia bekerja keluar daftar berhenti dan memulai pekerjaan untuk unit apa pun (unit layanan, unit mount, unit perangkat, dan sebagainya) diperlukan untuk mencapai tujuan itu, menurut persyaratan dan ketergantungan unit, memerintahkannya, sesuai dengan hubungan pemesanan unit, berhasil dan (jika mungkin) memperbaiki kontradiksi diri sendiri, dan (jika langkah terakhir berhasil) menempatkan mereka dalam antrian.

Kemudian ia mencoba untuk melakukan "pekerjaan" yang telah diuraikan.

Pekerjaan berhenti sedang berjalan untuk Sesi 1 pengguna xy

Nama tampilan unit di sini adalah Session 1 of user xy. Ini akan menjadi (dari nama tampilan) unit sesi , bukan unit layanan . Ini adalah abstraksi sesi ruang-pengguna yang dikelola oleh logindprogram systemd dan plugin PAM-nya. Ini adalah (pada intinya dan dalam teori) pengelompokan semua proses yang dijalankan pengguna sebagai "sesi masuk" di suatu tempat.

Pekerjaan yang telah ditolak itu adalah stop. Dan mungkin butuh waktu lama karena orang-orang systemd telah keliru menyatukan hangup sesi dengan shutdown sesi . Mereka mematahkan yang pertama untuk membuat yang kedua bekerja, dan sebagai tanggapan beberapa orang mengubah sistem dan mematahkan yang kedua untuk membuat yang kedua bekerja. Orang-orang systemd benar-benar harus mengenali bahwa mereka adalah dua hal yang berbeda.

Di sesi login Anda, Anda memiliki sesuatu yang mengabaikan SIGTERMatau yang membutuhkan waktu lama untuk dihentikan setelah dilihat SIGTERM. Ironisnya, yang pertama adalah perilaku lama beberapa cangkang kontrol pekerjaan. Cara yang benar untuk mengakhiri pemimpin sesi login ketika mereka adalah shell kontrol pekerjaan khusus ini adalah untuk memberitahu mereka bahwa sesi telah ditutup , dimana mereka mengakhiri semua pekerjaan mereka (jenis pekerjaan yang berbeda dengan pekerjaan systemd internal) dan kemudian mengakhiri diri mereka sendiri.

Apa yang sebenarnya terjadi adalah systemd sedang menunggu batas waktu unit berhenti sampai ia mau SIGKILL. Batas waktu ini dapat dikonfigurasi per unit, tentu saja, dan dapat diatur agar tidak pernah habis. Karenanya mengapa seseorang berpotensi dapat melihat perilaku yang berbeda.

Bacaan lebih lanjut

• Lennart Poettering (2015). systemd . halaman manual systemd. Freedesktop.org.
• Jonathan de Boyne Pollard (2016-06-01). systemd membunuh proses latar belakang setelah pengguna logout . 825394. Pelacak bug Debian.
• Lennart Poettering (2015). systemd.kill . halaman manual systemd. Freedesktop.org.
• Lennart Poettering (2015). systemd.service . halaman manual systemd. Freedesktop.org.
• Mengapa bash mengabaikan SIGTERM?
• /superuser/1102242/

Pesan-pesan ini dari systemd, yang merupakan sistem init yang memulai dan menghentikan pekerjaan. Pekerjaan dapat berupa daemon, tetapi juga dapat melakukan tugas-tugas kecil seperti memasang dan melepas disk, menghapus / tmp, atau menyimpan dan mengembalikan kecerahan layar di seluruh booting. systemctl list-unitsmemberi Anda ide. Systemd menggunakan "unit" dan "pekerjaan" untuk mengartikan hal yang sama.

Ketika suatu pekerjaan dihentikan, seperti halnya systemctl stop ..., maka pertanyaannya adalah berapa lama untuk menunggu pekerjaan selesai sebelum menyatakan kegagalan dan membunuh proses pekerjaan dengan SIGKILLsinyal. Kami benar-benar tidak ingin menggunakan SIGKILLkecuali kami harus, karena itu tidak memberikan kesempatan bagi proses untuk keluar dengan bersih. Untuk beberapa proses beberapa detik mungkin cukup waktu untuk menyatakan kegagalan, untuk proses lain seperti database mungkin ada jaringan dan disk I / O yang besar agar pekerjaan berhenti dengan bersih, dan oleh karena itu kami mungkin memberikan unit-unit itu beberapa menit untuk dimatikan dengan bersih. .

Apa yang Anda lihat pada saat shutdown adalah sama dengan systemctl stop $UNIT_NAMEyang membutuhkan waktu untuk berjalan. Ada penghitung yang menunjukkan detik berlalu dan waktu tunggu maksimum sebelum SIGKILL akan dikeluarkan dan proses shutdown tetap berjalan.

Kecuali ada alasan bagus untuk mengharapkan penundaan yang lama, ini biasanya mengindikasikan semacam kegagalan fungsi. Itu mungkin berkisar dari server DHCP yang tidak menanggapi Rilis dan dengan demikian tindakan Rilis perlu waktu habis, atau beberapa kesalahan yang menyebabkan daemon tidak pernah keluar.

Beberapa layanan macet dan systemd menunggu untuk keluar. Systemd mungkin tidak memperkirakan secara akurat waktu yang diperlukan, waktu (biasanya 90 detik) adalah berapa lama systemd akan menunggu sebelum kehabisan kesabaran. Lihat posting ini:

Pekerjaan berhenti sedang berjalan untuk Sesi c2 pengguna

"Hentikan pekerjaan" adalah ketika systemdsedang menunggu "pekerjaan" tertentu berhenti, misalnya beberapa proses yang sedang menunggu untuk diselesaikan sebelum melanjutkan. Jika Anda melihat pesan peringatan bahwa "stop job sedang berjalan ..." (dll) secara teknis berarti ada sesuatu yang menunggu dalam antrian pekerjaan.

Namun, sebelum menggali seluruh antrian pekerjaan sistem Anda, ingatlah bahwa kadang-kadang pesan peringatan ini merupakan akibat tidak langsung dari faktor lingkungan (bahkan, pesan tersebut bahkan dirujuk pada repo GitHub mereka sebagai kemungkinan bug).

Sebagai contoh: kami menerima pesan terkait "berhenti bekerja" dan tidak dapat mengetahui mengapa .... ternyata, disk hampir kehabisan ruang, dan mulai membuat OS berperilaku aneh.

Memutakhirkan server ke disk yang lebih besar dan mem-boot ulang memperbaikinya;)