Bagaimana cara Memulai Layanan secara Otomatis saat Boot di RHEL / CentOS 7?

Ingin tahu bagaimana mengelola layanan di latar belakang atau saat boot?


Mekanisme untuk mengelola dan memulai proses saat boot telah diubah. Sampai RHEL / CentOS 6.x, Anda akan membuat skrip di /etc/init.d/ dan diaktifkan dengan bantuan chkconfig tetapi ada banyak hal yang berbeda pada RHEL 7.

Ini diganti oleh systemd dan karena itu kurang lebih adalah manajer proses default pada versi Linux utama, System Admin berpengalaman dalam rasa lain akan merasa seperti di rumah. Dalam artikel ini, kita akan mengeksplorasi apa itu systemd, apa alasan untuk beralih itu, dan bagaimana menggunakan systemd untuk mengatur, menjalankan dan mengelola proses latar belakang dengan itu.

Apa itu systemd??

Karena setiap proses di Linux terlihat transparan, mari kita lihat di mana systemd bersembunyi. Di sistem saya, saya mendapatkan yang berikut:

~ $ ps -ef | grep systemd
root 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd –system –deserialize 22
pesan + 768 1 0 Nov11? 00:05:46 / usr / bin / dbus-daemon –system –address = systemd: –nofork –nopidfile –systemd-aktivasi –syslog-only
root 805 1 0 Nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 Nov11? 00:00:00 / lib / systemd / systemd –user
ankush 1176 1132 0 Nov11? 00:04:50 / usr / bin / dbus-daemon –session –address = systemd: –nofork –nopidfile –systemd-aktivasi –syslog-only
ankush 9772 20029 0 21:11 poin / 6 00:00:00 grep –color = auto systemd
systemd + 17298 1 0 Nov19? 00:00:12 / lib / systemd / systemd-diselesaikan
systemd + 17303 1 0 Nov19? 00:00:00 / lib / systemd / systemd-timesyncd
root 17307 1 0 Nov19? 00:00:02 / lib / systemd / systemd-journald
root 18182 1 0 Nov19? 00:00:00 / lib / systemd / systemd-udevd

Saya yakin Anda langsung memperhatikannya. proses pertama dalam daftar diluncurkan sebagai root pengguna, dan memiliki pid 1.

Benar saja, ini adalah proses pertama yang diluncurkan sistem saat boot. Katakan halo kepada systemd. ��

Jadi, secara sederhana, systemd adalah proses “ibu” yang meluncurkan, mengelola, dan mengakhiri proses lain dalam sistem, selain memberikan info tentang pencatatan, status sistem file, dll..

Catatan tentang namanya. Namanya memang systemd dan bukan Sistem D atau apa pun. “D” adalah singkatan dari daemon, proses Linux standar yang bekerja (bersembunyi?) Di latar belakang dan tidak melekat pada sesi terminal apa pun.

Mengapa RHEL beralih ke systemd?

Seperti yang telah kita bahas, systemd adalah manajer sistem dan proses, dan dalam RHEL 7, menggantikan program pemula yang terkenal. Mengapa RHEL (Oracle?) Mengambil keputusan ini? Nah, ada alasan yang sangat bagus untuk ini, jadi mari kita lihat sebentar.

Inisialisasi layanan paralel

Tidak menyukai program init SysV, systemd mampu meluncurkan layanan secara paralel. Program init, sebaliknya, meluncurkan mereka satu per satu. Di era di mana bahkan perangkat seluler memiliki CPU multi-core, kurangnya inisialisasi paralel adalah kegagalan besar.

Manajemen layanan dinamis (panas)

Jika Anda perhatikan bahwa drive USB perlu dipasang secara eksplisit pada sistem Fedora sebelumnya sementara mereka akan terbuka secara otomatis di Ubuntu dan distribusi serupa, alasannya adalah systemd. Itu dapat mendeteksi perubahan langsung dalam perangkat keras dan menghentikan / meluncurkan layanan sesuai kebutuhan. Beberapa orang dapat berargumen bahwa itu tidak perlu, tetapi bagi banyak orang, segala sesuatu yang mengurangi beban kognitif sangat disambut.

Peluncuran layanan yang ditangguhkan

systemd mempersingkat waktu booting karena dapat menunda peluncuran layanan saat dibutuhkan. Contoh sederhana adalah layanan terkait sistem file jaringan. Jika tidak ada disk jaringan yang tersedia, tidak masuk akal untuk menjalankan dan menjalankan layanan.

Komunikasi proses yang lebih cepat

Kemampuan paralel dari systemd dibawa ke komunikasi antar-proses. systemd mampu menawarkan akses paralel ke soket dan bus sistem, secara signifikan mengurangi waktu tunggu proses untuk sumber daya komunikasi.

Mulai ulang otomatis

Jika layanan macet, systemd dapat mendeteksi itu dan mencoba untuk memulai kembali. Sebagian besar waktu, restart sederhana adalah semua yang diperlukan untuk aplikasi untuk mulai berfungsi lagi, kecuali ada masalah yang lebih mendasar.

Bagaimanapun, systemd membuat kehidupan sysadmin lebih mudah di sini.

systemd di RHEL7 – Perubahan apa untuk Sysadmin?

Jika Anda memiliki perasaan yang mengganggu bahwa systemd tidak akan menjadi lonceng dan peluit, Anda benar. Ada beberapa ketidakcocokan yang signifikan yang dapat mengejutkan RHEL sysadmin. Mari kita lihat sebentar.

Dukungan runlevel terbatas

systemd memiliki pengakuan dan dukungan yang cukup buruk untuk runlevel. Tidak semua runlevel didukung, dan untuk beberapa target mungkin bahkan tidak ada. Dalam kasus seperti itu, systemd mengembalikan “N” sebagai respons terhadap perintah runlevel, menandakan bahwa ia tidak memiliki runlevel yang sesuai dengan target ini. Secara keseluruhan, Red Hat menyarankan kita untuk tidak menggunakan (!) Perintah runlevel.

Tidak ada perintah khusus

Yang ini akan terasa sakit. Satu kelebihan besar dengan SysV adalah kemampuan untuk mendefinisikan perintah khusus untuk menyediakan fungsionalitas yang lebih baik untuk mengelola proses. Dengan systemd, tidak ada opsi seperti itu dan Anda terjebak dengan start, stop, status, restart, dll.

Khusus keluarga dan non-interaktif

systemd (tentu saja) melacak proses yang telah diluncurkan dan menyimpan PID mereka. Namun, tantangannya adalah bahwa systemd tidak dapat menangani proses yang tidak diluncurkan olehnya. Lebih lanjut, itu tidak mungkin bagi pengguna untuk berinteraksi dengan proses yang dimulai oleh systemd. Semua output menuju / dev / null, secara efektif menghentikan semua harapan yang mungkin Anda miliki untuk mendapatkan output.

Tidak ada konteks

Tidak seperti layanan init, yang diluncurkan oleh systemd tidak mewarisi lingkungan apa pun dari pengguna di sistem. Dengan kata lain, informasi seperti PATH dan variabel sistem lainnya tidak tersedia, dan setiap proses baru diluncurkan dalam konteks kosong.

Jika daftar batasan ini membuat Anda menangis, sekali lagi, Anda tidak sendirian. systemd telah menjadi kekuatan polarisasi di dunia Linux, dan Googling pada “systemd sucks” akan menggali banyak bahan bacaan. ��

Cara Memulai Layanan Secara Otomatis Saat Turun?

Berikut ini adalah kasus penggunaan yang cukup umum dalam penerapan. Kita perlu mengubah program dalam bahasa yang tidak memiliki proses yang berjalan lama: PHP! Mari kita asumsikan saya menulis skrip PHP untuk menangani koneksi websocket yang masuk (setelah semua, kami membangun aplikasi obrolan!) Dan skrip ditempatkan di /home/ankush/chat_server/index.php.

Karena koneksi websocket dapat menekan server kapan saja, proses ini harus selalu aktif dan memonitor koneksi yang masuk. Kami tidak dapat memiliki siklus hidup PHP tradisional di sini karena WebSockets adalah koneksi stateful, dan jika script mati, koneksi adalah daftar. Lagi pula, cukup di soket web; mari kita lihat bagaimana kita akan melakukan daemonisasi skrip ini melalui systemd.

Semua layanan systemd berada di / etc / systemd / system, jadi mari kita buat file di sana untuk menggambarkan skrip server websocket kami. Dengan asumsi Anda masuk sebagai pengguna root.

# vi /etc/systemd/system/chat_server.service

dan kemudian dibutuhkan hal-hal berikut.

[Satuan]
Deskripsi = Layanan Server Obrolan
Setelah = network.target

[Layanan]
Ketik = sederhana
Pengguna = ankush
ExecStart = php /home/ankush/chat_server/index.php
Mulai ulang = batal

[Install]
WantedBy = multi-user.target

Simpan file dan langkah selanjutnya adalah memuat ulang daemon systemd

# systemctl daemon-reload

dan untuk memulai layanan yang baru saja kita buat:

# systemctl mulai chat_server

Jika Anda tidak melihat kesalahan, itu dia!

Mari kita juga cepat melihat apa arti berbagai arahan dalam file:

  • Bagian [Unit] mendefinisikan unit layanan baru untuk systemd. Dalam bahasa systemd, semua layanan dikenal sebagai unit layanan.
  • Direktif Setelah (dapat diprediksi) memberi tahu systemd untuk meluncurkan layanan ini hanya setelah layanan jaringan diluncurkan (jika tidak, siapa yang akan melakukan penanganan koneksi soket level rendah ?!).
  • Type = simple memberitahu systemd bahwa layanan ini tidak seharusnya memotong sendiri. Dengan kata lain, hanya satu instance akan berjalan setiap saat.
  • User = ankush berarti layanan ini akan berjalan sebagai pengguna “ankush”. Kami dapat mengubah ini menjadi “root”, tetapi sangat tidak direkomendasikan dari perspektif keamanan.
  • ExecStart, seperti yang Anda tahu, adalah perintah sebenarnya untuk dijalankan.
  • Restart = on-abort berarti bahwa layanan harus dimulai ulang ketika dibatalkan. Di PHP, proses yang lama berjalan membocorkan memori dan akhirnya meledak, jadi ini diperlukan.
  • The WantedBy = directive memberitahu systemd target mana (pikirkan grup) yang menjadi bagian dari layanan ini. Ini menghasilkan tautan simbolik yang dibuat di dalam target itu untuk menunjuk ke layanan.

Secara umum, ini cukup untuk menjalankan proses latar belakang menggunakan systemd di RHEL 7.

Lebih banyak opsi untuk Restart logic

Dalam contoh di atas, saya telah mengkonfigurasi Restart = on-abort tetapi itu bukan satu-satunya pilihan. Ada lebih banyak dan pilih berdasarkan kebutuhan.

  • pada kegagalan – akan dimulai ulang ketika kode keluar atau sinyal najis
  • selalu – restart ketika ditemukan turun, sinyal bersih atau tidak bersih
  • pada-abnormal – sinyal tidak bersih, anjing penjaga atau batas waktu
  • sukses – hanya ketika dihentikan oleh sinyal bersih atau kode keluar

Mengkonfigurasi Layanan untuk Mulai saat Boot

Setelah Anda puas dengan skrip dan memastikannya berfungsi, selanjutnya Anda ingin mengonfigurasinya sehingga memicu saat boot dan mulai.

Buka / etc / systemd / system dan jalankan perintah enable di bawah ini (jangan lupa untuk mengubah nama file .service dengan yang Anda miliki)

# systemctl aktifkan chat_server.service

Anda akan melihat konfirmasi bahwa itu telah menciptakan symlink.

Dibuat symlink dari /etc/systemd/system/multi-user.target.wants/chat_server.service ke /etc/systemd/system/chat_server.service.

Mulai ulang server Anda dan Anda akan melihat layanan dimulai pada saat boot.

Itu mudah! Bukan begitu?

Tolong! Saya berinvestasi besar-besaran di Pemula. ��

Saya mengerti Anda mempercayai saya, kasus Anda adalah norma dan bukan pengecualian. RHEL telah menggunakan Upstart begitu lama sehingga switch hampir terasa seperti pengkhianatan. Tapi hei, sistem terus berubah, dan kita tidak boleh bertengkar soal hal sepele. Red Hat mengakui bahwa banyak orang yang terjebak dengan versi yang lebih lama, dan telah membuat panduan migrasi Anda pasti harus merujuk.

Satu rahmat yang menyelamatkan dalam semua ini adalah bahwa systemd kompatibel dengan skrip init SysV, jadi untuk sebagian besar, Anda hanya perlu memindahkan file Anda dan menjalankan layanan yang sama.

Tertarik untuk mempelajari lebih lanjut tentang Administrasi Linux dan Pemecahan Masalah? Lihat ini kursus online.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map