File service systemd tidak wajib berada di /etc/systemd/system. System manager mencari unit file di beberapa direktori, dan lokasi file berpengaruh karena urutan pencarian menentukan definisi mana yang dipakai ketika nama unit yang sama tersedia di lebih dari satu tempat.

Untuk service yang dikelola administrator, /etc/systemd/system biasanya menjadi lokasi yang tepat. Package distribusi umumnya memasang unit di /usr/lib/systemd/system, sedangkan /run/systemd/system digunakan untuk konfigurasi runtime yang hilang setelah reboot. Pemisahan ini memungkinkan konfigurasi lokal menimpa default dari vendor tanpa mengedit file milik package manager.

systemd mencari nama unit melalui load path

Ketika sebuah perintah merujuk unit berdasarkan nama,

systemctl start myapp.service

systemd mencari myapp.service melalui unit load path. Gambaran sederhana untuk beberapa lokasi system-level yang penting adalah:

/etc/systemd/system
/run/systemd/system
/usr/local/lib/systemd/system
/usr/lib/systemd/system

Load path lengkap juga berisi direktori lain untuk generated, transient, dan attached units. Sifat pentingnya adalah prioritas: unit yang ditemukan lebih awal dalam jalur pencarian menimpa unit bernama sama yang berada lebih bawah.

Artinya, dua file berikut tidak diperlakukan sebagai dua service terpisah:

/etc/systemd/system/myapp.service
/usr/lib/systemd/system/myapp.service

Definisi di /etc/systemd/system/myapp.service memiliki prioritas lebih tinggi.

Load path yang efektif dapat diperiksa langsung:

systemd-analyze unit-paths

Cara ini lebih akurat daripada mengasumsikan setiap distribusi memakai layout filesystem yang persis sama.

/etc/systemd/system untuk konfigurasi lokal administrator

Custom service yang dibuat langsung oleh administrator biasanya ditempatkan di:

/etc/systemd/system/myapp.service

Contohnya:

[Unit]
Description=My application
After=network.target

[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/server
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Hanya definisi unit yang perlu berada dalam search path systemd. Aplikasinya sendiri tidak harus berada di sana.

Executable dapat disimpan di lokasi lain:

/opt/myapp/server
/srv/myapp/server
/usr/local/bin/myapp

ExecStart= menggunakan path executable absolut, sehingga binary tidak harus berada satu direktori dengan file .service.

Pemisahan ini menjaga konfigurasi service manager tetap terpisah dari artifact aplikasi.

Unit dari vendor berada di bawah /usr

Software yang dikelola package manager umumnya memasang system unit ke direktori unit milik distribusi, biasanya:

/usr/lib/systemd/system

Sebagian sistem secara historis menggunakan /lib/systemd/system; pada distribusi dengan layout merged /usr, /lib dapat berupa symlink menuju /usr/lib.

Administrator sebaiknya tidak mengedit unit milik package secara langsung. Package upgrade dapat mengganti file tersebut, dan perubahan lokal menjadi sulit dibedakan dari perubahan vendor.

Misalnya sebuah package menyediakan:

/usr/lib/systemd/system/example.service

dan perubahan lokal yang dibutuhkan hanya restart policy. Drop-in lebih tepat daripada menyalin lalu memelihara seluruh unit vendor:

sudo systemctl edit example.service

Override lokal biasanya tersimpan di:

/etc/systemd/system/example.service.d/override.conf

dengan isi seperti:

[Service]
Restart=on-failure
RestartSec=3s

Unit vendor tetap dikelola package manager, sementara kebijakan lokal tetap berada di bawah /etc.

/run/systemd/system bersifat sementara

/run menyimpan runtime state. Unit file yang ditempatkan di:

/run/systemd/system

dapat memengaruhi boot yang sedang berjalan, tetapi tidak ditujukan untuk bertahan setelah reboot.

Lokasi ini cocok untuk konfigurasi generated atau sementara. Sebaliknya, lokasi tersebut tidak cocok untuk production service yang dipelihara manual dan harus tetap tersedia setelah mesin dinyalakan ulang.

Hubungan prioritasnya juga penting:

/etc/systemd/system
        ↓
/run/systemd/system
        ↓
/usr/local/lib/systemd/system
        ↓
/usr/lib/systemd/system

Definisi persisten milik administrator di /etc dapat menimpa definisi runtime atau vendor bernama sama yang berada lebih rendah dalam load path.

Unit file dapat tetap berada di luar direktori standar

Dalam beberapa proyek, unit file disimpan bersama source tree:

/opt/myapp/deploy/myapp.service

File tersebut tidak harus disalin secara manual ke /etc/systemd/system. systemctl link dapat membuat unit eksternal tersedia melalui unit search path:

sudo systemctl link /opt/myapp/deploy/myapp.service

Perintah ini membuat link di area konfigurasi unit yang menunjuk ke file eksternal.

Ada konsekuensi operasional: target link harus tetap tersedia setiap kali systemd membutuhkan unit tersebut. Memindahkan atau menghapus direktori proyek akan merusak link. Untuk service yang sudah di-deploy, memasang unit secara stabil di /etc/systemd/system sering lebih mudah dikelola daripada membuat link ke source checkout yang dapat berubah.

daemon-reload berbeda dari reload service

Setelah membuat atau mengubah unit file secara manual, reload konfigurasi systemd manager:

sudo systemctl daemon-reload

Perintah ini membuat systemd membaca ulang unit file dan membangun kembali informasi dependency.

Operasi tersebut berbeda dari:

sudo systemctl reload myapp.service

Perintah kedua meminta service itu sendiri me-reload konfigurasi aplikasi, jika service mendukung operasi tersebut. Artinya bukan “baca ulang file .service ini.”

Urutan yang umum setelah memasang custom unit baru adalah:

sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service

enable dan start juga menyatakan kondisi yang berbeda. start mengaktifkan unit saat ini. enable membuat link yang ditentukan oleh bagian [Install] sehingga unit dapat ditarik otomatis oleh target seperti multi-user.target.

Untuk menjalankan keduanya sekaligus pada service yang baru dipasang:

sudo systemctl enable --now myapp.service

Enable tidak memindahkan unit file

Salah satu anggapan yang keliru adalah systemctl enable menyalin service ke direktori startup khusus. Operasi ini pada umumnya membuat symlink sesuai bagian [Install].

Untuk:

[Install]
WantedBy=multi-user.target

proses enable biasanya menghasilkan relasi seperti:

/etc/systemd/system/multi-user.target.wants/myapp.service
    -> /etc/systemd/system/myapp.service

atau link menuju lokasi unit yang sebenarnya.

Link di direktori .wants/ menyatakan wiring dependency. Unit aslinya tetap berada di tempat instalasinya.

Karena itu sebuah service dapat dijalankan walaupun berstatus disabled:

sudo systemctl start myapp.service

dan dapat di-enable walaupun saat itu belum berjalan:

sudo systemctl enable myapp.service

Aktivasi runtime dan enablement saat boot adalah dua konsep yang terpisah.

Periksa definisi yang benar-benar dimuat systemd

Ketika beberapa direktori, symlink, atau drop-in terlibat, periksa unit efektif daripada menebak.

systemctl cat myapp.service

Untuk melihat path fragment unit utama:

systemctl show myapp.service -p FragmentPath

Contohnya:

FragmentPath=/etc/systemd/system/myapp.service

Perbedaan konfigurasi lokal terhadap vendor juga dapat diperiksa dengan:

systemd-delta

Perintah-perintah ini sangat berguna setelah package upgrade atau ketika sebuah mesin telah mengumpulkan override lama.

Lokasi unit menyatakan kepemilikan konfigurasi

Direktori unit file merupakan bagian dari kebijakan administrasi sistem, bukan batasan mengenai lokasi binary aplikasi.

Model kepemilikan yang berguna adalah:

/usr/lib/systemd/system/
    unit yang dikelola distribusi atau package

/usr/local/lib/systemd/system/
    system unit yang dipasang secara lokal

/run/systemd/system/
    unit khusus runtime

/etc/systemd/system/
    konfigurasi dan override persisten milik administrator

Untuk custom application yang dikelola langsung pada server, unit di /etc/systemd/system membuat kepemilikannya jelas. Untuk software dari package, mempertahankan unit vendor di /usr/lib lalu menerapkan perubahan lokal melalui /etc menjaga batas antara package state dan kebijakan administrator.

Batas tersebut merupakan alasan utama unit search path systemd memiliki beberapa direktori. Path-path itu bukan sekadar tempat penyimpanan yang dapat dipertukarkan; urutannya memberi konfigurasi lokal mekanisme terkontrol untuk menimpa definisi dengan prioritas lebih rendah tanpa menulis ulang file asalnya.

Linux Systemd Systemctl Manajemen Service