Cara mengetahui apakah suatu sistem menggunakan sistem init SysV, Upstart atau Systemd

Proses init selalu diberi PID 1. /proc filesystem menyediakan cara untuk mendapatkan jalur ke executable yang diberi PID.

Dengan kata lain:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/upstart'

Seperti yang Anda lihat, proses init di kotak Ubuntu 14.10 saya adalah Pemula. Ubuntu 15.04 menggunakan systemd, jadi menjalankan perintah itu malah menghasilkan:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/lib/systemd/systemd'

Jika sistem yang Anda gunakan memberikan /sbin/init sebagai hasilnya, maka Anda akan ingin mencoba menyatakan file itu:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/init'
[email protected]:~$ stat /sbin/init
  File: ‘/sbin/init’ -> ‘/lib/systemd/systemd’

Anda juga dapat menjalankannya untuk mengetahui lebih lanjut:

[[email protected] ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.

Anda dapat melihat-lihat sistem untuk menemukan indikator. Salah satu caranya adalah dengan memeriksa keberadaan tiga direktori:

• /usr/lib/systemd memberi tahu Anda bahwa Anda menggunakan sistem berbasis systemd.

• /usr/share/upstart adalah indikator yang cukup bagus bahwa Anda menggunakan sistem berbasis Pemula.

• /etc/init.d memberi tahu Anda bahwa kotak tersebut memiliki SysV init dalam riwayatnya

Masalahnya, ini adalah heuristik yang harus dipertimbangkan bersama, mungkin dengan data lain, bukan indikator tertentu sendiri. Kotak Ubuntu 14.10 yang saya lihat sekarang memiliki ketiga direktori. Mengapa? Karena Ubuntu baru saja beralih ke systemd dari Pemula dalam versi itu, tetapi mempertahankan init Pemula dan SysV untuk kompatibilitas mundur.

Pada akhirnya, menurut saya jawaban terbaik adalah "pengalaman". Anda akan melihat bahwa Anda telah masuk ke kotak CentOS 7 dan mengetahui bahwa itu adalah systemd. Bagaimana Anda mempelajari ini? Bermain-main, RTFMing, dll. Dengan cara yang sama Anda mendapatkan semua pengalaman.

Saya menyadari ini bukan jawaban yang sangat memuaskan, tetapi itulah yang terjadi ketika ada fragmentasi di pasar, menciptakan desain yang tidak standar. Ini seperti menanyakan bagaimana Anda tahu apakah ls menerima -C , atau --color , atau tidak melakukan keluaran warna sama sekali. Sekali lagi, jawabannya adalah "pengalaman".

Ini sebenarnya masalah yang cukup sulit. Salah satu kesulitan utama adalah bahwa tempat di mana seseorang paling sering ingin melakukan ini adalah tempat di mana kemungkinan besar seseorang akan berada di tengah menginstal atau mengubah barang. Lainnya adalah bahwa ada perbedaan yang tidak kentara namun sangat penting antara set alat manajemen sistem yang diinstal , set alat manajemen sistem yang sedang berjalan saat ini , dan set alat manajemen sistem yang akan berjalan pada boot berikutnya .

Menentukan apa yang diinstal dilakukan dengan manajer paket, tentu saja. Tetapi ini diperumit oleh fakta bahwa beberapa sistem dapat dipasang berdampingan.

Pada Debian Linux, misalnya, seseorang dapat menginstal paket systemd, tetapi instalasi paket systemd-sysv yang terpisah membuatnya menjadi sistem yang aktif. Maksudnya agar paket systemd dan sysvinit bisa diinstall secara bersamaan. Memang, kerumunan Debian Linux telah mengambil langkah-langkah di Debian 8 untuk beralih ke setiap program yang memiliki nama berbeda (/lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , dan sebagainya) karena alasan ini, bahwa paket "non-aktivasi" tidak bertentangan dengan nama /sbin/init . /sbin/init kemudian merupakan tautan simbolis ke mana pun yang dikonfigurasi untuk dijalankan pada boot berikutnya dengan "paket pengaktifan".

Menentukan apa yang sedang berjalan sekarang dan siap untuk dijalankan berikutnya hanya dapat dilakukan dengan serangkaian pengujian khusus perangkat, dengan berbagai tingkat risiko dari kesalahan positif, dan dengan berbagai tingkat dokumentasi. Untuk memeriksa apakah manajer sistem sedang berjalan saat ini, khususnya, kita benar-benar harus melihat daftar proses atau berbagai API yang diterbitkan oleh manajer sistem. Tapi ini tidak sepenuhnya tanpa jebakan.

Umum bukan pemula

Mari kita mulai dengan hal-hal yang pasti tidak kerja.

• /proc/1/exe akan menunjuk ke /sbin/init yang sama saat pemula atau Sistem 5 init sedang berjalan sekarang. Dan pada beberapa sistem, itu juga /sbin/init ketika systemd sedang berjalan.

  Kerumunan Debian Linux ingin beralih ke setiap program yang memiliki nama berbeda, seperti yang disebutkan sebelumnya. Tapi ini khusus untuk Debian, jauh dari universal, dan tidak terlalu membantu ketika program dipanggil sebagai /sbin/init (pada fase initramfs dari bootstrap). Hanya minit Felix von Leitner yang dikemas oleh Debian 8 untuk dipanggil dengan namanya sendiri.

• Keberadaan file API kontrol /dev/initctl tidak khusus untuk Sistem 5 init . systemd memiliki (bukan proses #1) systemd-initctl server yang melayani ini. finit dari Joachim Nilsson melayaninya juga. (Hanya untuk membuatnya lebih menyenangkan, di Debian sekarang terletak di /run/initctl . Lihat https://superuser.com/a/888936/38062 untuk detailnya.)
• systemd, pemula, Sistem 5 rc , dan OpenRC semua memproses /etc/init.d/ , untuk kompatibilitas mundur dalam kasus dua yang sebelumnya. Keberadaannya tidak menunjukkan adanya sistem tertentu.

Mendeteksi Sistem 5 init

Ironisnya, seperti yang dijelaskan di https://unix.stackexchange.com/a/196197/5132 , salah satu cara setidaknya di Debian Linux untuk mendeteksi tidak adanya Sistem 5 init adalah tidak adanya /etc/inittab . Namun:

• Ini adalah efek samping dari cara Debian mengemas hal-hal seperti /etc/inittab .
• Salah satu bagian dari keseluruhan masalah adalah /etc/inittab itu bertahan jika Sistem 5 init digunakan pada titik mana pun di masa lalu , karena menguninstall paket tidak menghapus file konfigurasinya. (Ini telah menjadi masalah yang cukup besar untuk pekerjaan Debian 8, karena ada beberapa paket di Debian 7 yang menginstal sendiri dengan menambahkan entri ke /etc/inittab .)
• Ini adalah tes terbalik.

Mendeteksi systemd

Untuk memeriksa systemd sebagai pengelola sistem yang sedang berjalan dengan cara "resmi", seseorang memeriksa keberadaan /run/systemd/system . Ini adalah direktori, di /run , yang dibuat oleh systemd sendiri saat boot, dan yang tidak mungkin dibuat oleh manajer sistem lain.

Tapi itu hanya tidak mungkin . Cek ini sudah rusak , karena tidak berguna membuat direktori ini juga.

Pemeriksaan lain, tidak resmi, tidak akan berfungsi:

• systemd menerbitkan seluruh RPC API melalui D-Bus, yang bahkan berisi nama dan nomor versi; tapi:
  • Hal ini tidak dicakup oleh "Jaminan Stabilitas Antarmuka" yang terkenal buruk dan dapat berubah besok atau sewaktu-waktu.
  • Begitu juga server D-Bus yang mirip di systemd-shim.
  • Begitu juga tidak berguna.
• Keberadaan /run/systemd/private juga tidak dijamin dan juga digandakan oleh tidak berguna.

Mendeteksi nosh

system-manager di nosh membuat /run/system-manager direktori. Tapi ini berbagi kelemahan dari pemeriksaan systemd yang setara.

Non-pemula lebih lanjut:

• Nosh system-manager menurut desain tidak membuat pipa atau soket di sistem file, dan tidak memiliki RPC API sejak awal.
• Nosh service-manager konvensional memiliki soket API di /run/service-manager/control , tetapi seseorang dapat menjalankan nosh service manajer di bawah beberapa manajer sistem lainnya; jadi ini tidak memberi tahu siapa sistem manajer sedang berjalan sebagai proses #1. Bagaimanapun, itu tidak menetapkan nama itu sendiri; apa pun yang dipanggil itu tidak.
• Keberadaan string versi nosh, yang dipancarkan oleh system-control version , systemctl version (jika ada yang menginstal shims kompatibilitas systemd) dan initctl version (jika ada yang menginstal shims kompatibilitas pemula) hanya menunjukkan keberadaan kumpulan alat, karena alat ini tidak membuat kueri dari sistem yang sedang berjalan.

Mendeteksi pemula

initctl milik pemula sendiri melakukan panggilan API melalui D-Bus, dan pemeriksaan resmi adalah untuk memeriksa apakah seseorang dapat menjalankan initctl dan keluarannya berisi string "pemula" di suatu tempat.

Tapi, seperti API systemd:

• Tidak ada jaminan bahwa API akan ada besok atau tidak berubah sewaktu-waktu.
• Tidak ada jaminan bahwa beberapa shim kompatibilitas tidak ada atau tidak akan ada di masa mendatang.

  Memang sudah ada satu kompatibilitas shim. nosh memiliki paket kompatibilitas pemula yang menyediakan shim untuk initctl pemula , start , stop , dan status perintah. Untungnya (meskipun ini disengaja), initctl shim tidak mengeluarkan kata "pemula".

  root ~ #initctl version
  nosh version 1.14
  root ~ #