Ano ang systemd, paano ito gumagana, at paano pamahalaan ang mga serbisyo sa Linux

Ang systemd ay init system at service manager na ginagamit sa karamihan ng modernong distribution ng Linux: Debian, Ubuntu, Fedora, RHEL, at kanilang mga kamag-anak. Pagkatapos mag-boot, sinisimulan ng kernel ang systemd bilang unang process na may PID 1, at mula roon ay pinapatakbo na nito ang network, mino-mount ang mga disk, sinisimulan ang web server, database, at lahat ng iba pa. Sa maikling salita, ang systemd ay "tagapamahala" na nakaaalam kung aling mga serbisyo ang dapat tumakbo, sa anong pagkakasunod sisimulan, at kung ano ang gagawin kapag bumagsak ang isang serbisyo.

Madaling suriin kung systemd ang gamit mo:

$ ps -p 1 -o comm=
systemd

Bakit kinailangan ang systemd

Dati, gumagamit ang Linux ng SysV init: isang hanay ng shell script sa /etc/init.d/ na sunod-sunod na tinatakbo. Madaling intindihin ang sistemang ito, pero mabagal at marupok. Bawat script ang kailangang sumulat ng PID file, magpasya kung buhay pa ang process, at ang pag-restart ng serbisyong bumagsak ay kailangang gawin nang hiwalay.

Sentralisado ang paglutas ng systemd sa mga problemang ito:

• Parallel na pagsisimula. Sabay-sabay na sinisimulan ang mga serbisyong walang dependency sa isa't isa, kaya mas mabilis mag-boot.
• Dependency at pagkakasunod. Malinaw sa paglalarawan ng serbisyo kung ano ang kailangan nito (halimbawa network) at kung kailan dapat simulan.
• Pagbabantay. Kilala ng systemd ang lahat ng process ng serbisyo sa pamamagitan ng cgroups at kayang i-restart ito kapag bumagsak.
• Iisang journal. Kinokolekta ng journald ang output ng lahat ng serbisyo, at sa iisang utos mo ito mababasa.
• Iisang interface. Pare-pareho ang pamamahala sa lahat ng serbisyo: systemctl start|stop|restart|status.

Bukod sa service manager, may ilang bahagi ang proyekto ng systemd: journald (log), logind (mga user session), timesyncd (pag-sync ng oras), resolved (DNS), at networkd (network). Hindi lahat ng distribution ay gumagamit ng lahat ng ito, pero halos palaging naroon ang systemd bilang PID 1 at ang journald.

Mga unit: ano ang binubuo ng systemd

Inilalarawan ang lahat ng pinamamahalaan ng systemd gamit ang mga unit. Ang unit ay text file na nasa format na INI, at ang uri nito ay tinutukoy ng extension.

Nasaan ang mga unit file

Nakalagay ang mga unit file sa ilang direktoryo, at may prayoridad ang mga ito:

• /usr/lib/systemd/system/ (sa Debian at Ubuntu, mayroon ding /lib/systemd/system/) — mga unit na galing sa package. Huwag itong i-edit nang direkta: buburahin ng update ng package ang mga pagbabago.
• /etc/systemd/system/ — mga unit at override ng administrator. Ito ang may pinakamataas na prayoridad.
• /run/systemd/system/ — mga pansamantalang unit na nalikha habang tumatakbo ang sistema.

Para makita ang panghuling nilalaman ng isang unit kasama ang lahat ng override, gamitin ang systemctl cat nginx.service.

Target sa halip na runlevel

Pinalitan ng target ang mga lumang runlevel. Ang multi-user.target ay karaniwang server mode na walang graphics, ang graphical.target ay may graphical na shell, at ang rescue.target ay single-user mode para sa recovery. Makikita ang default target gamit ang systemctl get-default at mababago gamit ang systemctl set-default multi-user.target.

systemctl: pamamahala ng serbisyo

Ang systemctl ang pangunahing kasangkapan sa systemd. Karamihan ng utos ay nagbabago ng estado ng sistema at nangangailangan ng sudo.

Paano basahin ang systemctl status

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 09:14:03 UTC; 2h 5min ago
       Docs: man:nginx(8)
   Main PID: 812 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 6.1M
        CPU: 154ms
     CGroup: /system.slice/nginx.service
             ├─812 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─813 "nginx: worker process"
             └─814 "nginx: worker process"

Ipinapakita ng linyang Loaded kung saan galing ang unit file at kung naka-enable ang autostart (enabled). Ang linyang Active ang kasalukuyang estado: active (running), inactive (dead), o failed. Ipinapakita ng bloke ng CGroup ang lahat ng process ng serbisyo — ganito binabantayan ng systemd kung alin ang sa kanya.

Ano ang pagkakaiba ng enable at start

Madalas itong malito. Sinisimulan ng start ang serbisyo ngayon, pero hindi ito babalik pagkatapos mag-reboot. Gumagawa naman ang enable ng symbolic link sa direktoryo ng target (halimbawa /etc/systemd/system/multi-user.target.wants/), kaya sinisimulan ang serbisyo sa boot, pero hindi ito tumatakbo ngayon. Kadalasan kailangan ang dalawa — gamitin ang enable --now.

May ikatlong estado ang mask: itinatali ng systemctl mask service ang unit sa /dev/null, kaya hindi ito mapapatakbo, kahit manual o bilang dependency. Kapaki-pakinabang kapag gusto mong siguradong nakapatay ang serbisyo.

journalctl: log ng mga serbisyo

Lahat ng isinusulat ng serbisyo sa stdout at stderr ay kinukuha ng systemd-journald at isinasave sa binary na log kasama ang metadata: pangalan ng unit, PID, priority, at oras. Binabasa ang journal gamit ang journalctl.

journalctl -u nginx              # log ng isang serbisyo
journalctl -u nginx -f           # sundan nang real time, tulad ng tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # huling 50 linya
journalctl -b                    # mula sa kasalukuyang boot
journalctl -b -1                 # nakaraang boot
journalctl -p err -b             # error at mas malala lamang
journalctl -k                    # mga mensahe ng kernel
journalctl --disk-usage          # gaano kalaki ang espasyo ng log

Sinasala ng -p ayon sa priority ng syslog: emerg, alert, crit, err, warning, notice, info, debug. Kasama sa tinukoy na antas ang lahat ng mas malala.

Log pagkatapos mag-reboot

Kung wala ang direktoryong /var/log/journal at naka-Storage=auto ang /etc/systemd/journald.conf, nasa memorya lamang (/run/log/journal) ang log at nawawala pagkatapos mag-reboot. Para permanente ito, itakda ang Storage=persistent o gumawa ng direktoryo at i-restart ang journald. Nililimitahan ang laki ng SystemMaxUse=, at maaaring linisin ang luma gamit ang journalctl --vacuum-time=2weeks o --vacuum-size=500M.

Madalas kasama ng journald ang rsyslog: ipinapasa ng journald ang mga mensahe sa rsyslog, na sumusulat ng tradisyonal na text file sa /var/log/ at kayang magpadala ng log sa central server.

Autostart ng sarili mong serbisyo: halimbawa ng unit file

Ipagpalagay na mayroon kang application — script o binary — na kailangang laging tumatakbo, awtomatikong sisimulan sa boot, at mare-restart kapag bumagsak. Gumawa ng file na /etc/systemd/system/myapp.service:

[Unit]
Description=My web application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Ipinaliliwanag ang bawat seksyon:

• [Unit] — paglalarawan at mga dependency. Itinatakda lamang ng After= ang pagkakasunod; ang Wants= ay malambot na dependency (hihilahin ang unit pero hindi babagsak kung hindi ito nagsimula). Matigas na dependency ang Requires=.
• [Service] — paano patakbuhin. Ang Type=simple ay nangangahulugang ang process sa ExecStart ang mismong serbisyo at hindi ito lilipat sa background. Pinapatakbo ng User= ang serbisyo bilang user na walang espesyal na pribilehiyo. Nagre-restart ang Restart=on-failure kapag nag-exit nang may error, pagkalipas ng RestartSec segundo.
• [Install] — ang gagawin ng enable. Ang WantedBy=multi-user.target ay nangangahulugang "simulan sa karaniwang boot".

Ilapat ito:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

Mga karaniwang pagkakamali sa unit file

• Relative na path sa ExecStart. Dapat absolute ang path ng programa. Hindi hinahanap ng systemd ang mga utos sa PATH ng user tulad ng ginagawa ng shell.
• Nakalimutan ang daemon-reload. Pagkatapos i-edit ang file, lumang bersyon pa rin ang gamit ng systemd at magbababala ito sa status.
• Lumilipat sa background ang daemon. Kung nagfo-fork ang programa pero Type=simple ang nakatakda, iisipin ng systemd na tapos na ang serbisyo. Patakbuhin ang programa sa foreground, o gamitin ang Type=forking kasama ang PIDFile=.
• Environment variable mula sa profile. Hindi nakikita ng serbisyo ang ~/.bashrc at /etc/profile. Itakda ang mga variable gamit ang Environment= o EnvironmentFile=.

Override nang hindi ginagalaw ang unit ng package

Para baguhin ang parameter ng serbisyo mula sa package nang hindi ginagalaw ang file nito, gamitin ang drop-in:

sudo systemctl edit nginx

Magbubukas ang editor, at ang mga pagbabago ay ise-save sa /etc/systemd/system/nginx.service.d/override.conf. Halimbawa, maaari mong idagdag doon ang [Service] at Restart=always. Pagkalabas sa editor, awtomatikong babasahin muli ng systemd ang config.

Timer ng systemd bilang kapalit ng cron

Ang timer ay unit na nagpapatakbo ng serbisyong may parehong pangalan ayon sa iskedyul. Mas maganda kaysa cron dahil nasa journal ang log ng gawain, may dependency, at kayang habulin ang mga pagpapatakbong nalampasan (Persistent=true). Halimbawa ng pang-araw-araw na backup:

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

Maaaring suriin ang ekspresyong OnCalendar gamit ang systemd-analyze calendar "*-*-* 03:00:00" — ipapakita nito kung kailan ang susunod na pagpapatakbo.

Pag-diagnose ng boot

Itinatala ng systemd ang oras ng pagsisimula ng bawat unit, kaya madaling hanapin ang dahilan ng mabagal na boot:

systemd-analyze                  # kabuuang oras ng boot
systemd-analyze blame            # mga unit na nakaayos ayon sa oras ng pagsisimula
systemd-analyze critical-chain   # kadena na nagpabagal sa boot
systemd-analyze verify /etc/systemd/system/myapp.service   # suriin ang unit file

Buod

Ang systemd ang PID 1 at service manager ng modernong Linux. Inilalarawan nito ang lahat gamit ang mga unit, kinokontrol gamit ang systemctl, itinatala ang log sa journal na binabasa ng journalctl, at kayang magpatakbo ng gawain gamit ang timer sa halip na cron. Para magamit ito nang mahusay, sapat na ang pag-aaral ng status, enable --now, journalctl -u, at kung paano sumulat ng simpleng unit file na may Restart=on-failure. Ang systemd, journald, at logging ay itinuturo nang praktikal sa kursong Linux.