Historia ya systemd na sababu za kushinda kwake

Kwa nini systemd ilishinda

Historia ya systemd inaanza na mambo mawili ambayo SysV init haikuweza kufanya. SysV init (System V init, mfumo wa kuanzisha Linux uliorithiwa kutoka AT&T Unix) haikuwa na njia ya kuelezea huduma inategemea nini, na haikuwa na njia ya kujua ni michakato (processes) ipi inayomilikiwa na huduma pindi inapokuwa inaendeshwa. systemd ilijibu yote mawili kwa kutumia vipengele vya kernel ambavyo hati ya shell (shell script) haiwezi kufikia: control groups kwa ajili ya kufuatilia michakato, na listening sockets zilizofunguliwa mapema kwa ajili ya kupanga mtiririko. Hadithi iliyobaki ni jinsi majibu hayo mawili yalivyoenea katika sehemu nyingine ya userland, ambapo ndipo pingamizi zilipoanzia, na baadhi ya pingamizi hizo zilikuwa sahihi.

Yale ambayo SysV init ilifanya kihalisi

Kwenye mfumo wa SysV, PID 1 (process ID 1, mchakato wa kwanza unaoanzishwa na kernel) ilisoma /etc/inittab, ikachagua runlevel, na kuendesha hati (scripts) za runlevel hiyo. Hati hizo zilikuwa zikikaa ndani ya /etc/init.d/. Viungo vya mfano (symbolic links) ndani ya /etc/rc3.d/ viliaua ni zipi zinazoendeshwa na kwa mpangilio upi, kwa hivyo /etc/rc3.d/S20nginx ilielekeza kwenye /etc/init.d/nginx na kuitwa ikiwa na hoja (argument) 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 iliyopo ndani ya S20nginx ni nafasi, si utegemezi. Inasema hati hii inaendeshwa baada ya S19 na kabla ya S21. Haielezi sababu, kwa hivyo hakuna kinachoweza kuikagua, na hakuna kinachoweza kuendesha hati mbili zisizohusiana kwa wakati mmoja kwa usalama bila binadamu kuamua kuwa ni salama.

Programu ya rc iliendesha kila hati kwa zamu na kusubiri hadi imalize. Hati iliyokwama kwa sekunde thelathini ikisubiri anwani ya mtandao ilikwamisha mchakato mzima wa boot kwa sekunde thelathini, hata kwa huduma ambazo hazigusi mtandao hata kidogo.

Kichwa cha habari cha LSB (Linux Standard Base) kilichopo juu ya hati hiyo kilikuwa jaribio la kurekebisha hili kutoka ndani. Debian 6.0 mnamo 2011 ilifanya insserv kuwa chaguo-msingi: ilisoma Required-Start kutoka kwa kila hati, ikajenga grafu, na kupanga upya namba za symlinks. Debian iliweza kisha kuendesha hati huru kwa wakati mmoja kwa kutumia startpar. Hilo lilisaidia, lakini halikufikia tatizo la msingi zaidi. Utegemezi ulikuwa bado unategemea hati kumaliza kazi. S20nginx kurejesha 0 inamaanisha kuwa shell function imekamilika. Haimaanishi kuwa nginx inakubali miunganisho.

Mambo matano ambayo init script haiwezi kurekebisha

• Kuanza kwa sambamba (Parallel startup). Kupanga huduma kwa kutumia majina ya faili kunalazimisha mpangilio wa kila huduma kwenye mashine, hivyo boot inakuwa polepole kama jumla ya muda wa kila huduma.
• Utayari (Readiness). Script ya kuanza inamaliza kazi mara tu inapozindua daemon, si pale daemon inapokuwa tayari kuhudumia maombi, hivyo script inayofuata mara nyingi huanza mapema mno.
• Usimamizi (Supervision). Daemon hujigawa (fork) mara mbili na mzazi wake huacha kufanya kazi, jambo linaloitenga na terminal na kuifanya iwe chini ya PID 1. init huona mtoto akimaliza kazi na haina njia ya kuaminika ya kufuatilia mchakato uliobakia.
• Kuanza kwa mahitaji (On-demand start). inetd (internet super-server) iliweza kuzindua daemon wakati muunganisho ulipofika, lakini ilikuwa mfumo tofauti wenye faili yake ya usanidi, na haikusaidia katika kupanga huduma nyingine wakati wa boot.
• Udhibiti wa rasilimali (Resource control). Hakuna kitu katika init script kinachoweza kudhibiti kumbukumbu ya huduma au sehemu yake ya CPU. ulimit ilitumika kwa mchakato mmoja na nice iligusa tu scheduler, hivyo mchakato uliotoroka kutoka kwa huduma ulionekana kama mchakato mwingine wowote kwenye seva.

Pengo la usimamizi ndilo lililoleta madhara kila siku. Faili ya PID ilikuwa njia ya mkato: daemon iliandika kitambulisho chake cha mchakato kwenye /run/nginx.pid, na kazi ya kusimamisha (stop function) ilisoma faili hiyo. Ikiwa daemon ilikufa ghafla, faili ilibaki. Kernel ilitumia tena namba hiyo kwa kitu kingine, na start-stop-daemon --stop --pidfile ilituma ishara (signal) kwa chochote kilichokuwa na namba hiyo sasa. Faili ya PID iliyopitwa na wakati ndiyo sababu init script huua mchakato usio sahihi.

launchd ilitatua tatizo la socket kwanza

Apple ilitoa launchd katika Mac OS X 10.4 mwaka 2005, ikiwa imeandikwa na Dave Zarzycki. Mchakato mmoja ulichukua nafasi ya init, rc, xinetd, crond na watchdogd.

Wazo lililostahili kuigwa lilikuwa socket activation. launchd hutengeneza kila socket inayoisikiliza kwanza, kisha huanzisha daemons. Mteja anayeunganisha kwenye daemon ambayo bado haijaanza hapati ujumbe wa connection refused, kwa sababu kernel hushikilia muunganisho kwenye backlog queue ya socket hiyo hadi daemon itakapopiga accept(). Mpangilio kati ya daemons mbili huacha kuwa kitu kinachotangazwa na binadamu. Socket ndiyo inayoshughulikia hilo.

launchd ilijengwa juu ya Mach IPC (inter-process communication), ambayo ni sehemu ya XNU kernel ya Apple na haina mbadala kwenye Linux. Kusafirisha (porting) msimbo huo haukuwa jambo la kweli. Hata hivyo, wazo hilo lilisambaa.

Upstart ilifanya matukio kuwa kitengo cha kazi

Upstart ya Canonical, iliyoandikwa na Scott James Remnant, ilitolewa katika Ubuntu 6.10 mnamo Oktoba 2006. Fedora 9 hadi Fedora 14 ilitumia Upstart, kama ilivyokuwa kwa RHEL 6 na Chrome OS. Ilichukua nafasi ya runlevel kwa tukio, na kazi ilibainisha ni matukio yapi yanayopaswa kuianzisha na kuikomesha.

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

Matatizo mawili yaliibuka kadiri idadi ya kazi ilivyoongezeka. La kwanza ni mwelekeo. Kazi husema "nianzishe tukio hili linapotokea", kwa hivyo maarifa ya nini kinategemea nini yanakaa kwenye faili isiyo sahihi: huduma inajua inachohitaji, na haiwezi kujua nani ataihitaji mwaka ujao. Kuongeza huduma mara nyingi kulimaanisha kuhariri kazi iliyopo ili itoe tukio jipya.

La pili ni ufuatiliaji. Upstart ilifuata daemon inayojigawa (forking daemon) kwa kuhesabu wito wa fork() kwa kutumia ptrace, ambayo uliisanidi kama expect fork au expect daemon. Ukikisia vibaya idadi ya forks, Upstart husimamia mchakato ambao tayari umeshatoka, au husubiri fork ambayo tayari imeshatokea. Dalili yake ni initctl start kukwama bila kutoa kosa, jambo ambalo faili ya kazi haikupi njia ya kulielezea.

Upstart pia ilihitaji wachangiaji kutia saini mkataba wa wachangiaji wa Canonical. Hilo halikuwa kosa la kihandisi, lakini liliathiri nani aliyefanya kazi kwenye mfumo huo.

Kufikiria upya PID 1, Aprili 2010

Mnamo tarehe 30 Aprili 2010, Lennart Poettering alichapisha makala iliyoitwa "Rethinking PID 1". Kay Sievers alifanya kazi kwenye mradi huo pamoja naye. Hoja hiyo ilikuwa na sehemu nne.

• Anza huduma chache. Huduma nyingi zinaweza kusubiri hadi pale kitu kitakapozihitaji.
• Acha kupanga utaratibu wa kuanza huduma ambapo socket inaweza kuashiria utaratibu huo. Fungua socket zote kwa wakati mmoja, kisha uanzishe kila kitu kwa pamoja.
• Fuatilia michakato (processes) kwa kutumia control groups badala ya PID files.
• Elezea huduma katika faili ya deklarativa, ili maelezo moja yafanye kazi kwenye kila distribution.

Toleo la kwanza lilitoka mwaka huo. Fedora 14 ilitoa systemd kama chaguo mnamo Novemba 2010, na Fedora 15 ilifanya iwe chaguo-msingi mnamo Mei 2011.

Kwa nini cgroups zilifanya usimamizi kuwa wa kutegemeka

cgroup (control group) ni kipengele cha kernel kwa ajili ya kupanga michakato (processes) katika makundi, kilichounganishwa kwenye Linux 2.6.24 mnamo mwaka 2008. systemd huweka kila huduma katika cgroup yake yenyewe. Mchakato mwana (child) hurithi cgroup ya mzazi wake, na mchakato usio na upendeleo (unprivileged process) hauwezi kujiondoa kutoka kwenye kundi hilo. Kwa hivyo, double forking haifichi chochote: PID 1 hushikilia seti kamili ya michakato inayomilikiwa na unit, wakati wote. Kusimamisha huduma kunamaanisha kuua kila kitu kilicho ndani ya cgroup yake, jambo ambalo ndilo linalofanywa na KillMode=control-group kwa chaguo-msingi.

systemctl status huchapisha kundi hilo:

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

Kizuizi hicho ndicho jibu kamili kwa tatizo la PID file iliyopitwa na wakati. Hakuna faili inayoweza kupitwa na wakati, kwa sababu orodha hiyo ni hali ya kernel.

Mti huo huo hubeba mipaka, kwa sababu cgroups ziliundwa kwa ajili ya uhasibu kabla ya mtu yeyote kuzitumia kwa ajili ya ufuatiliaji. MemoryMax=, CPUQuota= na TasksMax= ni mstari mmoja kila moja. Kuweka kikomo cha kumbukumbu na CPU kwenye huduma ni faili ya drop-in leo hii, na mnamo 2009 ilikuwa ni patch ya shell script ambayo hakuna aliyeiandika.

Kwa nini kila usambazaji ulibadilika kati ya 2011 na 2015

• Fedora 15, Mei 2011.
• openSUSE 12.1, Novemba 2011.
• Mageia 2, Mei 2012.
• Arch Linux, chaguo-msingi kwa usakinishaji mpya kuanzia Oktoba 2012.
• RHEL 7, Juni 2014.
• SLES 12, Oktoba 2014.
• Debian 8, Aprili 2015.
• Ubuntu 15.04, Aprili 2015.

Sababu zilikuwa za kawaida, ndiyo maana mabadiliko yalikuwa ya haraka.

• Faili moja ya unit hufanya kazi kwenye kila usambazaji, kwa hivyo miradi ya upstream ilianza kusafirisha faili ya .service na usambazaji ukaacha kudumisha hati ya shell kwa kila kifurushi kwa kila toleo.
• Ufuatiliaji wa desktop session ulihamia systemd-logind baada ya ConsoleKit kuacha kudumishwa karibu na 2012. GNOME ilihitaji logind, kwa hivyo usambazaji uliokosa systemd ulilazimika kutafuta mbadala. Mbadala huo, elogind, ni logind ya systemd iliyotolewa na kudumishwa kando.
• udev, meneja wa vifaa, iliunganishwa kwenye mti wa chanzo wa systemd mnamo Aprili 2012. Usambazaji uliokuwa ukisafirisha udev sasa ulikuwa ukifuatilia hazina ya systemd. Gentoo ilifanya fork ya eudev kama jibu.
• Containers zilifanya ufuatiliaji wa mchakato wa kuaminika na vikomo kwa kila huduma kuwa muhimu zaidi, kwa kuwa zote ni vipengele vya cgroup. Swali la ni msimamizi yupi anayemiliki mchakato wa container bado ni hai wakati wowote unapofanya stack ya Docker Compose irudi baada ya reboot.

Uamuzi wa Debian ulikuwa wa kelele. Kamati ya Kiufundi ilipiga kura mnamo Februari 2014, kura zilikuwa sare, na mwenyekiti, Bdale Garbee, alipiga kura ya maamuzi kwa ajili ya systemd. Ubuntu ilitangaza siku chache baadaye kwamba itafuata Debian badala ya kuendelea na Upstart. Kundi la watengenezaji wa Debian lilifanya fork ya usambazaji huo kama Devuan mnamo Novemba 2014 na kutoa Devuan 1.0 mnamo Mei 2017.

Upinzani, uliowasilishwa kwa usawa

Upeo. Mradi mmoja sasa unasafirisha PID 1, daemon ya logi, usimamizi wa session za kuingia, meneja wa vifaa, daemon ya usanidi wa mtandao, resolver ya DNS (domain name system), mteja wa NTP (network time protocol), mkimbizaji wa container na boot loader. Utetezi wa kawaida, kwamba hizi ni binary tofauti ambazo si lazima uzisakinishe, ni wa kweli lakini haujibu upinzani huu. Mara tu desktop inapohitaji logind, na logind ikitolewa kutoka kwenye mti wa systemd, chaguo si huru tena. Hiyo ndiyo maana ya kuunganishwa (coupling) katika hoja hiyo, na imetokea.

Journal ya binary. journald huandika muundo wa binary uliopangwa badala ya matini ya kawaida. Unapata vitu ambavyo matini haikuwahi kukupa: uchujaji kwa kila unit na kwa kila kipaumbele, sehemu zilizopangwa, na metadata ambayo programu inayotuma haiwezi kughushi, kwa sababu journald hurekodi unit na cgroup yenyewe. journalctl -u nginx -p err --since "-1h" huchukua nafasi ya grep yenye regular expression ya tarehe. Gharama yake ni halisi pia. Kwenye mashine ambayo haitaki kuwaka, huwezi kusoma logi kwa less kutoka kwenye rescue shell. Badala yake, unaelekeza journalctl kwenye diski iliyopandishwa (mounted):

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

Kuna mtego wa pili hapa ambao huwanasa watu mara moja. journald huweka logi kwenye /run/log/journal, ambayo ni kumbukumbu, isipokuwa kama /var/log/journal ipo. Kwenye mashine ambayo haipo, journalctl -b -1 haina cha kuonyesha baada ya reboot, wakati ambao ndio hasa ulihitaji logi hizo. Iangalie na uirekebishe:

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 sasa inapaswa kuripoti journal zilizohifadhiwa chini ya /var/log/journal. Ikiwa unataka matini ya kawaida pia, weka ForwardToSyslog=yes katika /etc/systemd/journald.conf na uweke rsyslog ikiwa imesakinishwa.

Uwezo wa kutatua matatizo ya boot. Unit inapokwama, console huonyesha mstari mmoja na hakuna kingine:

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

Zana za kwenda mbali zaidi zipo: systemctl list-jobs wakati imekwama, systemd-analyze blame na systemd-analyze critical-chain baadaye, na systemd.log_level=debug kwenye kernel command line. Toleo la haki la malalamiko haya ni kwamba init script inaweza kusomwa kutoka juu hadi chini na mtu yeyote anayejua sh, wakati unit iliyokwama inahitaji kujua ni amri ipi kati ya kumi na mbili za kutumia. Hiyo ni gharama halisi. Inalipwa mara moja kwa kila msimamizi, na ililipwa na wasimamizi wengi kwa wakati mmoja.

Chaguo-msingi linalobadilika kwa kila mtu. systemd 230 mwaka 2016 ilibadilisha chaguo-msingi la logind ili michakato ya mtumiaji iliyobaki iuawe wakati wa logout. Session za tmux na screen zilizotenganishwa zilikuwa zikifa wakati session iliyozianzisha ilipomalizika. Usambazaji (distributions) ulisafirisha KillUserProcesses=no katika /etc/systemd/logind.conf, na jibu linaloungwa mkono ni loginctl enable-linger <user>. Chaguo-msingi moja katika mradi mmoja ilibadilisha mazoea ambayo mamilioni ya watu walitegemea, ambayo ndiyo maana ya "userland nyingi sana sehemu moja" katika vitendo.

Dependency ya chaguo-msingi ni eneo la usalama. Mnamo Machi 2024, backdoor katika xz-utils ililenga sshd kwenye Debian na Ubuntu. OpenSSH ya juu (upstream) haiunganishi libsystemd. Usambazaji huo uliirekebisha ili sshd iweze kuripoti utayari kwa systemd, na libsystemd ilivuta liblzma, ambapo backdoor ilikuwepo. Itifaki ya utayari yenyewe ni datagram moja inayotumwa kwenye socket iliyotajwa katika $NOTIFY_SOCKET, kwa hivyo hakuna maktaba iliyowahi kuhitajika kwa ajili hiyo. Jibu la systemd lilikuwa kupakia maktaba za mgandamizo (compression) kwa dlopen, ili zisiweze kuunganishwa kwa chaguo-msingi. Aina inayohusiana ya mdudu (bug) inaonyesha sura hiyo hiyo: mwaka 2017 thamani ya User= iliyoanza na tarakimu ilichukuliwa kuwa batili na unit ilifanya kazi kama root badala ya kushindwa, kwa hivyo kosa la kuandika likawa njia ya kupandisha marupurupu (privilege escalation). Matoleo ya baadaye hukataa kuwasha unit hiyo.

Historia kwenye prompt yako ya systemctl

Kila tatizo lililotajwa hapo juu sasa ni maelekezo moja kwenye faili unaloweza kulisoma.

• Serial boot imekuwa After= na Wants=, na systemd-analyze critical-chain inaonyesha kile kilichochelewesha boot yako.
• Readiness imekuwa Type=notify, ambapo huduma huandika READY=1 kwenye $NOTIFY_SOCKET inapokuwa tayari kuhudumia. Type=forking pamoja na PIDFile= bado ipo kwa ajili ya daemons za zamani, na ndiyo aina inayofeli kwa start operation timed out. Terminating. wakati PID file haionekani.
• Supervision imekuwa cgroup, kwa hivyo Restart=on-failure pamoja na RestartSec= inachukua nafasi ya wrapper script, na StartLimitBurst= inazuia crash loop kuendelea milele.
• inetd imekuwa .socket unit iliyokaa kando ya .service unit.
• ulimit imekuwa MemoryMax=, CPUQuota= na TasksMax=.
• Mstari wa su - appuser -c kwenye init script umekuwa User=, NoNewPrivileges=yes na ProtectSystem=strict, kwa hivyo kuendesha huduma kama mtumiaji asiye na upendeleo ndiyo muundo wa kawaida wa unit badala ya kazi ya ziada.

[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

Mstari mmoja kwenye faili hiyo ni kosa ambalo kila mtu hufanya mara moja. Requires=postgresql.service ni hitaji, si mpangilio: inasema unit yako itafeli ikiwa Postgres itafeli, na haisemi iwashe Postgres kwanza. Bila After=postgresql.service zote mbili huanza kwa wakati mmoja, na huduma yako huunganisha kwenye port ambayo hakuna kinachosikiliza bado. Hizi mbili ni tofauti kwa makusudi, kwa sababu wakati mwingine unataka moja bila nyingine. ProtectSystem=strict huweka file system katika hali ya kusoma tu (read-only) kwa huduma hii, ndiyo maana StateDirectory= ipo: inapa huduma njia moja inayoweza kuandikika (writable) chini ya /var/lib.

Mahali dhahiri zaidi pa kuona mwaka 2005 kwenye seva ya 2026 ni SSH kwenye Ubuntu 24.04, ambayo inatumia systemd 255 kufikia Agosti 2026. ssh.service imewezeshwa na socket kwa chaguo-msingi: ssh.socket inashikilia socket inayosikiliza, na sshd huanza wakati muunganisho unapofika. Kwa hivyo Port 2222 kwenye /etc/ssh/sshd_config haina athari, kwa sababu sshd si mchakato uliofungua port hiyo. Mabadiliko hayo yanapaswa kufanyika kwenye socket unit.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

ListenStream= tupu inafuta thamani iliyorithiwa kutoka kwa unit iliyopakiwa. Iache nje na utapata ports zote mbili, kwa sababu systemd huongeza kwenye orodha badala ya kuibadilisha. Kisha tumia na uhakiki, huku ukiwa umeweka session ya pili ya SSH wazi wakati wote:

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

ss inapaswa kuorodhesha socket moja kwenye port 2222 inayomilikiwa na systemd, si na sshd. Huo ndio usanifu wa launchd, miaka ishirini baadaye, kwenye VPS yako. Ikiwa unapendelea tabia ya zamani, sudo systemctl disable --now ssh.socket ikifuatiwa na sudo systemctl enable --now ssh.service inakupa sshd inayoendelea kufanya kazi ambayo inasoma Port kutoka kwenye config yake yenyewe tena.

Ni maelezo yapi kati ya haya utakayokutana nayo inategemea toleo unalotumia, kwa hivyo ni vyema kujua tofauti kati ya toleo la LTS na toleo la muda la Ubuntu kabla ya kupanga upgrade. Katika mashine zaidi ya moja, ukweli kwamba unit file inafanana kila mahali ndiyo sababu kusimamia seva kadhaa kutoka sehemu moja sasa ni tatizo la usanidi badala ya tatizo la shell scripting. Na unapoandika units zako mwenyewe, jozi ya service na timer inafanya kazi ambayo ungeigawanya kati ya init script na mstari wa cron mwaka 2009.

FAQ

Kwa nini usambazaji wa Linux ulichukua nafasi ya SysV init na systemd?

Kwa sababu mbili za kihandisi na sababu moja ya matengenezo. SysV init ilipanga huduma kulingana na jina la faili, ambalo ni nafasi badala ya utegemezi, na ilishindwa kufuatilia daemon yoyote iliyojitenga na mzazi wake, ndiyo maana faili za PID zilizopitwa na wakati zingeweza kuua mchakato usio sahihi. systemd ilitatua upangaji kwa kutumia socket activation na maelekezo ya utegemezi, na ikatatua ufuatiliaji kwa kutumia control groups. Sababu ya matengenezo iliamua kasi: faili moja ya unit hufanya kazi kwenye kila usambazaji, kwa hivyo miradi ya upstream ilisafirisha faili ya .service na watunza usambazaji wakaacha kuandika shell script kwa kila kifurushi. Fedora 15 ilibadilika mnamo Mei 2011 na Ubuntu 15.04 ilikuwa ya mwisho kusita, mnamo Aprili 2015.

Je, systemd ni binary moja kubwa?

Hapana. Source tree hujenga programu nyingi tofauti. PID 1 ni /usr/lib/systemd/systemd, wakati journald, logind na udevd ni michakato tofauti yenye binaries zao; endesha ls /usr/lib/systemd/ ili kuziona kwenye mashine yako. Ukosoaji unaobaki unahusu kuunganishwa kwa matoleo badala ya ukubwa wa binary: programu hizi hutolewa pamoja na kushiriki interfaces za faragha, kwa hivyo usambazaji huelekea kuzichukua kama seti, na programu kama GNOME zilianza kutarajia logind haswa.

Je, bado ninaweza kuendesha Linux bila systemd?

Ndiyo. Devuan inasambaza sysvinit, Gentoo hutumia OpenRC kama chaguo-msingi, Void hutumia runit, Alpine hutumia busybox init na OpenRC, na Slackware huhifadhi scripts za mtindo wa BSD. Gharama ni kazi ya utangamano. Programu za desktop zinazotarajia logind zinahitaji elogind, ambayo ni logind ya systemd inayotunzwa kama kifurushi cha pekee, na kiasi kinachoongezeka cha programu za seva sasa husafirisha faili ya .service pekee, kwa hivyo unaandika na kutunza startup script mwenyewe.

Kwa nini journal ni binary badala ya faili ya maandishi ya kawaida?

Kwa sababu journald huhifadhi sehemu zilizopangwa na index, ambayo inatoa uchujaji kwa kila unit, uchujaji wa kipaumbele, na metadata ambayo programu inayotuma haiwezi kughushi: journald hurekodi unit, cgroup na UID halisi yenyewe badala ya kuamini mstari wa logi. Bei yake ni kwamba unahitaji journalctl ili kuisoma, ikiwa ni pamoja na kutoka kwa mfumo wa uokoaji, ambapo unaielekeza kwenye diski iliyopandishwa (mounted) kwa journalctl --directory /mnt/var/log/journal. Ikiwa unataka maandishi pia, weka ForwardToSyslog=yes katika /etc/systemd/journald.conf.

Nini kilichochukua nafasi ya kuhariri script yangu ya /etc/init.d?

Faili za drop-in. Usihariri unit katika /usr/lib/systemd/system/, kwa sababu uboreshaji wa kifurushi huifuta. Endesha sudo systemctl edit nginx.service na systemd itatengeneza /etc/systemd/system/nginx.service.d/override.conf, ambayo huunganishwa juu ya unit iliyofungashwa. systemctl cat nginx.service inaonyesha matokeo yaliyounganishwa, na systemd-delta inaorodhesha kila override kwenye mashine. Baada ya kuhariri kwa mkono, endesha sudo systemctl daemon-reload, au amri inayofuata itachapisha Warning: The unit file, source configuration file or drop-ins of nginx.service changed on disk.