Sejarah systemd dan Alasan Systemd Memenangkan Linux

Mengapa systemd menang

Sejarah systemd dimulai dari dua hal yang tidak dapat dilakukan SysV init. SysV init (System V init, sistem startup yang diwarisi Linux dari AT&T Unix) tidak memiliki cara untuk menjelaskan dependensi sebuah service dan tidak memiliki cara untuk mengetahui proses mana yang termasuk dalam sebuah service setelah service tersebut berjalan. systemd menjawab kedua kebutuhan itu dengan fitur kernel yang tidak dapat dijangkau oleh skrip shell: control group untuk melacak proses dan socket listening yang telah dibuka sebelumnya untuk mengatur urutan startup. Selebihnya, kisah ini menjelaskan bagaimana kedua solusi tersebut meluas ke bagian lain dari userland. Di sinilah berbagai keberatan mulai muncul, dan beberapa di antaranya memang beralasan.

Yang sebenarnya dilakukan SysV init

Pada sistem SysV, PID 1 (ID proses 1, proses pertama yang dijalankan kernel) membaca /etc/inittab, memilih runlevel, lalu menjalankan skrip untuk runlevel tersebut. Skrip-skrip itu berada di /etc/init.d/. Symlink di /etc/rc3.d/ menentukan skrip mana yang dijalankan dan urutannya. Karena itu, /etc/rc3.d/S20nginx menunjuk 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 di S20nginx adalah posisi, bukan dependensi. Artinya, skrip ini berjalan setelah S19 dan sebelum S21. Informasi ini tidak menjelaskan alasannya. Karena itu, sistem tidak dapat memeriksanya dan tidak dapat dengan aman menjalankan dua skrip yang tidak berkaitan secara bersamaan tanpa keputusan manusia bahwa hal tersebut aman.

Program rc menjalankan setiap skrip secara berurutan dan menunggu skrip tersebut selesai. Skrip yang terhenti selama tiga puluh detik karena menunggu alamat jaringan akan menunda seluruh proses boot selama tiga puluh detik, termasuk service yang tidak pernah menggunakan jaringan.

Header LSB (Linux Standard Base) di bagian atas skrip tersebut merupakan upaya untuk memperbaiki masalah ini dari dalam. Debian 6.0 pada 2011 menjadikan insserv sebagai default. Program itu membaca Required-Start dari setiap skrip, membangun graf, lalu memberi nomor ulang pada symlink. Debian kemudian dapat menjalankan skrip yang independen secara bersamaan dengan startpar. Langkah ini membantu, tetapi tidak menyelesaikan masalah yang lebih mendasar. Dependensi masih bergantung pada selesainya skrip. S20nginx yang mengembalikan 0 berarti sebuah fungsi shell telah selesai. Itu tidak berarti nginx sudah menerima koneksi.

Lima hal yang tidak dapat diperbaiki oleh init script

• Startup paralel. Pengurutan berdasarkan nama file menghasilkan urutan total untuk setiap service pada mesin, sehingga waktu boot sama dengan jumlah waktu semua prosesnya.
• Kesiapan. Start script selesai ketika sudah melakukan fork terhadap daemon, bukan ketika daemon sudah dapat melayani request. Akibatnya, script berikutnya sering berjalan terlalu cepat.
• Supervisi. Daemon melakukan fork dua kali, lalu proses induknya keluar. Tindakan ini melepaskan daemon dari terminal dan membuatnya diadopsi kembali oleh PID 1. init melihat proses anak keluar, tetapi tidak memiliki hubungan yang andal dengan proses yang masih berjalan.
• Startup sesuai permintaan. inetd (internet super-server) dapat menjalankan daemon ketika koneksi masuk, tetapi sistem ini terpisah dan memiliki file konfigurasinya sendiri. Sistem ini juga tidak menangani pengurutan semua proses lain saat boot.
• Kontrol resource. Tidak ada bagian dalam init script yang dapat membatasi memori service atau jatah CPU-nya. ulimit hanya berlaku untuk satu proses, sedangkan nice hanya memengaruhi scheduler. Karena itu, proses anak service yang tidak terkendali terlihat seperti proses lain pada mesin.

Kesenjangan dalam supervisi adalah masalah yang paling terasa dalam penggunaan sehari-hari. File PID menjadi solusinya: daemon menulis ID prosesnya ke /run/nginx.pid, lalu fungsi stop membaca kembali file tersebut. Jika daemon dihentikan secara paksa, file itu tetap ada. Kernel kemudian menggunakan kembali nomor tersebut untuk proses lain, dan start-stop-daemon --stop --pidfile mengirimkan sinyal ke proses apa pun yang saat itu memiliki nomor tersebut. File PID yang usang dapat menyebabkan init script menghentikan proses yang salah.

launchd lebih dahulu menyelesaikan masalah socket

Apple merilis launchd di Mac OS X 10.4 pada 2005. Perangkat lunak ini ditulis oleh Dave Zarzycki. Satu proses menggantikan init, rc, xinetd, crond, dan watchdogd.

Gagasan yang layak ditiru adalah aktivasi socket. launchd membuat setiap socket yang listening terlebih dahulu, lalu menjalankan daemon. Klien yang terhubung ke daemon yang belum berjalan tidak langsung menerima penolakan koneksi, karena kernel menahan koneksi tersebut dalam antrean backlog socket sampai daemon memanggil accept(). Urutan antara dua daemon tidak lagi perlu ditentukan oleh administrator. Socket yang menanganinya.

launchd dibangun di atas Mach IPC (inter-process communication), yang merupakan bagian dari kernel XNU milik Apple dan tidak memiliki padanan di Linux. Memindahkan kode tersebut ke platform lain tidak pernah realistis. Namun, gagasannya tetap diadopsi.

Upstart menjadikan event sebagai unit kerja

Upstart dari Canonical, yang ditulis oleh Scott James Remnant, dirilis dalam Ubuntu 6.10 pada Oktober 2006. Fedora 9 hingga Fedora 14 menggunakannya, begitu pula RHEL 6 dan Chrome OS. Upstart menggantikan runlevel dengan event. Job menentukan event yang harus memulai dan 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 muncul ketika jumlah job bertambah. Masalah pertama adalah arah dependensi. Job menyatakan, "mulai saya ketika hal ini terjadi". Akibatnya, informasi tentang dependensi berada di file yang keliru. Service mengetahui hal yang dibutuhkannya, tetapi tidak dapat mengetahui siapa yang akan membutuhkannya tahun depan. Menambahkan service sering kali berarti mengedit job yang sudah ada agar job tersebut memancarkan event baru.

Masalah kedua adalah pelacakan proses. Upstart melacak daemon yang melakukan fork dengan menghitung pemanggilan fork() menggunakan ptrace. Anda mengonfigurasinya sebagai expect fork atau expect daemon. Jika jumlah fork diperkirakan secara keliru, Upstart akan mengawasi proses yang sudah berhenti atau menunggu fork yang sudah terjadi. Gejalanya adalah initctl start yang macet tanpa error. File job tidak menyediakan cara untuk menjelaskan kondisi tersebut.

Upstart juga mengharuskan kontributor menandatangani perjanjian kontributor Canonical. Hal itu bukan kesalahan teknis, tetapi memang memengaruhi pihak yang mengerjakannya.

Memikirkan Kembali PID 1, April 2010

Pada 30 April 2010, Lennart Poettering menerbitkan tulisan berjudul "Memikirkan Kembali PID 1". Kay Sievers mengerjakan proyek tersebut bersamanya. Argumennya terdiri dari empat bagian.

• Kurangi proses start. Banyak service dapat menunggu hingga benar-benar diminta.
• Jangan mendeklarasikan urutan jika socket dapat menyiratkannya. Buka semua socket dalam satu tahap, lalu start semuanya sekaligus.
• Lacak proses menggunakan control group, bukan file PID.
• Jelaskan service dalam file deklaratif agar satu deskripsi dapat digunakan pada setiap distribusi.

Rilis pertama menyusul pada tahun yang sama. Fedora 14 merilis systemd sebagai opsi pada November 2010, dan Fedora 15 menjadikannya default pada Mei 2011.

Mengapa cgroups membuat supervisi dapat diandalkan

Cgroup (control group) adalah fitur kernel untuk mengelompokkan proses yang digabungkan ke Linux 2.6.24 pada 2008. systemd menempatkan setiap service dalam cgroup sendiri. Proses anak mewarisi cgroup dari induknya, dan proses tanpa hak istimewa tidak dapat memindahkan dirinya keluar dari cgroup tersebut. Karena itu, double forking tidak menyembunyikan apa pun: PID 1 selalu memegang kumpulan proses yang tepat milik suatu unit. Menghentikan service berarti menghentikan semua proses dalam cgroup-nya. Itulah yang dilakukan oleh KillMode=control-group secara default.

systemctl status menampilkan grup 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 sepenuhnya menjelaskan masalah file PID yang usang. Tidak ada file yang dapat menjadi usang, karena daftar tersebut merupakan state kernel.

Pohon yang sama juga membawa batasan, karena cgroups awalnya dibuat untuk accounting sebelum digunakan untuk pelacakan proses. MemoryMax=, CPUQuota=, dan TasksMax= masing-masing hanya terdiri dari satu baris. Menerapkan batas memori dan CPU yang ketat pada service kini cukup dilakukan dengan file drop-in. Pada 2009, hal itu memerlukan patch pada shell script yang tidak pernah dibuat siapa pun.

Mengapa setiap distribusi beralih antara 2011 dan 2015

• Fedora 15, Mei 2011.
• openSUSE 12.1, November 2011.
• Mageia 2, Mei 2012.
• Arch Linux, sebagai default untuk instalasi baru sejak Oktober 2012.
• RHEL 7, Juni 2014.
• SLES 12, Oktober 2014.
• Debian 8, April 2015.
• Ubuntu 15.04, April 2015.

Alasannya sebagian besar tidak menarik. Karena itu, peralihannya berlangsung cepat.

• Satu berkas unit berfungsi pada setiap distribusi. Karena itu, proyek upstream mulai merilis berkas .service, dan distribusi berhenti memelihara satu shell script untuk setiap package pada setiap rilis.
• Pelacakan sesi desktop beralih ke systemd-logind setelah ConsoleKit tidak lagi dipelihara sekitar 2012. GNOME memerlukan logind. Jadi, distribusi yang tidak menggunakan systemd harus mencari pengganti. Pengganti tersebut, elogind, adalah logind milik systemd yang diekstrak dan dipelihara secara terpisah.
• udev, device manager, digabungkan ke source tree systemd pada April 2012. Distribusi yang merilis udev kini melacak repository systemd. Sebagai tanggapan, Gentoo mem-fork eudev.
• Container membuat pelacakan proses yang andal dan batas per-service menjadi lebih penting karena keduanya merupakan fitur cgroup. Pertanyaan tentang supervisor mana yang memiliki proses container masih relevan setiap kali Anda membuat stack Docker Compose aktif kembali setelah reboot.

Keputusan Debian paling banyak mendapat perhatian. Technical Committee melakukan pemungutan suara pada Februari 2014. Hasilnya imbang, lalu ketua Bdale Garbee memberikan suara penentu untuk systemd. Beberapa hari kemudian, Ubuntu mengumumkan bahwa Ubuntu akan mengikuti Debian, bukan melanjutkan penggunaan Upstart. Sekelompok developer Debian mem-fork distribusi tersebut menjadi Devuan pada November 2014 dan merilis Devuan 1.0 pada Mei 2017.

Keberatan yang disampaikan secara adil

Cakupan. Satu proyek kini merilis PID 1, daemon logging, manajemen sesi login, pengelola perangkat, daemon konfigurasi jaringan, resolver DNS (domain name system), klien NTP (network time protocol), runner container, dan boot loader. Pembelaan yang umum, yaitu bahwa semua komponen tersebut berupa binary terpisah yang tidak wajib Anda instal, memang benar, tetapi tidak menjawab keberatan ini. Setelah desktop memerlukan logind dan logind dirilis dari pohon systemd, pilihan tersebut tidak lagi bebas. Itulah yang dimaksud dengan coupling dalam argumen tersebut, dan hal itu memang terjadi.

Journal binary. journald menulis format binary terindeks, bukan teks biasa. Anda memperoleh hal-hal yang tidak pernah disediakan teks: pemfilteran berdasarkan unit dan prioritas, field terstruktur, serta metadata yang tidak dapat dipalsukan oleh program pengirim karena journald mencatat unit dan cgroup itu sendiri. journalctl -u nginx -p err --since "-1h" menggantikan grep dengan regular expression tanggal. Biayanya juga nyata. Pada mesin yang tidak dapat boot, Anda tidak dapat membaca log dengan less dari rescue shell. Arahkan journalctl ke disk yang telah di-mount:

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

Ada jebakan kedua yang sering baru diketahui setelah mengalaminya. journald menyimpan log di /run/log/journal, yang merupakan memory, kecuali /var/log/journal tersedia. Pada mesin yang tidak memiliki /var/log/journal, journalctl -b -1 tidak menampilkan apa pun setelah reboot, tepat saat Anda membutuhkannya. Periksa dan perbaiki:

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 seharusnya melaporkan journal yang diarsipkan di bawah /var/log/journal. Jika Anda juga menginginkan teks biasa, atur ForwardToSyslog=yes di /etc/systemd/journald.conf dan pertahankan rsyslog tetap terinstal.

Kemudahan debugging saat boot. Saat sebuah unit macet, console hanya menampilkan satu baris dan tidak ada informasi lain:

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

Tool untuk melanjutkan pemeriksaan memang tersedia: systemctl list-jobs saat proses masih macet, systemd-analyze blame dan systemd-analyze critical-chain setelahnya, serta systemd.log_level=debug pada kernel command line. Versi keberatan yang adil adalah bahwa init script dapat dibaca dari awal hingga akhir oleh siapa pun yang mengetahui sh, sedangkan unit yang macet mengharuskan Anda mengetahui perintah mana dari belasan perintah yang harus digunakan. Itu merupakan biaya nyata. Setiap administrator harus membayarnya sekali, dan banyak administrator harus membayarnya pada waktu yang sama.

Default yang berubah untuk semua orang. systemd 230 pada 2016 mengubah default logind sehingga proses user yang tersisa dihentikan saat logout. Sesi tmux dan screen yang detached berakhir ketika sesi yang memulainya berakhir. Distribution mengirimkan KillUserProcesses=no di /etc/systemd/logind.conf, dan jawaban yang didukung adalah loginctl enable-linger <user>. Satu default dalam satu proyek mengubah kebiasaan yang diandalkan jutaan orang. Inilah arti "terlalu banyak userland di satu tempat" dalam praktik.

Dependensi default merupakan permukaan keamanan. Pada Maret 2024, backdoor pada xz-utils menargetkan sshd di Debian dan Ubuntu. OpenSSH upstream tidak melakukan link ke libsystemd. Distribution tersebut menambahkan patch agar sshd dapat melaporkan readiness ke systemd, dan libsystemd menarik liblzma, tempat backdoor tersebut berada. Protokol readiness itu sendiri hanya berupa satu datagram yang dikirim ke socket yang disebut dalam $NOTIFY_SOCKET, sehingga library tidak pernah diperlukan untuk itu. Respons systemd adalah memuat library kompresi dengan dlopen, sehingga library tersebut tidak lagi di-link secara default. Kelas bug terkait menunjukkan pola yang sama: pada 2017, nilai User= yang diawali digit dianggap tidak valid dan unit dijalankan sebagai root alih-alih gagal, sehingga typo berubah menjadi privilege escalation. Versi yang lebih baru menolak menjalankan unit tersebut.

Riwayat pada prompt systemctl Anda sendiri

Setiap masalah di atas kini menjadi satu direktif dalam file yang dapat Anda baca.

• Boot serial menjadi After= dan Wants=, sedangkan systemd-analyze critical-chain menunjukkan apa yang sebenarnya menahan boot Anda.
• Kesiapan menjadi Type=notify. Di sana service menulis READY=1 ke $NOTIFY_SOCKET saat sudah dapat melayani permintaan. Type=forking dengan PIDFile= masih tersedia untuk daemon lama, dan merupakan tipe yang gagal dengan start operation timed out. Terminating. jika file PID tidak pernah muncul.
• Supervisi dilakukan oleh cgroup. Karena itu, Restart=on-failure dengan RestartSec= menggantikan skrip wrapper, sedangkan StartLimitBurst= mencegah loop crash berjalan tanpa batas.
• inetd menjadi unit .socket yang berada di samping unit .service.
• ulimit menjadi MemoryMax=, CPUQuota=, dan TasksMax=.
• Baris su - appuser -c dalam skrip init menjadi User=, NoNewPrivileges=yes, dan ProtectSystem=strict. Dengan demikian, menjalankan service sebagai pengguna tanpa hak istimewa menjadi bentuk default unit, bukan pekerjaan 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 file tersebut adalah kesalahan yang biasanya dibuat setiap orang satu kali. Requires=postgresql.service adalah persyaratan, bukan pengurutan: direktif ini menyatakan bahwa unit Anda gagal jika Postgres gagal, tetapi tidak menyatakan bahwa Postgres harus dimulai lebih dahulu. Tanpa After=postgresql.service, keduanya dimulai pada saat yang sama, dan service Anda mencoba terhubung ke port yang belum memiliki proses yang mendengarkan. Keduanya sengaja dipisahkan karena terkadang Anda memerlukan salah satunya tanpa yang lain. ProtectSystem=strict me-mount sistem file dalam mode hanya-baca untuk service ini. Karena itu, StateDirectory= ada untuk memberikan satu path yang dapat ditulis bagi service di bawah /var/lib.

Tempat paling jelas untuk melihat perilaku dari 2005 pada server 2026 adalah SSH di Ubuntu 24.04, yang menggunakan systemd 255 pada Agustus 2026. ssh.service diaktifkan melalui socket secara default: ssh.socket memegang socket yang mendengarkan, dan sshd dimulai saat koneksi masuk. Karena itu, Port 2222 dalam /etc/ssh/sshd_config tidak berpengaruh, karena sshd bukan proses yang membuka port tersebut. Perubahan harus dilakukan pada unit socket.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

ListenStream= yang kosong menghapus nilai yang diwarisi dari unit yang disediakan paket. Jika baris tersebut dihilangkan, kedua port akan digunakan karena systemd menambahkan item ke daftar, bukan menggantinya. Setelah itu, terapkan perubahan dan lakukan pemeriksaan. Biarkan sesi SSH kedua tetap terbuka selama proses ini:

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

ss seharusnya menampilkan satu socket pada port 2222 yang dimiliki oleh systemd, bukan oleh sshd. Itulah desain launchd, dua puluh tahun kemudian, pada VPS Anda. Jika Anda lebih memilih perilaku lama, sudo systemctl disable --now ssh.socket yang diikuti sudo systemctl enable --now ssh.service akan memberikan sshd yang berjalan dalam waktu lama dan kembali membaca Port dari konfigurasinya sendiri.

Detail yang Anda temui bergantung pada rilis yang digunakan. Karena itu, sebaiknya pahami perbedaan antara rilis Ubuntu LTS dan interim sebelum merencanakan pemutakhiran. Jika Anda mengelola lebih dari satu mesin, fakta bahwa file unit identik di semua mesin menjadi alasan mengelola beberapa server dari satu tempat kini merupakan masalah konfigurasi, bukan lagi masalah skrip shell. Saat menulis unit sendiri, pasangan service dan timer menjalankan tugas yang pada 2009 akan Anda bagi antara skrip init dan baris cron.

FAQ

Mengapa distribusi Linux mengganti SysV init dengan systemd?

Ada dua alasan teknis dan satu alasan pemeliharaan. SysV init mengurutkan service berdasarkan nama file. Urutan ini menunjukkan posisi, bukan dependensi. SysV init juga kehilangan jejak daemon yang melakukan fork dari proses induknya. Karena itu, file PID yang sudah usang dapat menghentikan proses yang salah. systemd menangani pengurutan dengan socket activation dan direktif dependensi. systemd menangani pelacakan dengan control group. Alasan pemeliharaan menentukan kecepatannya: satu unit file dapat digunakan pada setiap distribusi. Karena itu, proyek upstream merilis file .service, dan maintainer distribusi berhenti menulis shell script untuk setiap package. Fedora 15 beralih pada May 2011, sedangkan Ubuntu 15.04 menjadi distribusi besar terakhir yang bertahan, pada April 2015.

Apakah systemd merupakan satu binary besar?

Tidak. Source tree tersebut membangun banyak program terpisah. PID 1 adalah /usr/lib/systemd/systemd, sedangkan journald, logind, dan udevd merupakan proses terpisah dengan binary masing-masing. Jalankan ls /usr/lib/systemd/ untuk melihatnya pada sistem Anda. Kritik yang masih bertahan berkaitan dengan keterikatan jadwal rilis, bukan ukuran binary. Program-program ini dirilis bersama dan menggunakan interface privat yang sama. Karena itu, distribusi cenderung mengambilnya sebagai satu set. Software seperti GNOME juga kemudian mengharapkan logind secara khusus.

Apakah saya masih dapat menjalankan Linux tanpa systemd?

Ya. Devuan menyertakan sysvinit, Gentoo menggunakan OpenRC sebagai default, Void menggunakan runit, Alpine menggunakan busybox init dengan OpenRC, dan Slackware mempertahankan script bergaya BSD. Konsekuensinya adalah pekerjaan kompatibilitas. Software desktop yang mengharapkan logind memerlukan elogind. Komponen ini adalah logind milik systemd yang dipelihara sebagai package mandiri. Selain itu, semakin banyak software server yang sekarang hanya merilis file .service. Karena itu, Anda harus menulis dan memelihara startup script sendiri.

Mengapa journal menggunakan format binary, bukan file teks biasa?

Karena journald menyimpan field terstruktur beserta index. Dengan demikian, journald menyediakan filtering berdasarkan unit, filtering berdasarkan prioritas, dan metadata yang tidak dapat dipalsukan oleh program pengirim. journald mencatat unit, cgroup, dan UID sebenarnya sendiri, bukan mempercayai isi baris log. Konsekuensinya, Anda memerlukan journalctl untuk membacanya, termasuk dari rescue system. Dalam kondisi tersebut, arahkan journalctl ke disk yang telah di-mount menggunakan journalctl --directory /mnt/var/log/journal. Jika Anda juga menginginkan teks, tetapkan ForwardToSyslog=yes di /etc/systemd/journald.conf.

Apa yang menggantikan pengeditan script /etc/init.d saya?

Gunakan file drop-in. Jangan mengedit unit di /usr/lib/systemd/system/ karena package upgrade akan menimpanya. Jalankan sudo systemctl edit nginx.service, lalu systemd membuat /etc/systemd/system/nginx.service.d/override.conf yang digabungkan di atas unit dari package. systemctl cat nginx.service menampilkan hasil gabungan tersebut, sedangkan systemd-delta mencantumkan semua override pada mesin. Setelah mengedit secara manual, jalankan sudo systemctl daemon-reload. Jika tidak, perintah berikutnya akan menampilkan Warning: The unit file, source configuration file or drop-ins of nginx.service changed on disk..