Kasaysayan ng systemd at kung bakit ito nanaig

Bakit nanaig ang systemd

Nagsimula ang kasaysayan ng systemd sa dalawang bagay na hindi kayang gawin ng SysV init. Ang SysV init (System V init, ang startup system na minana ng Linux mula sa AT&T Unix) ay walang paraan upang ilarawan kung saan nakadepende ang isang serbisyo, at wala ring paraan upang malaman kung aling mga proseso ang kabilang sa isang serbisyo kapag tumatakbo na ito. Sinagot ng systemd ang dalawang problemang ito gamit ang mga feature ng kernel na hindi naaabot ng shell script: mga control group para subaybayan ang mga proseso, at mga listening socket na nauna nang binuksan para sa tamang pag-order. Ang natitirang bahagi ng kasaysayan ay tungkol sa pagkalat ng dalawang solusyong ito sa iba pang bahagi ng userland. Dito nagsimula ang mga pagtutol, at tama ang ilan sa mga ito.

Ano talaga ang ginagawa ng SysV init

Sa isang SysV system, binasa ng PID 1 (process ID 1, ang unang process na sinisimulan ng kernel) ang /etc/inittab, pumili ng runlevel, at pinatakbo ang mga script para sa runlevel na iyon. Nasa /etc/init.d/ ang mga script. Ang mga symbolic link sa /etc/rc3.d/ ang nagtakda kung alin ang tatakbo at kung anong pagkakasunod-sunod, kaya tumuturo ang /etc/rc3.d/S20nginx sa /etc/init.d/nginx at tinatawag ito gamit ang argument na 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

Ang 20 sa S20nginx ay posisyon, hindi dependency. Sinasabi nitong tatakbo ang script na ito pagkatapos ng S19 at bago ang S21. Hindi nito sinasabi kung bakit, kaya walang makakapag-check nito at walang ligtas na makakapagpatakbo ng dalawang hindi magkakaugnay na script nang sabay nang walang taong magpapasyang ligtas ito.

Pinatakbo ng rc program ang bawat script nang paisa-isa at hinintay itong matapos. Kung nag-block ang isang script nang tatlumpung segundo habang naghihintay ng network address, na-block din nang tatlumpung segundo ang buong boot, pati ang mga service na hindi kailanman gumagamit ng network.

Ang LSB (Linux Standard Base) header sa itaas ng script na iyon ay pagtatangkang ayusin ito mula sa loob. Noong 2011, ginawa ng Debian 6.0 na default ang insserv: binasa nito ang Required-Start mula sa bawat script, bumuo ng graph, at muling binilang ang mga symlink. Dahil dito, maaaring patakbuhin ng Debian nang sabay ang mga independent script gamit ang startpar. Nakatulong ito, pero hindi nito nalutas ang mas malalim na problema. Nakasalalay pa rin ang dependency sa pagtatapos ng isang script. Ang pagbabalik ng S20nginx na 0 ay nangangahulugang nagbalik ang isang shell function. Hindi nito nangangahulugang tumatanggap na ng connections ang nginx.

Ang limang bagay na hindi kayang ayusin ng anumang init script

• Parallel startup. Ang pag-order batay sa filename ay isang total order para sa bawat service sa machine, kaya ang boot ay kasingbagal ng kabuuan ng oras ng lahat ng bahagi.
• Readiness. Tumatapos ang start script kapag na-fork na nito ang daemon, hindi kapag kaya na ng daemon na tumanggap ng request. Kaya madalas ay masyadong maagang nagsisimula ang kasunod na script.
• Supervision. Dalawang beses nagfa-fork ang isang daemon at lumalabas ang parent nito. Dahil dito, nahiwalay ito sa terminal at nire-reparent sa PID 1. Nakikita ng init na lumabas ang isang child, pero wala itong maaasahang link sa process na patuloy na tumatakbo.
• On-demand start. Maaaring mag-launch ang inetd (ang internet super-server) ng daemon kapag may dumating na connection. Pero hiwalay itong system na may sarili nitong configuration file, at wala itong ginagawa tungkol sa pag-order ng lahat ng iba pang service sa boot.
• Resource control. Walang kayang magtakda ang init script ng limit sa memory ng service o sa bahagi nito sa CPU. Ang ulimit ay para lamang sa isang process, at ang nice ay scheduler lamang ang naaapektuhan. Kaya ang runaway child ng isang service ay mukhang iba pang process sa machine.

Ang supervision gap ang pinakamasakit sa pang-araw-araw na operasyon. Ang PID file ang workaround: isinusulat ng daemon ang process ID nito sa /run/nginx.pid, at binabasa muli ng stop function ang file. Kapag sapilitang pinatay ang daemon, nananatili ang file. Pagkatapos, nire-reuse ng kernel ang numerong iyon para sa ibang process, at nagpapadala ang start-stop-daemon --stop --pidfile ng signal sa process na kasalukuyang nagmamay-ari nito. Ganito nakapapatay ng maling process ang stale PID file sa isang init script.

Inuna ng launchd na lutasin ang problema sa socket

Inilabas ng Apple ang launchd sa Mac OS X 10.4 noong 2005. Isinulat ito ni Dave Zarzycki. Pinalitan ng isang proseso ang init, rc, xinetd, crond, at watchdogd.

Ang ideyang sulit kopyahin ay socket activation. Inuuna ng launchd na likhain ang lahat ng listening socket, saka nito sinisimulan ang mga daemon. Kapag kumonekta ang isang client sa daemon na hindi pa nagsisimula, hindi ito makatatanggap ng connection refused. Hawak ng kernel ang koneksyon sa backlog queue ng socket na iyon hanggang tawagin ng daemon ang accept(). Hindi na kailangang ideklara ng isang tao ang ordering sa pagitan ng dalawang daemon. Ang socket na ang humahawak nito.

Itinayo ang launchd sa Mach IPC (inter-process communication), na bahagi ng XNU kernel ng Apple at walang katumbas sa Linux. Hindi kailanman naging praktikal ang pag-port ng code. Gayunman, kumalat ang ideya.

Ang mga event ang naging unit of work ng Upstart

Ang Upstart ng Canonical, na isinulat ni Scott James Remnant, ay inilabas sa Ubuntu 6.10 noong October 2006. Ginamit ito ng Fedora 9 hanggang Fedora 14, gayundin ng RHEL 6 at Chrome OS. Pinalitan nito ang runlevel ng isang event, at tinutukoy ng isang job kung aling mga event ang dapat magsimula at maghinto rito.

# /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

Dalawang problema ang lumitaw habang dumarami ang mga job. Ang una ay ang direksyon ng dependency. Sinasabi ng isang job na “simulan ako kapag nangyari ito,” kaya nasa maling file ang impormasyon kung ano ang nakadepende sa ano: alam ng isang serbisyo kung ano ang kailangan nito, pero hindi nito malalaman kung sino ang mangangailangan dito sa susunod na taon. Kadalasan, ang pagdaragdag ng serbisyo ay nangangailangan ng pag-edit sa isang kasalukuyang job para maglabas ito ng bagong event.

Ang ikalawa ay ang pagsubaybay sa proseso. Sinusubaybayan ng Upstart ang isang forking daemon sa pamamagitan ng pagbilang sa mga fork() call gamit ang ptrace, na kino-configure bilang expect fork o expect daemon. Kapag mali ang tantiya sa bilang ng mga fork, maaaring pangasiwaan ng Upstart ang prosesong tapos na, o maghintay sa fork na nangyari na. Ang sintomas ay nakabiting initctl start nang walang error, at walang paraan ang job file para ipaliwanag ito.

Kinailangan din ng Upstart na pumirma ang mga contributor sa contributor agreement ng Canonical. Hindi ito engineering fault, pero nakaapekto ito sa mga taong nagtrabaho rito.

Muling Pag-iisip sa PID 1, Abril 2010

Noong 30 Abril 2010, naglathala si Lennart Poettering ng post na pinamagatang “Muling Pag-iisip sa PID 1.” Nakipagtulungan sa kanya si Kay Sievers sa project. May apat na bahagi ang argumento.

• Mas kaunti ang simulan. Maraming service ang maaaring maghintay hanggang may aktuwal na humiling sa mga ito.
• Itigil ang pagtatakda ng order kung sapat nang ipahiwatig ito ng socket. Buksan ang lahat ng socket sa isang pass, saka sabay-sabay na simulan ang lahat.
• Subaybayan ang mga process gamit ang control group sa halip na PID file.
• Ilarawan ang isang service sa isang declarative file upang gumana ang isang description sa bawat distribution.

Sinundan ito ng unang release sa taon ding iyon. Inilabas ng Fedora 14 ang systemd bilang option noong Nobyembre 2010, at ginawa itong default ng Fedora 15 noong Mayo 2011.

Bakit naging maaasahan ang supervision dahil sa cgroups

Ang cgroup (control group) ay isang feature ng kernel para sa pagpapangkat ng mga proseso. Isinama ito sa Linux 2.6.24 noong 2008. Inilalagay ng systemd ang bawat service sa sarili nitong cgroup. Namamana ng child ang cgroup ng parent nito, at hindi maaaring ilipat ng isang unprivileged process ang sarili nito palabas ng cgroup. Kaya walang itinatago ang double forking: hawak ng PID 1 ang eksaktong set ng mga prosesong kabilang sa isang unit sa lahat ng oras. Ang paghinto sa isang service ay nangangahulugang pagpatay sa lahat ng proseso sa cgroup nito. Ito ang ginagawa ng default na KillMode=control-group.

Ipinapakita ng systemctl status ang grupong iyon:

● 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"

Ang block na iyon ang buong sagot sa stale PID file. Walang file na maaaring maging stale dahil kernel state ang listahan.

Dala rin ng parehong tree ang mga limit, dahil ginawa ang cgroups para sa accounting bago ito ginamit sa tracking. Tig-iisang linya ang MemoryMax=, CPUQuota=, at TasksMax=. Ang Paglalagay ng hard memory at CPU cap sa isang service ay isa nang drop-in file ngayon. Noong 2009, isa pa lamang itong patch sa isang shell script na walang sumulat.

Bakit nagpalit ang bawat distribution mula 2011 hanggang 2015

• Fedora 15, Mayo 2011.
• openSUSE 12.1, Nobyembre 2011.
• Mageia 2, Mayo 2012.
• Arch Linux, default para sa mga bagong installation mula Oktubre 2012.
• RHEL 7, Hunyo 2014.
• SLES 12, Oktubre 2014.
• Debian 8, Abril 2015.
• Ubuntu 15.04, Abril 2015.

Kadalasang simple ang mga dahilan, kaya mabilis ang paglipat.

• Gumagana ang isang unit file sa bawat distribution, kaya nagsimulang mag-release ang mga upstream project ng .service file at tumigil ang mga distribution sa pag-maintain ng tig-isang shell script para sa bawat package at release.
• Lumipat ang desktop session tracking sa systemd-logind matapos tumigil ang maintenance ng ConsoleKit noong bandang 2012. Kailangan ng GNOME ang logind, kaya kinailangang humanap ng kapalit ang distribution na walang systemd. Ang kapalit na iyon, ang elogind, ay ang logind ng systemd na kinuha at mina-maintain nang hiwalay.
• Isinama ang udev, ang device manager, sa source tree ng systemd noong Abril 2012. Dahil dito, ang mga distribution na nagshi-ship ng udev ay nagsubaybay na rin sa repository ng systemd. Bilang tugon, nag-fork ang Gentoo ng eudev.
• Dahil sa containers, naging mas mahalaga ang maaasahang process tracking at per-service limits, dahil parehong cgroup feature ang mga ito. Aktibo pa rin ang tanong kung aling supervisor ang nagmamay-ari sa isang container process kapag pinapabalik mo ang isang Docker Compose stack matapos ang reboot.

Malaki ang naging epekto ng desisyon ng Debian. Bumoto ang Technical Committee noong Pebrero 2014. Tabla ang boto, kaya bumoto ang chair na si Bdale Garbee para sa systemd bilang deciding vote. Pagkalipas ng ilang araw, inanunsyo ng Ubuntu na susundin nito ang Debian sa halip na ipagpatuloy ang Upstart. Noong Nobyembre 2014, nag-fork ang isang grupo ng mga Debian developer at ginawa ang distribution na Devuan. Inilabas ang Devuan 1.0 noong Mayo 2017.

Ang mga pagtutol, na inilalahad nang patas

Saklaw. Isang proyekto na ngayon ang naglalabas ng PID 1, logging daemon, pamamahala ng login session, device manager, network configuration daemon, DNS (domain name system) resolver, NTP (network time protocol) client, container runner, at boot loader. Totoo ang karaniwang depensa na magkakahiwalay na binary ang mga ito at hindi mo kailangang i-install ang lahat, pero hindi nito sinasagot ang pagtutol. Kapag kailangan ng desktop ang logind, at hiwalay na release ang logind mula sa systemd tree, hindi na malaya ang pagpili. Iyon ang ibig sabihin ng coupling sa argumento, at nangyari ito.

Ang binary journal. Sumusulat ang journald ng naka-index na binary format sa halip na plain text. May mga impormasyong makukuha rito na hindi naibibigay ng text: pag-filter ayon sa unit at priority, structured fields, at metadata na hindi maaaring dayain ng nagpapadalang program dahil mismong journald ang nagtatala ng unit at cgroup. Pinapalitan ng journalctl -u nginx -p err --since "-1h" ang grep ng date regular expression. Totoo rin ang kapalit na gastos. Sa machine na hindi nagbo-boot, hindi mo mababasa ang log gamit ang less mula sa rescue shell. Ituro sa halip ang journalctl sa naka-mount na disk:

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

May isa pang bitag dito na minsan ay nakakaligtaan. Iniingatan ng journald ang mga log sa /run/log/journal, na memory, maliban kung umiiral ang /var/log/journal. Sa machine na wala nito, walang maipapakita ang journalctl -b -1 pagkatapos ng reboot, kahit iyon mismo ang oras na kailangan mo ang log. Suriin at ayusin ito:

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

Dapat iulat ngayon ng journalctl --disk-usage ang mga naka-archive na journal sa ilalim ng /var/log/journal. Kung gusto mo rin ng plain text, itakda ang ForwardToSyslog=yes sa /etc/systemd/journald.conf at panatilihing naka-install ang rsyslog.

Pagde-debug ng boot. Kapag nagha-hang ang isang unit, isang linya lamang ang ipinapakita ng console at wala nang iba:

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

May mga tool para magpatuloy sa pagsusuri: systemctl list-jobs habang naka-stuck ito, systemd-analyze blame at systemd-analyze critical-chain pagkatapos nito, at systemd.log_level=debug sa kernel command line. Ang patas na bersyon ng reklamo ay maaaring basahin ng sinumang nakakaalam ng sh ang init script mula simula hanggang dulo, samantalang kailangan mong malaman kung alin sa maraming command ang gagamitin kapag nag-stuck ang isang unit. Totoong gastos ito. Binabayaran ito nang isang beses ng bawat administrator, at sabay-sabay itong binayaran ng maraming administrator.

Isang default na nagbabago para sa lahat. Binago ng systemd 230 noong 2016 ang default ng logind upang patayin ang mga natitirang user process kapag nagla-logout. Namamatay ang mga detached tmux at screen session kapag nagtatapos ang session na nagsimula sa mga ito. Ipinadala ng mga distribution ang KillUserProcesses=no sa /etc/systemd/logind.conf, at ang suportadong sagot ay loginctl enable-linger <user>. Binago ng isang default sa isang proyekto ang nakasanayang gawain na inaasahan ng milyun-milyong tao. Iyan ang praktikal na kahulugan ng “napakaraming userland sa iisang lugar.”

Ang default dependency ay security surface. Noong March 2024, tinarget ng backdoor sa xz-utils ang sshd sa Debian at Ubuntu. Hindi nagli-link ang upstream OpenSSH sa libsystemd. Naglagay ng patch ang mga distribution na iyon upang makapag-ulat ang sshd ng readiness sa systemd, at isinama ng libsystemd ang liblzma, kung saan naroon ang backdoor. Ang readiness protocol mismo ay isang datagram na ipinapadala sa socket na pinangalanan sa $NOTIFY_SOCKET, kaya hindi kailanman kinailangan ang library para rito. Ang tugon ng systemd ay i-load ang compression libraries gamit ang dlopen upang hindi na awtomatikong mai-link ang mga ito. Ipinapakita rin ng kaugnay na klase ng bug ang parehong pattern: noong 2017, ang User= value na nagsisimula sa digit ay itinuring na invalid, pero tumakbo ang unit bilang root sa halip na mag-fail. Dahil dito, naging privilege escalation ang isang typo. Sa mga susunod na version, tumatanggi nang mag-start ang unit.

History sa sarili mong systemctl prompt

Ang bawat problemang nabanggit sa itaas ay isa na ngayong directive sa isang file na maaari mong basahin.

• Ang serial boot ay naging After= at Wants=, at ipinapakita ng systemd-analyze critical-chain kung ano talaga ang nagpabagal sa boot.
• Ang readiness ay naging Type=notify, kung saan isinusulat ng service ang READY=1 sa $NOTIFY_SOCKET kapag kaya na nitong tumanggap ng request. Umiiral pa rin ang Type=forking kasama ang PIDFile= para sa mga lumang daemon, at ito ang uri na nagfa-fail gamit ang start operation timed out. Terminating. kapag hindi lumitaw ang PID file.
• Ang supervision ay naging cgroup, kaya pinapalitan ng Restart=on-failure kasama ang RestartSec= ang wrapper script, at pinipigilan ng StartLimitBurst= na magpatuloy nang walang hanggan ang crash loop.
• Ang inetd ay naging .socket unit na katabi ng .service unit.
• Ang ulimit line sa isang init script ay naging MemoryMax=, CPUQuota= at TasksMax=.
• Ang su - appuser -c line sa isang init script ay naging User=, NoNewPrivileges=yes at ProtectSystem=strict, kaya ang pagpapatakbo ng service bilang unprivileged user ang default na anyo ng isang unit sa halip na dagdag na trabaho.

[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

Ang isang line sa file na iyon ang pagkakamaling nagagawa ng lahat kahit isang beses. Ang Requires=postgresql.service ay requirement, hindi ordering: sinasabi nitong magfa-fail ang unit mo kapag nag-fail ang Postgres, ngunit hindi nito sinasabing simulan muna ang Postgres. Kung walang After=postgresql.service, sabay na magsisimula ang dalawa, at kokonekta ang service mo sa port na wala pang nakikinig. Magkahiwalay ang dalawang ito dahil sinasadya iyon; kung minsan, kailangan mo ang isa nang wala ang isa. Mina-mount ng ProtectSystem=strict ang file system bilang read-only para sa service na ito, kaya naroon ang StateDirectory=: nagbibigay ito sa service ng isang writable path sa ilalim ng /var/lib.

Ang pinakamalinaw na paraan para makita ang 2005 sa isang 2026 server ay ang SSH sa Ubuntu 24.04, na naglalabas ng systemd 255 noong August 2026. Socket activated by default ang ssh.service: hawak ng ssh.socket ang listening socket, at nagsisimula ang sshd kapag may dumating na connection. Kaya walang epekto ang Port 2222 sa /etc/ssh/sshd_config, dahil hindi sshd ang process na nagbukas ng port. Sa socket unit dapat ilagay ang pagbabago.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Nililinis ng walang laman na ListenStream= ang value na minana mula sa packaged unit. Kapag inalis mo ito, makukuha mo ang dalawang port dahil ina-append ng systemd ang mga item sa isang listahan sa halip na palitan ito. Pagkatapos, i-apply at i-check ang mga pagbabago. Panatilihing bukas ang pangalawang SSH session sa buong proseso:

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

Dapat maglista ang ss ng isang socket sa port 2222 na pagmamay-ari ng systemd, hindi ng sshd. Iyan ang disenyo ng launchd, makalipas ang 20 taon, sa VPS mo. Kung mas gusto mo ang dating behavior, magbibigay ang sudo systemctl disable --now ssh.socket na sinundan ng sudo systemctl enable --now ssh.service ng long-running sshd na muling nagbabasa ng Port mula sa sarili nitong config.

Depende sa release na ginagamit mo kung alin sa mga detalyeng ito ang makikita mo, kaya mahalagang malaman ang pagkakaiba ng LTS at interim Ubuntu release bago magplano ng upgrade. Kapag higit sa isang machine ang pinamamahalaan mo, ang dahilan kung bakit maaaring pamahalaan ang ilang server mula sa isang lugar ang pagkakapareho ng unit file sa lahat ng system; dahil dito, configuration problem na ito ngayon sa halip na shell scripting problem. Kapag gumagawa ka naman ng sarili mong units, ginagawa ng service at timer pair ang trabahong dati mong hinahati sa isang init script at cron line noong 2009.

FAQ

Bakit pinalitan ng mga Linux distribution ang SysV init ng systemd?

May dalawang engineering reason at isang maintenance reason. Inaayos ng SysV init ang mga service ayon sa filename, na posisyon lamang at hindi dependency. Nawawala rin sa tracking nito ang daemon na nag-fork palayo sa parent nito. Dahil dito, maaaring mapatay ng stale PID file ang maling process. Nilutas ng systemd ang service ordering gamit ang socket activation at dependency directives. Nilutas naman nito ang process tracking gamit ang control groups. Ang maintenance reason ang nagpasya sa bilis ng paglipat: gumagana ang isang unit file sa bawat distribution, kaya nag-release ang upstream projects ng .service file at tumigil ang mga distribution maintainer sa pagsusulat ng shell script para sa bawat package. Lumipat ang Fedora 15 noong May 2011, at ang Ubuntu 15.04 ang huling malaking nagpatuloy sa lumang setup noong April 2015.

Isang malaking binary ba ang systemd?

Hindi. Maraming magkakahiwalay na program ang bina-build mula sa source tree nito. Ang PID 1 ay /usr/lib/systemd/systemd, habang magkakahiwalay na process at sariling binary ang journald, logind, at udevd. Patakbuhin ang ls /usr/lib/systemd/ upang makita ang mga ito sa sarili mong machine. Ang natitirang puna ay tungkol sa release coupling, hindi sa laki ng binary: sabay na nire-release ang mga program na ito at gumagamit sila ng private interfaces. Dahil dito, karaniwang kinukuha ng mga distribution ang mga ito bilang isang set. Inasahan din ng software gaya ng GNOME ang partikular na paggamit ng logind.

Maaari ko pa bang patakbuhin ang Linux nang walang systemd?

Oo. Ang Devuan ay nagso-ship ng sysvinit, ang default ng Gentoo ay OpenRC, runit ang ginagamit ng Void, busybox init na may OpenRC ang ginagamit ng Alpine, at pinananatili ng Slackware ang mga script na istilong BSD. Ang kapalit nito ay karagdagang compatibility work. Ang desktop software na umaasa sa logind ay nangangailangan ng elogind. Ito ang logind ng systemd na pinananatili bilang standalone package. Dumadami rin ang server software na nagso-ship lamang ng .service file, kaya ikaw mismo ang magsusulat at magpapanatili ng startup script.

Bakit binary ang journal sa halip na plain text file?

Dahil nag-iimbak ang journald ng structured fields na may index. Nagbibigay ito ng filtering ayon sa unit, filtering ayon sa priority, at metadata na hindi maaaring pekein ng program na nagpapadala ng log. Ang unit, cgroup, at tunay na UID ay itinatala mismo ng journald sa halip na basta pagkatiwalaan ang log line. Ang kapalit nito ay kailangan mo ng journalctl upang basahin ang journal, kabilang na mula sa rescue system. Ituro ito sa mounted disk gamit ang journalctl --directory /mnt/var/log/journal. Kung gusto mo rin ng text output, itakda ang ForwardToSyslog=yes sa /etc/systemd/journald.conf.

Ano ang pumalit sa pag-edit ng aking /etc/init.d script?

Mga drop-in file. Huwag i-edit ang unit sa /usr/lib/systemd/system/ dahil o-overwrite ito ng package upgrade. Patakbuhin ang sudo systemctl edit nginx.service at gagawa ang systemd ng /etc/systemd/system/nginx.service.d/override.conf, na ime-merge sa packaged unit. Ipinapakita ng systemctl cat nginx.service ang merged result, at inililista ng systemd-delta ang bawat override sa machine. Pagkatapos ng anumang manual na pag-edit, patakbuhin ang sudo systemctl daemon-reload. Kung hindi, ipi-print ng susunod na command ang Warning: The unit file, source configuration file or drop-ins of nginx.service changed on disk.