Cara Membuat Unit Layanan SystemD di Linux

Meskipun Systemd telah menjadi objek dari banyak kontroversi, sampai -sampai beberapa distribusi diberi garpu hanya untuk menyingkirkannya (lihat Devuan, garpu Debian yang, secara default, menggantikan Systemd dengan sysvinit), pada akhirnya telah menjadi The the Sistem Init Standar De-Facto di dunia Linux.

Dalam tutorial ini kita akan melihat bagaimana layanan SystemD terstruktur, dan kita akan belajar cara membuatnya.

Dalam tutorial ini Anda akan belajar:

• Apa itu unit layanan…
• Apa bagian dari unit layanan.
• Apa opsi paling umum yang dapat digunakan di setiap bagian.
• Apa saja berbagai jenis layanan yang dapat didefinisikan.

Persyaratan dan konvensi perangkat lunak yang digunakan

Sistem init systemd

Semua distribusi utama, seperti Rhel, Centos, Fedora, Ubuntu, Debian dan Archlinux, mengadopsi SystemD sebagai sistem init mereka. Systemd, sebenarnya, lebih dari sekadar sistem init, dan itulah salah satu alasan mengapa beberapa orang sangat menentang desainnya, yang bertentangan dengan moto Unix yang mapan: "Lakukan satu hal dan lakukan dengan baik". Di mana sistem init lain menggunakan skrip shell sederhana untuk mengelola layanan, Systemd menggunakannya sendiri .melayani file (unit dengan .Sufiks Layanan): Dalam tutorial ini kita akan melihat bagaimana mereka terstruktur dan cara membuat dan menginstal satu.

Anatomi unit layanan

Apa itu unit layanan? File dengan .melayani Sufiks berisi informasi tentang proses yang dikelola oleh SystemD. Ini disusun oleh tiga bagian utama:

• [Unit]: Bagian ini berisi informasi yang tidak secara khusus terkait dengan jenis unit, seperti deskripsi layanan
• [Layanan]: Berisi informasi tentang jenis unit tertentu, layanan dalam kasus ini
• [Instal]: Bagian ini berisi informasi tentang pemasangan unit

Mari kita analisis masing -masing secara rinci.

Bagian [unit]

Itu [Satuan] bagian dari a .melayani File berisi deskripsi unit itu sendiri, dan informasi tentang perilakunya dan ketergantungannya: (untuk bekerja dengan benar layanan dapat bergantung pada yang lain). Di sini kita membahas beberapa opsi paling relevan yang dapat digunakan di bagian ini

Opsi "Deskripsi"

Pertama -tama kami memiliki Keterangan pilihan. Dengan menggunakan opsi ini, kami dapat memberikan deskripsi unit. Deskripsi kemudian akan muncul, misalnya, saat memanggil Systemctl perintah, yang mengembalikan ikhtisar status systemd. Ini dia, sebagai contoh, bagaimana deskripsi httpd Layanan didefinisikan pada sistem fedora:

[Unit] Deskripsi = Server Apache HTTP 

Opsi "After"

Dengan menggunakan Setelah Opsi, kami dapat menyatakan bahwa unit kami harus dimulai setelah unit yang kami berikan dalam bentuk daftar yang dipisahkan ruang. Misalnya, mengamati lagi file layanan di mana layanan web Apache didefinisikan, kita dapat melihat yang berikut:

Setelah = jaringan.Target Remote-FS.Target NSS-tampilan.Target httpd-init.melayani

Baris di atas menginstruksikan SystemD untuk memulai unit layanan httpd.melayani hanya setelah jaringan, hapus-fs, NSS-tampilan target dan Layanan HTTPD-Init.

Menentukan dependensi keras dengan "membutuhkan"

Seperti yang kami sebutkan secara singkat di atas, unit (layanan dalam kasus kami) dapat bergantung pada unit lain (tidak harus unit "layanan") untuk bekerja dengan benar: dependensi tersebut dapat dinyatakan dengan menggunakan Memerlukan pilihan.

Jika salah satu unit di mana layanan tergantung gagal untuk memulai, aktivasi layanan itu dihentikan: inilah sebabnya mereka disebut Ketergantungan yang keras. Di baris ini, diekstraksi dari file layanan Avahi-Daemon, kita dapat melihat bagaimana itu dinyatakan sebagai tergantung dari Avahi-Daemon.Unit Soket:

Membutuhkan = avahi-daemon.stopkontak

Mendeklarasikan ketergantungan "lunak" dengan "keinginan"

Kami baru saja melihat cara mendeklarasikan apa yang disebut ketergantungan "keras" untuk layanan dengan menggunakan Memerlukan pilihan; Kami juga dapat mencantumkan dependensi "lunak" dengan menggunakan Keinginan pilihan.

Apa bedanya? Seperti yang kami katakan di atas, jika ada ketergantungan yang "keras" gagal, layanan akan gagal sendiri; Namun, kegagalan ketergantungan "lunak" tidak mempengaruhi apa yang terjadi pada unit dependen. Dalam contoh yang disediakan, kita dapat melihat bagaimana buruh pelabuhan.melayani Unit memiliki ketergantungan lunak pada Docker-storage-setup.melayani satu:

[Unit] Wants = Docker-Storage-Setup.melayani 

Bagian [Layanan]

Dalam [Melayani] bagian dari a melayani unit, kita dapat menentukan hal -hal sebagai perintah yang akan dieksekusi saat layanan dimulai, atau jenis layanan itu sendiri. Mari kita lihat beberapa dari mereka.

Memulai, menghentikan, dan memuat ulang layanan

Layanan dapat dimulai, dihentikan, restart atau dimuat ulang. Perintah yang akan dieksekusi saat melakukan masing -masing tindakan ini dapat ditentukan dengan menggunakan opsi terkait di [Melayani] bagian.

Perintah yang akan dieksekusi saat layanan dimulai, dinyatakan dengan menggunakan EXECSTART pilihan. Argumen yang diteruskan ke opsi juga bisa menjadi jalan menuju skrip. Secara opsional, kami dapat mendeklarasikan perintah untuk dieksekusi sebelum dan sesudah layanan dimulai, dengan menggunakan ExecStartpre Dan EXECSTARTPOST Opsi masing -masing. Berikut adalah perintah yang digunakan untuk memulai layanan NetworkManager:

[Layanan] execStart =/usr/sbin/networkManager ---no-daemon 

Dengan cara yang sama, kita dapat menentukan perintah yang akan dieksekusi ketika layanan dimuat kembali atau dihentikan, dengan menggunakan EXECSTOP Dan Execreload pilihan. Demikian pula dengan apa yang terjadi dengan EXECSTARTPOST, Perintah atau beberapa perintah yang akan diluncurkan setelah proses dihentikan, dapat ditentukan dengan Execstoppost pilihan.

Jenis layanan

SystemD mendefinisikan dan membedakan antara beberapa jenis layanan yang berbeda tergantung pada perilaku yang diharapkan. Jenis layanan dapat ditentukan dengan menggunakan Jenis opsi, memberikan salah satu nilai ini:

• sederhana
• forking
• satu tembakan
• dbus
• memberitahu

Jenis layanan default, jika Jenis Dan BUSNAME Opsi tidak ditentukan, tetapi perintah disediakan melalui EXECSTART opsi, adalah sederhana. Ketika jenis layanan ini diatur, perintah yang dinyatakan dalam EXECSTART dianggap sebagai proses/layanan utama.

Itu forking Jenis bekerja secara berbeda: perintah yang diberikan EXECSTART diharapkan untuk membayar dan meluncurkan proses anak, yang akan menjadi proses/layanan utama. Proses induknya diharapkan mati setelah proses startup selesai.

Itu satu tembakan Jenis digunakan sebagai default jika Jenis Dan EXECSTART Opsi tidak didefinisikan. Itu bekerja sangat seperti sederhana: Perbedaannya adalah prosesnya diharapkan untuk menyelesaikan pekerjaannya sebelum unit lain diluncurkan. Unit, bagaimanapun, masih dianggap sebagai "aktif" bahkan setelah perintah keluar, jika Tetap peraturan Opsi diatur ke "Ya" (standarnya adalah "Tidak").

Jenis layanan berikutnya adalah dbus. Jika jenis layanan ini digunakan, daemon diharapkan mendapatkan nama dari Dbus, sebagaimana ditentukan dalam BUSNAME opsi, yang dalam hal ini, menjadi wajib. Untuk sisanya berfungsi seperti sederhana jenis. Namun, unit konsekuen diluncurkan hanya setelah nama DBUS diperoleh.

Proses lain bekerja serupa dengan sederhana, Dan itu memberitahu: Perbedaannya adalah bahwa daemon diharapkan untuk mengirim pemberitahuan melalui sd_notify fungsi. Hanya setelah pemberitahuan ini dikirim, unit konsekuen diluncurkan.

Atur batas waktu proses

Dengan menggunakan opsi spesifik, dimungkinkan untuk menentukan waktu tunggu untuk layanan ini. Mari kita mulai dengan Restartsec: Dengan menggunakan opsi ini, kita dapat mengatur jumlah waktu (secara default dalam detik) SystemD harus menunggu sebelum memulai kembali layanan. Rpan waktu juga dapat digunakan sebagai nilai untuk opsi ini, sebagai "5 menit 20 -an". Standarnya adalah 100ms.

Itu Timeoutstartsec Dan Timeoutstopsec Opsi dapat digunakan untuk menentukan, masing -masing, batas waktu untuk startup layanan dan berhenti, dalam hitungan detik. Dalam kasus pertama, jika setelah batas waktu yang ditentukan, proses startup daemon tidak selesai, itu akan dianggap gagal.

Dalam kasus kedua, jika suatu layanan akan dihentikan tetapi tidak diakhiri setelah batas waktu yang ditentukan, pertama Sigterm dan kemudian, setelah jumlah waktu yang sama, a Sigkill Sinyal dikirim ke sana. Kedua opsi juga menerima rentang waktu sebagai nilai dan dapat dikonfigurasi sekaligus, dengan jalan pintas: Timeoutsec. Jika ketakterbatasan disediakan sebagai nilai, batas waktu dinonaktifkan.

Akhirnya, kami dapat mengatur batas jumlah waktu yang dapat dijalankan layanan, menggunakan Runimemaxsec. Jika suatu layanan melebihi batas waktu ini, itu diakhiri dan dianggap gagal.

Bagian [instal]

Dalam [Install] Bagian, kami dapat menggunakan opsi yang terkait dengan instalasi layanan. Misalnya, dengan menggunakan Alias Opsi, kami dapat menentukan daftar alias yang terpisah ruang untuk digunakan untuk layanan saat menggunakan perintah SystemCTL (kecuali memungkinkan).

Demikian pula dengan apa yang terjadi dengan Memerlukan Dan Keinginan opsi di [Satuan] bagian, untuk menetapkan dependensi, di [Install] bagian, kita bisa menggunakan Dibutuhkan Dan Dicari. Dalam kedua kasus, kami mendeklarasikan daftar unit yang bergantung pada yang kami konfigurasi: dengan opsi sebelumnya mereka akan bergantung pada hal itu, dengan yang terakhir mereka akan dianggap hanya tergantung pada lemah. Misalnya:

[Install] wantedby = multi-pengguna.target 

Dengan garis di atas kami menyatakan bahwa multi-pengguna Target memiliki ketergantungan lunak pada unit kami. Dalam terminologi SystemD, unit yang diakhiri dengan .target akhiran, dapat dikaitkan dengan apa yang disebut Runtimes dalam sistem init lain sebagai Sysvinit. Dalam kasus kami, maka, target multi-pengguna, ketika dicapai, harus mencakup layanan kami.

Membuat dan Memasang Unit Layanan

Pada dasarnya ada dua tempat di sistem file di mana unit layanan SystemD diinstal: /usr/lib/systemd/system Dan /etc/systemd/system. Jalur sebelumnya digunakan untuk layanan yang disediakan oleh paket yang diinstal, sedangkan yang terakhir dapat digunakan oleh administrator sistem untuk layanannya sendiri yang dapat mengganti yang default.

Mari Buat Contoh Layanan Kustom. Misalkan kami ingin membuat layanan yang menonaktifkan fitur Wake-on-Lan pada antarmuka Ethernet tertentu (ENS5F5 dalam kasus kami) saat dimulai, dan mengaktifkannya kembali saat dihentikan. Kita bisa menggunakan Ethtool Perintah untuk menyelesaikan tugas utama. Beginilah file layanan kami bisa terlihat:

[Unit] Deskripsi = Force Ens5f5 Ethernet Interface ke 100Mbps Membutuhkan = Jaringan.target setelah = jaringan.Target [Layanan] type = oneshot stillAfterexit = ya execStart =/usr/sbin/ethtool -s ens5f5 wol d execstop =/usr/sbin/ethtool -s ens5f5 wol g [install] wantedby = multi -pengguna =.target 

Kami menetapkan deskripsi unit sederhana, dan menyatakan bahwa layanan tergantung pada jaringan.target unit dan harus diluncurkan setelah tercapai. Dalam [Melayani] bagian kami mengatur jenis layanan sebagai satu tembakan, dan menginstruksikan SystemD untuk mempertimbangkan layanan sebagai aktif setelah perintah dieksekusi, menggunakan Tetap peraturan pilihan. Kami juga mendefinisikan perintah yang akan dijalankan saat layanan dimulai dan dihentikan. Akhirnya, di [Install] Bagian Kami pada dasarnya menyatakan bahwa layanan kami harus dimasukkan dalam multi-pengguna target.

Untuk menginstal layanan, kami akan menyalin file ke /etc/systemd/system direktori sebagai Wol.melayani, daripada kita akan memulainya:

$ sudo cp wol.service/etc/systemd/system && sudo systemctl start wol.melayani

Kita dapat memverifikasi layanan aktif, dengan perintah berikut:

$ Systemctl IS-AKTIF WOL.layanan aktif 

Output dari perintah, seperti yang diharapkan, adalah aktif. Sekarang untuk memverifikasi bahwa "bangun di LAN" telah ditetapkan D, Dan sekarang dinonaktifkan, kita bisa menjalankan:

$ sudo ethtool ens5f5 | Grep Wake-on mendukung bangun-on: PG Wake-on: D 

Sekarang, menghentikan layanan harus menghasilkan hasil terbalik, dan mengaktifkan kembali WOL:

$ sudo systemctl stop wol.Layanan && Sudo Ethtool Ens5f5 | Grep Wake-on mendukung Wake-on: PG Wake-on: G 

Kesimpulan

Dalam tutorial ini kami melihat bagaimana file layanan SystemD disusun, apa saja bagiannya, dan beberapa opsi yang dapat digunakan di masing -masing. Kami belajar cara mengatur deskripsi layanan, untuk menentukan ketergantungannya dan untuk menyatakan perintah yang harus dieksekusi saat dimulai, dihentikan atau dimuat ulang.

Karena systemd, suka atau tidak, telah menjadi sistem init standar di dunia linux, penting untuk menjadi akrab dengan cara melakukan sesuatu. Dokumentasi Layanan SystemD Resmi dapat ditemukan di situs web Freedesktop. Anda juga bisa tertarik membaca artikel kami tentang mengelola layanan dengan SystemD.

Tutorial Linux Terkait:

• Hal -hal yang harus diinstal pada ubuntu 20.04
• Hal -hal yang harus dilakukan setelah menginstal ubuntu 20.04 FOSSA FOSSA Linux
• Cara Crash Linux
• Mint 20: Lebih baik dari Ubuntu dan Microsoft Windows?
• Unduh Linux
• Sistem Linux Hung? Cara melarikan diri ke baris perintah dan…
• Hal -hal yang harus dilakukan setelah menginstal ubuntu 22.04 Jammy Jellyfish…
• Pengantar Otomatisasi Linux, Alat dan Teknik
• Perintah Linux: 20 perintah terpenting teratas yang Anda butuhkan untuk…
• Perintah Linux Dasar