Sejarah systemd: Mengapa Ia Menjadi Standard Linux

Mengapa systemd menang

Sejarah systemd bermula dengan dua perkara yang tidak dapat dilakukan oleh SysV init. SysV init (System V init, sistem permulaan yang diwarisi Linux daripada AT&T Unix) tidak mempunyai cara untuk menerangkan kebergantungan sesuatu servis, dan tidak mempunyai cara untuk mengetahui proses mana yang tergolong dalam sesuatu servis setelah ia berjalan. systemd menjawab kedua-dua masalah tersebut dengan ciri kernel yang tidak dapat dicapai oleh skrip shell: control groups untuk menjejak proses, dan listening sockets yang dibuka lebih awal untuk penyusunan. Selebihnya adalah kisah bagaimana kedua-dua jawapan tersebut tersebar ke seluruh ruang pengguna (userland), di mana bantahan mula timbul, dan beberapa bantahan tersebut adalah tepat.

Apa yang SysV init sebenarnya lakukan

Pada sistem SysV, PID 1 (process ID 1, proses pertama yang dimulakan oleh kernel) membaca /etc/inittab, memilih runlevel, dan menjalankan skrip untuk runlevel tersebut. Skrip-skrip tersebut terletak di /etc/init.d/. Pautan simbolik (symbolic links) dalam /etc/rc3.d/ menentukan skrip mana yang dijalankan dan dalam urutan apa, jadi /etc/rc3.d/S20nginx menghala ke /etc/init.d/nginx dan dipanggil dengan argumen start.

#!/bin/sh
### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

case "$1" in
  start)
    start-stop-daemon --start --quiet --pidfile /run/nginx.pid \
      --exec /usr/sbin/nginx
    ;;
  stop)
    start-stop-daemon --stop --quiet --retry TERM/30/KILL/5 \
      --pidfile /run/nginx.pid
    ;;
esac

20 dalam S20nginx ialah kedudukan, bukan kebergantungan (dependency). Ia menyatakan bahawa skrip ini dijalankan selepas S19 dan sebelum S21. Ia tidak menyatakan sebabnya, jadi tiada apa yang boleh menyemaknya, dan tiada apa yang boleh menjalankan dua skrip yang tidak berkaitan secara serentak dengan selamat tanpa keputusan manusia bahawa ia adalah selamat.

Program rc menjalankan setiap skrip secara bergilir-gilir dan menunggu sehingga ia tamat. Skrip yang terhenti (block) selama tiga puluh saat sementara menunggu alamat rangkaian akan menyekat keseluruhan proses but selama tiga puluh saat, walaupun untuk servis yang tidak pernah menggunakan rangkaian.

Pengepala LSB (Linux Standard Base) di bahagian atas skrip tersebut merupakan satu percubaan untuk membaiki masalah ini dari dalam. Debian 6.0 pada tahun 2011 menjadikan insserv sebagai lalai: ia membaca Required-Start daripada setiap skrip, membina graf, dan menomborkan semula pautan simbolik tersebut. Debian kemudiannya boleh menjalankan skrip yang bebas secara serentak dengan startpar. Itu membantu, namun ia tidak menyelesaikan masalah yang lebih mendalam. Kebergantungan masih lagi bergantung pada skrip yang tamat. S20nginx yang mengembalikan 0 bermakna fungsi shell telah selesai. Ia tidak bermakna nginx sedang menerima sambungan.

Lima perkara yang tidak dapat diselesaikan oleh skrip init

• Permulaan selari. Penyusunan mengikut nama fail ialah susunan menyeluruh ke atas setiap servis pada mesin, jadi proses but menjadi perlahan mengikut jumlah masa setiap bahagian.
• Kesediaan. Skrip mula keluar apabila ia telah melakukan fork pada daemon, bukan apabila daemon tersebut boleh melayani permintaan, jadi skrip seterusnya sering bermula terlalu awal.
• Penyeliaan. Daemon melakukan fork sebanyak dua kali dan induknya keluar, yang memisahkannya daripada terminal dan menetapkan semula induknya kepada PID 1. init melihat anak proses keluar dan tidak mempunyai pautan yang boleh dipercayai kepada proses yang terus berjalan.
• Permulaan atas permintaan. inetd (pelayan super internet) boleh melancarkan daemon apabila sambungan tiba, tetapi ia merupakan sistem berasingan dengan fail konfigurasinya sendiri, dan ia tidak melakukan apa-apa mengenai penyusunan segala perkara lain semasa but.
• Kawalan sumber. Tiada apa-apa dalam skrip init yang boleh mengehadkan memori servis atau bahagian CPU-nya. ulimit digunakan pada satu proses dan nice hanya menyentuh penjadual, jadi anak proses yang tidak terkawal daripada sesuatu servis kelihatan seperti mana-mana proses lain pada kotak tersebut.

Jurang penyeliaan adalah perkara yang menjejaskan operasi harian. Fail PID merupakan penyelesaian sementara: daemon menulis ID prosesnya ke /run/nginx.pid, dan fungsi henti membaca semula fail tersebut. Jika daemon dimatikan secara paksa, fail tersebut kekal di situ. Kernel kemudian menggunakan semula nombor tersebut untuk perkara lain, dan start-stop-daemon --stop --pidfile menghantar isyarat kepada apa sahaja yang kini memilikinya. Fail PID yang lapuk adalah punca skrip init mematikan proses yang salah.

launchd menyelesaikan masalah soket terlebih dahulu

Apple melancarkan launchd dalam Mac OS X 10.4 pada tahun 2005, yang ditulis oleh Dave Zarzycki. Satu proses menggantikan init, rc, xinetd, crond dan watchdogd.

Idea yang wajar ditiru ialah pengaktifan soket (socket activation). launchd mencipta setiap soket yang mendengar (listening socket) terlebih dahulu, kemudian memulakan daemon. Pelanggan yang menyambung ke daemon yang belum bermula tidak akan menerima ralat connection refused, kerana kernel menahan sambungan tersebut dalam baris gilir backlog soket itu sehingga daemon memanggil accept(). Urutan antara dua daemon tidak lagi perlu ditentukan oleh manusia. Soket itu sendiri yang menguruskannya.

launchd dibina berasaskan Mach IPC (komunikasi antara proses), yang merupakan sebahagian daripada kernel XNU milik Apple dan tidak mempunyai padanan dalam Linux. Memindahkan kod tersebut tidak pernah menjadi sesuatu yang realistik. Walau bagaimanapun, idea tersebut tetap tersebar.

Upstart menjadikan peristiwa sebagai unit kerja

Upstart daripada Canonical, yang ditulis oleh Scott James Remnant, dilancarkan dalam Ubuntu 6.10 pada Oktober 2006. Fedora 9 hingga Fedora 14 menggunakannya, begitu juga RHEL 6 dan Chrome OS. Ia menggantikan runlevel dengan peristiwa, dan sesuatu job menyatakan peristiwa yang perlu memulakan serta menghentikannya.

# /etc/init/example.conf
start on filesystem and net-device-up IFACE!=lo
stop on runlevel [!2345]
respawn
respawn limit 10 5
exec /usr/local/bin/exampled

Dua masalah timbul apabila bilangan job bertambah. Masalah pertama ialah arah. Sesuatu job menyatakan "mulakan saya apabila ini berlaku", jadi pengetahuan tentang perkara yang bergantung pada apa terletak dalam fail yang salah: sesuatu servis mengetahui keperluannya, dan ia tidak boleh mengetahui siapa yang akan memerlukannya pada masa hadapan. Menambah servis sering kali bermakna menyunting job sedia ada supaya ia mengeluarkan peristiwa baharu.

Masalah kedua ialah penjejakan. Upstart menjejaki daemon yang melakukan forking dengan mengira panggilan fork() menggunakan ptrace, yang anda konfigurasikan sebagai expect fork atau expect daemon. Jika anda tersalah meneka bilangan fork, Upstart akan menyelia proses yang telah pun tamat, atau menunggu fork yang sudah pun berlaku. Simptomnya ialah initctl start tergantung tanpa ralat, yang mana fail job tidak memberikan cara untuk anda menjelaskannya.

Upstart juga memerlukan penyumbang untuk menandatangani perjanjian penyumbang Canonical. Itu bukanlah kesalahan kejuruteraan, namun ia membentuk siapa yang bekerja dengannya.

Memikirkan Semula PID 1, April 2010

Pada 30 April 2010, Lennart Poettering menerbitkan satu hantaran bertajuk "Rethinking PID 1". Kay Sievers bekerjasama dengan beliau dalam projek tersebut. Hujah tersebut mempunyai empat bahagian.

• Mulakan dengan lebih sedikit. Banyak servis boleh menunggu sehingga ada sesuatu yang benar-benar memintanya.
• Berhenti mengisytiharkan urutan apabila soket boleh membayangkannya. Buka semua soket dalam satu laluan, kemudian mulakan semuanya serentak.
• Jejaki proses dengan control groups dan bukannya fail PID.
• Terangkan servis dalam fail deklaratif, supaya satu penerangan berfungsi pada setiap pengedaran.

Keluaran pertama menyusul pada tahun tersebut. Fedora 14 menyertakan systemd sebagai pilihan pada November 2010, dan Fedora 15 menjadikannya tetapan lalai pada Mei 2011.

Mengapa cgroups menjadikan penyeliaan lebih boleh harap

cgroup (control group) ialah ciri kernel untuk mengumpulkan proses, yang digabungkan ke dalam Linux 2.6.24 pada tahun 2008. systemd meletakkan setiap servis ke dalam cgroupnya sendiri. Proses anak mewarisi cgroup induknya, dan proses tanpa keistimewaan tidak boleh mengeluarkan dirinya daripada cgroup tersebut. Oleh itu, double forking tidak menyembunyikan apa-apa: PID 1 memegang set proses yang tepat yang tergolong dalam satu unit, pada setiap masa. Menghentikan servis bermakna mematikan segala-galanya dalam cgroup tersebut, yang merupakan tindakan lalai KillMode=control-group.

systemctl status mencetak kumpulan tersebut:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-08-11 09:14:22 UTC; 3min ago
   Main PID: 1042 (nginx)
      Tasks: 3 (limit: 4653)
     Memory: 6.1M (peak: 7.4M)
     CGroup: /system.slice/nginx.service
             ├─1042 "nginx: master process /usr/sbin/nginx"
             ├─1043 "nginx: worker process"
             └─1044 "nginx: worker process"

Blok itu adalah jawapan lengkap kepada masalah fail PID yang lapuk. Tiada fail yang boleh menjadi lapuk, kerana senarai tersebut adalah keadaan kernel.

Pepohon yang sama membawa had, kerana cgroups dibina untuk perakaunan sebelum sesiapa menggunakannya untuk penjejakan. MemoryMax=, CPUQuota= dan TasksMax= masing-masing hanyalah satu baris. Meletakkan had memori dan CPU yang ketat pada servis kini merupakan fail drop-in, manakala pada tahun 2009 ia adalah patch kepada skrip shell yang tidak pernah ditulis oleh sesiapa.

Sebab setiap pengedaran beralih antara tahun 2011 dan 2015

• Fedora 15, Mei 2011.
• openSUSE 12.1, November 2011.
• Mageia 2, Mei 2012.
• Arch Linux, lalai untuk pemasangan baharu mulai Oktober 2012.
• RHEL 7, Jun 2014.
• SLES 12, Oktober 2014.
• Debian 8, April 2015.
• Ubuntu 15.04, April 2015.

Sebab-sebabnya kebanyakannya membosankan, itulah sebabnya peralihan tersebut berlaku dengan pantas.

• Satu fail unit berfungsi pada setiap pengedaran, jadi projek hulu mula membekalkan fail .service dan pengedaran berhenti menyelenggara skrip shell bagi setiap pakej untuk setiap keluaran.
• Penjejakan sesi desktop berpindah ke systemd-logind selepas ConsoleKit berhenti diselenggara sekitar tahun 2012. GNOME memerlukan logind, jadi pengedaran tanpa systemd terpaksa mencari pengganti. Pengganti itu, elogind, ialah logind milik systemd yang diekstrak dan diselenggara secara berasingan.
• udev, pengurus peranti, telah digabungkan ke dalam pepohon sumber systemd pada April 2012. Pengedaran yang membekalkan udev kini menjejaki repositori systemd. Gentoo melakukan fork terhadap eudev sebagai tindak balas.
• Kontena menjadikan penjejakan proses yang boleh dipercayai dan had bagi setiap servis lebih penting, memandangkan kedua-duanya adalah ciri cgroup. Persoalan tentang penyelia mana yang memiliki proses kontena masih relevan apabila anda memastikan Docker Compose stack kembali berjalan selepas but semula.

Keputusan Debian adalah yang paling hangat diperkatakan. Jawatankuasa Teknikal mengundi pada Februari 2014, undian berakhir dengan seri, dan pengerusi, Bdale Garbee, memberikan undi penentu untuk systemd. Ubuntu mengumumkan beberapa hari kemudian bahawa ia akan mengikut Debian dan bukannya meneruskan penggunaan Upstart. Sekumpulan pembangun Debian melakukan fork terhadap pengedaran tersebut sebagai Devuan pada November 2014 dan mengeluarkan Devuan 1.0 pada Mei 2017.

Bantahan yang dinyatakan secara adil

Skop. Satu projek kini mengeluarkan PID 1, daemon log, pengurusan sesi log masuk, pengurus peranti, daemon konfigurasi rangkaian, penyelesai DNS (domain name system), klien NTP (network time protocol), pelari kontena dan pemuat but. Pertahanan biasa, iaitu bahawa ini adalah binari berasingan yang tidak perlu anda pasang, adalah benar tetapi ia tidak menjawab bantahan tersebut. Apabila desktop memerlukan logind, dan logind dikeluarkan daripada pepohon systemd, pilihan itu tidak lagi bebas. Itulah maksud gandingan dalam hujah tersebut, dan ia telah berlaku.

Jurnal binari. journald menulis format binari berindeks dan bukannya teks biasa. Anda mendapat perkara yang tidak pernah diberikan oleh teks: penapisan mengikut unit dan keutamaan, medan berstruktur, serta metadata yang tidak boleh dipalsukan oleh program penghantar, kerana journald merekodkan unit dan cgroup itu sendiri. journalctl -u nginx -p err --since "-1h" menggantikan grep dengan ungkapan nalar tarikh. Kosnya juga nyata. Pada mesin yang tidak mahu but, anda tidak boleh membaca log dengan less daripada shell pemulihan. Anda menghalakan journalctl ke cakera yang dilekapkan sebaliknya:

sudo journalctl --directory /mnt/var/log/journal --boot -1 --priority err

Terdapat perangkap kedua di sini yang memerangkap pengguna sekali. journald menyimpan log dalam /run/log/journal, iaitu memori, melainkan /var/log/journal wujud. Pada kotak yang tidak mempunyainya, journalctl -b -1 tiada apa-apa untuk ditunjukkan selepas but semula, iaitu saat tepat anda memerlukannya. Semak dan betulkan:

journalctl --disk-usage
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

journalctl --disk-usage kini sepatutnya melaporkan jurnal yang diarkibkan di bawah /var/log/journal. Jika anda mahukan teks biasa juga, tetapkan ForwardToSyslog=yes dalam /etc/systemd/journald.conf dan kekalkan rsyslog dipasang.

Kebolehnyahpepijatan but. Apabila unit tergantung, konsol menunjukkan satu baris dan tiada yang lain:

[  *** ] A start job is running for Wait for Network to be Configured (1min 32s / no limit)

Alat untuk pergi lebih jauh memang wujud: systemctl list-jobs semasa ia tersekat, systemd-analyze blame dan systemd-analyze critical-chain selepas itu, dan systemd.log_level=debug pada baris perintah kernel. Versi adil bagi aduan tersebut ialah skrip init boleh dibaca dari atas ke bawah oleh sesiapa sahaja yang tahu sh, manakala unit yang tersekat memerlukan pengetahuan tentang yang mana antara sedozen perintah untuk digunakan. Itu adalah kos yang nyata. Ia dibayar sekali bagi setiap pentadbir, dan ia dibayar oleh ramai pentadbir pada masa yang sama.

Lalai yang berubah untuk semua orang. systemd 230 pada tahun 2016 menukar lalai logind supaya proses pengguna yang tertinggal dimatikan semasa log keluar. Sesi tmux dan screen yang terpisah mati apabila sesi yang memulakannya berakhir. Pengedaran menghantar KillUserProcesses=no dalam /etc/systemd/logind.conf, dan jawapan yang disokong ialah loginctl enable-linger <user>. Satu lalai dalam satu projek mengubah tabiat yang diharapkan oleh berjuta-juta orang, itulah maksud "terlalu banyak userland di satu tempat" dalam praktiknya.

Dependency lalai ialah permukaan keselamatan. Pada Mac 2024, pintu belakang dalam xz-utils menyasarkan sshd pada Debian dan Ubuntu. OpenSSH hulu tidak memautkan libsystemd. Pengedaran tersebut menampalnya supaya sshd boleh melaporkan kesediaan kepada systemd, dan libsystemd menarik liblzma, tempat pintu belakang itu berada. Protokol kesediaan itu sendiri ialah satu datagram yang dihantar ke soket yang dinamakan dalam $NOTIFY_SOCKET, jadi tiada pustaka yang diperlukan untuknya. Respons systemd adalah untuk memuatkan pustaka mampatan dengan dlopen, supaya ia tidak lagi dipautkan secara lalai. Kelas pepijat yang berkaitan menunjukkan bentuk yang sama: pada tahun 2017 nilai User= yang bermula dengan digit dianggap tidak sah dan unit berjalan sebagai root dan bukannya gagal, jadi kesilapan menaip menjadi peningkatan keistimewaan. Versi kemudian enggan memulakan unit tersebut.

Sejarah pada prompt systemctl anda sendiri

Setiap masalah di atas kini menjadi satu arahan dalam fail yang boleh anda baca.

• Boot bersiri menjadi After= dan Wants=, dan systemd-analyze critical-chain menunjukkan perkara yang sebenarnya menahan proses boot anda.
• Ketersediaan (readiness) menjadi Type=notify, di mana servis menulis READY=1 ke $NOTIFY_SOCKET apabila ia sedia untuk beroperasi. Type=forking dengan PIDFile= masih wujud untuk daemon lama, dan ia merupakan jenis yang gagal dengan start operation timed out. Terminating. apabila fail PID tidak pernah muncul.
• Penyeliaan (supervision) menjadi cgroup, jadi Restart=on-failure dengan RestartSec= menggantikan skrip pembungkus (wrapper script), dan StartLimitBurst= menghentikan gelung ranap (crash loop) daripada berjalan selama-lamanya.
• inetd menjadi unit .socket yang terletak bersebelahan dengan unit .service.
• ulimit menjadi MemoryMax=, CPUQuota= dan TasksMax=.
• Baris su - appuser -c dalam skrip init menjadi User=, NoNewPrivileges=yes dan ProtectSystem=strict, jadi menjalankan servis sebagai pengguna tanpa keistimewaan adalah bentuk lalai bagi sesuatu unit dan bukannya kerja tambahan.

[Unit]
Description=Example API
Wants=network-online.target
After=network-online.target postgresql.service
Requires=postgresql.service

[Service]
Type=notify
ExecStart=/usr/local/bin/exampled
Restart=on-failure
RestartSec=2
MemoryMax=512M
CPUQuota=50%
TasksMax=128
User=exampled
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
StateDirectory=exampled

[Install]
WantedBy=multi-user.target

Satu baris dalam fail tersebut adalah kesilapan yang dilakukan oleh semua orang sekurang-kurangnya sekali. Requires=postgresql.service ialah keperluan, bukan aturan: ia menyatakan unit anda akan gagal jika Postgres gagal, dan ia tidak menyatakan untuk memulakan Postgres terlebih dahulu. Tanpa After=postgresql.service, kedua-duanya bermula pada saat yang sama, dan servis anda akan cuba menyambung ke port yang belum lagi mendengar sebarang trafik. Kedua-duanya dipisahkan dengan sengaja, kerana kadangkala anda mahukan satu tanpa yang lain. ProtectSystem=strict melekapkan sistem fail sebagai baca-sahaja (read-only) untuk servis ini, itulah sebabnya StateDirectory= wujud: ia memberikan servis satu laluan boleh tulis di bawah /var/lib.

Tempat paling jelas untuk melihat teknologi tahun 2005 pada pelayan tahun 2026 adalah SSH pada Ubuntu 24.04, yang menyertakan systemd 255 setakat Ogos 2026. ssh.service diaktifkan melalui soket secara lalai: ssh.socket memegang soket pendengar, dan sshd bermula apabila sambungan tiba. Jadi Port 2222 dalam /etc/ssh/sshd_config tidak mempunyai kesan, kerana sshd bukanlah proses yang membuka port tersebut. Perubahan itu perlu dilakukan pada unit soket.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

ListenStream= yang kosong akan mengosongkan nilai yang diwarisi daripada unit pakej. Jika anda meninggalkannya, anda akan mendapat kedua-dua port, kerana systemd menambah pada senarai dan bukannya menggantikannya. Kemudian gunakan dan semak, dengan memastikan sesi SSH kedua sentiasa terbuka sepanjang masa:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -lntp | grep 2222

ss sepatutnya menyenaraikan satu soket pada port 2222 yang dimiliki oleh systemd, bukan oleh sshd. Itulah reka bentuk launchd, dua puluh tahun kemudian, pada VPS anda. Jika anda lebih suka kelakuan lama, sudo systemctl disable --now ssh.socket diikuti oleh sudo systemctl enable --now ssh.service akan memberikan anda sshd yang berjalan lama yang membaca Port daripada konfigurasinya sendiri semula.

Butiran yang anda temui bergantung pada keluaran yang anda jalankan, jadi adalah berbaloi untuk mengetahui perbezaan antara keluaran LTS dan keluaran interim Ubuntu sebelum anda merancang naik taraf. Merentasi lebih daripada satu mesin, fakta bahawa fail unit adalah sama di mana-mana adalah sebab mengurus beberapa pelayan dari satu tempat kini menjadi masalah konfigurasi dan bukannya masalah skrip shell. Dan apabila anda menulis unit anda sendiri, pasangan servis dan pemasa (timer) melakukan tugas yang sepatutnya anda bahagikan antara skrip init dan baris cron pada tahun 2009.

FAQ

Mengapakah pengedaran Linux menggantikan SysV init dengan systemd?

Atas dua sebab kejuruteraan dan satu sebab penyelenggaraan. SysV init menyusun servis mengikut nama fail, yang merupakan kedudukan dan bukannya kebergantungan, dan ia kehilangan jejak mana-mana daemon yang bercabang (fork) daripada induknya, itulah sebabnya fail PID yang lapuk boleh mematikan proses yang salah. systemd menyelesaikan penyusunan dengan pengaktifan soket dan arahan kebergantungan, serta menyelesaikan penjejakan dengan control groups. Sebab penyelenggaraan menentukan kelajuan: satu fail unit berfungsi pada setiap pengedaran, jadi projek hulu (upstream) menghantar fail .service dan penyelenggara pengedaran berhenti menulis skrip shell bagi setiap pakej. Fedora 15 bertukar pada Mei 2011 dan Ubuntu 15.04 merupakan pengedaran besar terakhir yang bertahan, pada April 2015.

Adakah systemd satu binari gergasi?

Tidak. Pepohon sumber membina banyak program yang berasingan. PID 1 ialah /usr/lib/systemd/systemd, manakala journald, logind dan udevd adalah proses berasingan dengan binari tersendiri; jalankan ls /usr/lib/systemd/ untuk melihatnya pada mesin anda sendiri. Kritikan yang masih wujud adalah mengenai gandingan keluaran dan bukannya saiz binari: program-program ini dikeluarkan bersama dan berkongsi antara muka peribadi, jadi pengedaran cenderung mengambilnya sebagai satu set, dan perisian seperti GNOME mula menjangkakan logind secara khusus.

Bolehkah saya masih menjalankan Linux tanpa systemd?

Boleh. Devuan menghantar sysvinit, Gentoo menggunakan OpenRC sebagai lalai, Void menggunakan runit, Alpine menggunakan busybox init dengan OpenRC, dan Slackware mengekalkan skrip gaya BSD. Kosnya ialah kerja keserasian. Perisian desktop yang menjangkakan logind memerlukan elogind, iaitu logind milik systemd yang diselenggara sebagai pakej kendiri, dan semakin banyak perisian pelayan kini hanya menghantar fail .service, jadi anda perlu menulis dan menyelenggara skrip permulaan sendiri.

Mengapakah jurnal berbentuk binari dan bukannya fail teks biasa?

Kerana journald menyimpan medan berstruktur dengan indeks, yang memberikan penapisan per-unit, penapisan keutamaan, dan metadata yang tidak boleh dipalsukan oleh program penghantar: journald merekodkan unit, cgroup dan UID sebenar itu sendiri dan bukannya mempercayai baris log tersebut. Harganya ialah anda memerlukan journalctl untuk membacanya, termasuk daripada sistem pemulihan, di mana anda menghalakannya ke cakera yang dilekapkan dengan journalctl --directory /mnt/var/log/journal. Jika anda mahukan teks juga, tetapkan ForwardToSyslog=yes dalam /etc/systemd/journald.conf.

Apakah yang menggantikan penyuntingan skrip /etc/init.d saya?

Fail drop-in. Jangan sunting unit dalam /usr/lib/systemd/system/, kerana naik taraf pakej akan menulis ganti fail tersebut. Jalankan sudo systemctl edit nginx.service dan systemd akan mencipta /etc/systemd/system/nginx.service.d/override.conf, yang digabungkan ke atas unit yang dipakejkan. systemctl cat nginx.service menunjukkan hasil gabungan, dan systemd-delta menyenaraikan setiap penggantian (override) pada mesin tersebut. Selepas sebarang suntingan dibuat secara manual, jalankan sudo systemctl daemon-reload, atau arahan seterusnya akan mencetak Warning: The unit file, source configuration file or drop-ins of nginx.service changed on disk.