ซิสเต็มดี
การเริ่มต้นระบบ systemd บนFedora 17
ผู้เขียนต้นฉบับ	เลนนาร์ต โพเอตเตอริง[ 1 ]
นักพัฒนา	ทีม systemd; [ 2 ]ผู้เขียนที่แตกต่างกัน 345 คนในปี 2018 [ 3 ]และผู้เขียนที่แตกต่างกันทั้งหมด 2,032 คน[ 4 ]
ปล่อย	30 มีนาคม 2553 ( 30 มีนาคม 2010 )
เวอร์ชันเสถียร	261 [ 5 ]  / 19 มิถุนายน 2026
เขียนเป็น	ซี
ระบบปฏิบัติการ	ลินุกซ์
พิมพ์	ซอฟต์แวร์ระบบ หัวหน้างานกระบวนการผลิต ผู้จัดการฝ่ายบริการ
ใบอนุญาต	LGPLv2.1+ [ 6 ]
เว็บไซต์	ซิสเต็มดี.ไอโอ
ที่เก็บข้อมูล	github.com/systemd/systemd​​​

systemdเป็นชุดซอฟต์แวร์สำหรับการจัดการระบบและบริการบนLinux ^{[ 7 ]}ที่สร้างขึ้นเพื่อรวมการกำหนดค่าและพฤติกรรมของบริการในLinux เวอร์ชันต่างๆ^{[ 8 ]}ส่วนประกอบหลักคือ ระบบ initที่ใช้ในการบูตพื้นที่ผู้ใช้และจัดการกระบวนการของผู้ใช้นอกจากนี้ยังให้ บริการ daemonและยูทิลิตี้ต่างๆ รวมถึงการจัดการอุปกรณ์ การจัดการการเข้าสู่ระบบ การจัดการการเชื่อมต่อเครือข่าย และการบันทึกเหตุการณ์ ชื่อsystemdเป็นไปตามธรรมเนียมการตั้งชื่อdaemon ของ Unixโดยการต่อท้ายด้วยตัวอักษรd ^{[ 9 ]}และยังเล่นคำกับวลีภาษาฝรั่งเศสSystème D (ความสามารถของบุคคลในการปรับตัวและแก้ไขปัญหาเฉพาะหน้าได้อย่างรวดเร็วเมื่อเผชิญกับปัญหา) ^{[ 10 ]}

ในการแจกจ่าย Linux นั้น systemd ถูกใช้แทนSysvinitและระบบ init อื่นๆ ตั้งแต่ปี 2015 การแจกจ่าย Linux เกือบทั้งหมดได้นำ systemd มาใช้ นักพัฒนาและผู้ใช้ของการแจกจ่ายที่นำ systemd มาใช้ต่างชื่นชมว่า systemd เป็นโซลูชันที่เสถียร รวดเร็ว และพร้อมใช้งานทันทีสำหรับปัญหาต่างๆ ที่มีอยู่ในระบบ Linux มานานหลายปี^{[ 11 ] [ 12 ] [ 13 ]}ในขณะที่นำมาใช้นั้น มันเป็น ระบบบูตและ init แบบขนาน เพียง ระบบเดียวที่ให้การจัดการแบบรวมศูนย์ของกระบวนการ daemon บริการ และจุดเชื่อมต่อ

นักวิจารณ์ของ systemd โต้แย้งว่ามันประสบปัญหาฟีเจอร์ครีปและทำให้ความสามารถในการทำงานร่วมกันระหว่าง ระบบปฏิบัติการ ที่คล้าย Unix เสียหาย (เนื่องจากมันไม่สามารถทำงานบนระบบปฏิบัติการที่พัฒนามาจาก Unix ที่ไม่ใช่ Linux เช่นBSDหรือSolaris ) นอกจากนี้ พวกเขายังโต้แย้งว่าชุดฟีเจอร์ขนาดใหญ่ของ systemd ทำให้เกิดช่องโหว่การโจมตี ที่ ใหญ่ ขึ้น ^{[ 14 ]}ซึ่งนำไปสู่การพัฒนาระบบปฏิบัติการ Linux รุ่นย่อยหลายรุ่นที่แทนที่ systemd ด้วยระบบ init อื่นๆ เช่น SysVinit หรือOpenRC ^{[ 15 ]}

Lennart PoetteringและKay Sieversวิศวกรซอฟต์แวร์ที่ทำงานให้กับRed Hat ในขณะนั้น ซึ่งเป็นผู้พัฒนา systemd ในช่วงแรก^{[ 2 ]}ได้เริ่มโครงการเพื่อแทนที่ init ของ System V แบบดั้งเดิมของ Linux ในปี 2010 ^{[ 16 ]}บทความในบล็อกของ Poettering ในเดือนเมษายน 2010 ที่มีชื่อว่า "Rethinking PID 1" ได้แนะนำเวอร์ชันทดลองของสิ่งที่จะกลายเป็น systemd ในภายหลัง^{[ 17 ]}พวกเขาพยายามที่จะเหนือกว่าประสิทธิภาพของdaemon initในหลายๆ ด้าน พวกเขาต้องการปรับปรุงเฟรมเวิร์กซอฟต์แวร์สำหรับการแสดงการพึ่งพา อนุญาตให้กระบวนการต่างๆ ทำงานพร้อมกันหรือแบบขนานได้ มากขึ้นในระหว่าง การบูตระบบและลดภาระการคำนวณ ของเชลล์

ในเดือนพฤษภาคม พ.ศ. 2554 Fedora Linuxกลายเป็นระบบปฏิบัติการ Linux หลักตัวแรกที่เปิดใช้งาน systemd เป็นค่าเริ่มต้น แทนที่Upstartเหตุผลในขณะนั้นคือ systemd ให้การทำงานแบบขนานอย่างกว้างขวางในระหว่างการเริ่มต้นระบบ การจัดการกระบวนการที่ดีขึ้น และโดยรวมแล้วเป็นแนวทางที่สมเหตุสมผลกว่าโดยอิงตามการพึ่งพาในการควบคุมระบบ^{[ 18 ]}

ในเดือนตุลาคม พ.ศ. 2555 Arch Linuxได้เปลี่ยนจาก SysVinit มาเป็น systemd เป็นค่าเริ่มต้น^{[ 19 ]}นักพัฒนาได้ถกเถียงกันมาตั้งแต่เดือนสิงหาคม พ.ศ. 2555 ^{[ 13 ]}และสรุปว่า systemd เร็วกว่าและมีคุณสมบัติมากกว่า SysVinit และการบำรุงรักษา SysVinit นั้นไม่คุ้มค่า^{[ 20 ]}บางคนคิดว่าคำวิจารณ์เกี่ยวกับ systemd ไม่ได้มาจากข้อบกพร่องที่แท้จริงของซอฟต์แวร์ แต่มาจากความไม่ชอบส่วนตัวที่มีต่อ Poettering และการต่อต้านการเปลี่ยนแปลงโดยทั่วไป ข้อร้องเรียนหลายประการเกี่ยวกับ systemd—รวมถึงการใช้D-bus , C แทนbashและรูปแบบบันทึกบนดิสก์ที่เป็นตัวเลือก—กลับถูกอธิบายว่าเป็นข้อดีโดยผู้ดูแล Arch ^{[ 21 ]}

ระหว่างปี 2013 ถึง 2014 คณะกรรมการด้านเทคนิคของ Debian ได้ถกเถียง กันอย่างกว้างขวาง ในรายชื่อผู้รับจดหมายเกี่ยวกับระบบ init ใดที่จะใช้เป็นค่าเริ่มต้นใน Debian 8 ก่อนที่จะตกลงใช้ systemd ^{[ 22 ] [ 23 ] [ 24 ]}ไม่นานหลังจากนั้น Joey Hess นักพัฒนา Debian ^{[ 25 ] Russ Allbery [ 26 ]}และIan Jackson [ ^{27 ]}สมาชิกคณะกรรมการด้านเทคนิคและ Tollef Fog Heen [ 28 ] ผู้ดูแลแพ็กเกจ systemd ^{ได้ลาออก}จากตำแหน่ง โดยอ้างถึงความเครียดอย่างมากที่เกิดจากข้อพิพาทเกี่ยวกับการบูรณาการ systemd ภายในชุมชน Debian และFOSS ซึ่งทำให้การ ^{บำรุง}รักษาเป็นประจำแทบเป็นไปไม่ได้Mark Shuttleworth ประกาศในเวลาต่อมาว่า Ubuntuที่ใช้ Debian จะใช้ systemd เพื่อแทนที่ ระบบ init Upstartเก่า^{[ 29 ] [ 30 ]}

ในเดือนสิงหาคม พ.ศ. 2558 systemd เริ่มให้บริการเชลล์ล็อกอิน ซึ่งสามารถเรียกใช้งานได้ผ่านmachinectl shellทาง^{[ 31 ]}

ในเดือนกันยายน พ.ศ. 2559 มีการค้นพบ ช่องโหว่ด้านความปลอดภัยที่อนุญาตให้ผู้ใช้ที่ไม่มีสิทธิ์ใดๆ ก็ตามสามารถโจมตีระบบ systemd ด้วยการปฏิเสธการให้บริการได้^{[ 32 ]} Rich Felker ผู้พัฒนาmuslกล่าวว่าช่องโหว่นี้เผยให้เห็น "ข้อบกพร่องในการออกแบบการพัฒนาระบบ" ที่สำคัญ^{[ 33 ]}ในปี พ.ศ. 2560 มีการค้นพบช่องโหว่ด้านความปลอดภัยอีกข้อหนึ่งใน systemd-resolved, CVE - 2017-9445ซึ่ง "อนุญาตให้เกิดการหยุดชะงักของบริการ" โดย "เซิร์ฟเวอร์ DNS ที่เป็นอันตราย" ^{[ 34 ] [ 35 ]}ต่อมาในปี พ.ศ. 2560 รางวัล Pwnie Awardsได้มอบรางวัล "การตอบสนองของผู้จำหน่ายที่แย่ที่สุด" ให้แก่ Lennart Poettering ผู้เขียน เนื่องจากวิธีการจัดการกับช่องโหว่ของเขา^{[ 36 ]}

Poettering อธิบายการพัฒนา systemd ว่า "ไม่มีวันเสร็จสิ้น ไม่มีวันสมบูรณ์ แต่เป็นการติดตามความก้าวหน้าของเทคโนโลยี" ในเดือนพฤษภาคม 2014 Poettering อธิบายเพิ่มเติมว่า systemd เป็นการรวม "ความแตกต่างที่ไร้ประโยชน์ระหว่างการแจกจ่าย" โดยให้ฟังก์ชันทั่วไปสามประการดังต่อไปนี้: ^{[ 39 ]}

• ผู้จัดการระบบและบริการ (ทำหน้าที่จัดการทั้งระบบ โดยการกำหนดค่าต่างๆ และบริการต่างๆ ของระบบ)
• แพลตฟอร์มซอฟต์แวร์ (ทำหน้าที่เป็นพื้นฐานสำหรับการพัฒนาซอฟต์แวร์อื่นๆ)
• ทำหน้าที่เป็นตัวเชื่อมระหว่างแอปพลิเคชันและเคอร์เนล (จัดเตรียมอินเทอร์เฟซต่างๆ ที่เปิดเผยฟังก์ชันการทำงานที่เคอร์เนลมีให้)

systemdประกอบด้วยคุณสมบัติต่างๆ เช่น การเริ่มต้น daemon ตามความต้องการ การสนับสนุนสแนปช็อต การติดตามกระบวนการ^{[ 40 ]}และ Inhibitor Locks ^{[ 41 ]}ไม่ใช่แค่ชื่อของ init daemon เท่านั้น แต่ยังหมายถึงชุดซอฟต์แวร์ทั้งหมดที่อยู่รอบๆ ซึ่งนอกจาก init daemon systemdแล้ว ยังรวมถึง daemon journald , logindและnetworkdและส่วนประกอบระดับต่ำอื่นๆ อีกมากมาย ในเดือนมกราคม 2013 Poettering ได้อธิบาย systemd ไม่ใช่โปรแกรมเดียว แต่เป็นชุดซอฟต์แวร์ขนาดใหญ่ที่ประกอบด้วยไบนารี 69 ตัว^{[ 42 ]} ในฐานะ ชุดซอฟต์แวร์แบบบูรณาการsystemd จะแทนที่ลำดับการเริ่มต้นและระดับการทำงานที่ควบคุมโดย init daemon แบบดั้งเดิม พร้อมกับสคริปต์เชลล์ที่ดำเนินการภายใต้การควบคุมของมัน systemd ยังรวมบริการอื่นๆ อีกมากมายที่พบได้ทั่วไปในระบบ Linux โดยจัดการการเข้าสู่ระบบของผู้ใช้ คอนโซลระบบ การเสียบอุปกรณ์แบบ hotplugging (ดูudev ) การดำเนินการตามกำหนดเวลา (แทนที่cron ) การบันทึก ชื่อโฮสต์ และภาษาท้องถิ่น

เช่นเดียวกับ init daemon, systemdเป็น daemon ที่จัดการ daemon อื่นๆ ซึ่งรวมถึงsystemdเองด้วย ที่เป็นกระบวนการทำงานเบื้องหลัง systemd เป็น daemon แรกที่เริ่มต้นระหว่างการบูตและเป็น daemon สุดท้ายที่สิ้นสุดระหว่างการปิดระบบ daemon systemdทำหน้าที่เป็นรากของโครงสร้างกระบวนการ ในพื้นที่ผู้ใช้ กระบวนการแรก ( PID 1) มีบทบาทพิเศษในระบบ Unix เนื่องจากมันจะเข้ามาแทนที่กระบวนการแม่เมื่อกระบวนการแม่เดิมสิ้นสุด ดังนั้น กระบวนการแรกจึงเหมาะสมอย่างยิ่งสำหรับวัตถุประสงค์ในการตรวจสอบ daemon

systemdดำเนินการองค์ประกอบของลำดับการเริ่มต้นแบบขนาน ซึ่งในทางทฤษฎีจะเร็วกว่าวิธีการลำดับการเริ่มต้นแบบดั้งเดิม^{[ 43 ]}สำหรับการสื่อสารระหว่างกระบวนการ (IPC) systemdทำให้ซ็อกเก็ตโดเมน UnixและD-Busพร้อมใช้งานสำหรับเดมอนที่กำลังทำงานอยู่ สถานะของsystemdเองยังสามารถเก็บรักษาไว้ในสแนปช็อตเพื่อเรียกใช้ในอนาคตได้ อีกด้วย

ด้วยแนวทางการทำงานแบบบูรณาการ systemd ยังมีตัวเลือกทดแทนสำหรับ daemon และยูทิลิตี้ต่างๆ รวมถึงสคริปต์ shell สำหรับการเริ่มต้นระบบ pm-utils, inetd , acpid , syslog , watchdog, cronและatdส่วนประกอบหลักของ systemd ประกอบด้วย:

• systemdคือตัวจัดการระบบและบริการสำหรับระบบปฏิบัติการลินุกซ์
• systemctl เป็นคำสั่งสำหรับตรวจสอบและควบคุมสถานะของระบบ จัดการบริการและตัวจัดการระบบ systemd อย่าสับสนกับsysctl
• สามารถใช้ คำสั่ง systemd-analyzeเพื่อตรวจสอบสถิติประสิทธิภาพการบูตระบบ และดึงข้อมูลสถานะและข้อมูลการติดตามอื่นๆ จากตัวจัดการระบบและบริการได้

systemd ติดตามกระบวนการโดยใช้ระบบย่อย cgroupsของเคอร์เนล Linux แทนการใช้ตัวระบุโปรเซส (PID) ดังนั้น daemon จึงไม่สามารถ "หลบหนี" systemd ได้ แม้กระทั่งโดยการสร้าง กระบวนการ ลูกสองครั้ง (double-fork ) systemdไม่เพียงแต่ใช้ cgroups เท่านั้น แต่ยังเสริมด้วยคุณสมบัติอื่นๆ อีกด้วยsystemd-nspawnและmachinectlเป็นโปรแกรมยูทิลิตี้สองโปรแกรมที่ช่วยอำนวยความสะดวกในการสร้างและจัดการคอนเทนเนอร์Linux ^{[ 44 ]}ตั้งแต่เวอร์ชัน 205 เป็นต้นไป systemd ยังมี ControlGroupInterface ซึ่งเป็น API สำหรับ cgroup ของเคอร์เนล Linux ^{[ 45 ]} cgroup ของเคอร์เนล Linux ได้รับการปรับปรุงเพื่อรองรับkernfs[ ^{46 ]}และกำลังได้รับการแก้ไขเพื่อรองรับลำดับชั้นที่เป็นหนึ่ง^{เดียว[ 47 ]}

นอกเหนือจากวัตถุประสงค์หลักในการจัดหาระบบ init ของ Linux แล้ว ชุดโปรแกรม systemd ยังสามารถให้ฟังก์ชันการทำงานเพิ่มเติมได้ ซึ่งรวมถึงส่วนประกอบต่อไปนี้:

วารสาร

systemd-journaldเป็นโปรแกรมทำงานเบื้องหลังที่รับผิดชอบการบันทึกเหตุการณ์ โดยใช้ ไฟล์ไบนารีแบบเพิ่มข้อมูลอย่างเดียวเป็นไฟล์บันทึกผู้ดูแลระบบสามารถเลือกได้ว่าจะบันทึกเหตุการณ์ของระบบด้วยsystemd-journald , syslog-ngหรือrsyslog

ลิบูเดฟ

libudevคือไลบรารีมาตรฐานสำหรับการใช้งาน udev ซึ่งช่วยให้แอปพลิเคชันจากภายนอกสามารถสอบถามทรัพยากรของ udev ได้

ท้องถิ่น

localedทำหน้าที่จัดการภาษาและรูปแบบแป้นพิมพ์ของ ระบบ

เข้าสู่ระบบ

systemd-logindเป็น daemon ที่จัดการการเข้าสู่ระบบและที่นั่งของผู้ใช้ในรูปแบบต่างๆ เป็นตัวจัดการการเข้าสู่ระบบแบบบูรณาการที่นำเสนอการปรับปรุงmultiseat ^{[ 48 ]}และแทนที่ConsoleKitซึ่งไม่ได้รับการดูแลรักษาอีกต่อไป^{[ 49 ]}สำหรับตัวจัดการการแสดงผล X11การเปลี่ยนไปใช้logindต้องการการพอร์ตเพียงเล็กน้อย^{[ 50 ]}มันถูกรวมเข้าไว้ใน systemd เวอร์ชัน 30

ชื่อโฮสต์

คำสั่ง hostnamedทำหน้าที่จัดการชื่อโฮสต์ของระบบ

บ้าน

homedเป็นโปรแกรมทำงานเบื้องหลัง (daemon) ที่ให้บริการบัญชีผู้ใช้แบบพกพาซึ่งเป็นอิสระจากการกำหนดค่าระบบในปัจจุบันhomed จะย้ายข้อมูลต่างๆ เช่น UID/GID จากที่ต่างๆ ทั่วระบบไฟล์มารวมไว้ในไฟล์เดียว homed จัดการไดเร็กทอรีโฮมของผู้ใช้ได้หลายวิธี เช่น ไดเร็กทอรีธรรมดา ซับโวลุ่มbtrfs โวลุ่ม Linux Unified Key Setupไดเร็กทอรี fscrypt หรือการเมานต์จากเซิร์ฟเวอร์SMB~/.identity

เครือข่าย

networkdเป็น daemon สำหรับจัดการการกำหนดค่าอินเทอร์เฟซเครือข่าย ในเวอร์ชัน 209 เมื่อเริ่มใช้งานครั้งแรก การสนับสนุนจะจำกัดเฉพาะการกำหนดที่อยู่แบบคงที่และการสนับสนุนพื้นฐานสำหรับการกำหนดค่าบริดจ์^{[ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ]}ในเดือนกรกฎาคม 2014 systemd เวอร์ชัน 215 ได้รับการเผยแพร่ โดยเพิ่มคุณสมบัติใหม่ เช่น เซิร์ฟเวอร์ DHCPสำหรับ โฮสต์ IPv4และการสนับสนุนVXLAN ^{[ 56 ] [ 57 ]}networkctlอาจใช้เพื่อตรวจสอบสถานะของลิงก์เครือข่ายตามที่เห็นโดย systemd-networkd ^{[ 58 ]}การกำหนดค่าอินเทอร์เฟซใหม่จะต้องเพิ่มภายใต้ /lib/systemd/network/ เป็นไฟล์ใหม่ที่ลงท้ายด้วยนามสกุล .network

แก้ไขแล้ว

ให้บริการการแปลงชื่อเครือข่ายให้กับแอปพลิเคชันภายในเครื่อง

ซิสเต็มดีบูต

systemd-bootเป็นตัวจัดการการบูต ซึ่งเดิมเรียกว่า gummibootโดย Kay Sievers ได้รวมเข้ากับ systemd ในเวอร์ชัน 220

systemd-bsod

systemd-bsodเป็นโปรแกรมรายงานข้อผิดพลาดที่ใช้ในการสร้างหน้าจอสีน้ำเงินแห่งความตาย (Blue Screen of Death )

systemd-nspawn

systemd-nspawnสามารถใช้เพื่อเรียกใช้คำสั่งหรือระบบปฏิบัติการในคอนเทนเนอร์เนมสเปซได้

กำหนดเวลา

systemd-timedatedเป็นเดมอนที่สามารถใช้ควบคุมการตั้งค่าที่เกี่ยวข้องกับเวลา เช่น เวลาของระบบเขตเวลา ของระบบ หรือการเลือกระหว่างUTCและนาฬิการะบบเขตเวลาท้องถิ่น สามารถเข้าถึงได้ผ่าน D-Bus ^{[ 59 ]}มันถูกรวมเข้าไว้ใน systemd เวอร์ชัน 30

ซิงค์เวลา

timesyncdเป็น เดมอน NTP ฝั่งไคลเอ็นต์ สำหรับซิงโครไนซ์นาฬิการะบบผ่านเครือข่าย

ไฟล์ชั่วคราว

systemd-tmpfilesเป็นยูทิลิตี้ที่ทำหน้าที่จัดการการสร้างและการล้างไฟล์และไดเร็กทอรีชั่วคราว โดยปกติจะทำงานหนึ่งครั้งเมื่อเริ่มต้นระบบ และจากนั้นจะทำงานตามช่วงเวลาที่กำหนด

udevd

udevเป็นตัวจัดการอุปกรณ์สำหรับเคอร์เนล Linuxซึ่งจัดการ ไดเร็กทอรี /devและการกระทำทั้งหมดในพื้นที่ผู้ใช้เมื่อเพิ่ม/ลบอุปกรณ์ รวมถึง การโหลด เฟิร์มแวร์ในเดือนเมษายน 2555 ซอร์สโค้ดของ udev ถูกรวมเข้ากับซอร์สโค้ดของ systemd ^{[ 60 ] [ 61 ]}เพื่อให้ตรงกับหมายเลขเวอร์ชันของ udev ผู้ดูแล systemd ได้เพิ่มหมายเลขเวอร์ชันโดยตรงจาก 44 เป็น 183 ^{[ 62 ]}

เมื่อวันที่ 29 พฤษภาคม 2557 การสนับสนุนการโหลดเฟิร์มแวร์ผ่าน udev ถูกยกเลิกจาก systemd เนื่องจากมีการตัดสินใจว่าเคอร์เนลควรรับผิดชอบในการโหลดเฟิร์มแวร์^{[ 63 ]}

systemdสามารถกำหนดค่าได้ผ่านไฟล์ข้อความธรรมดาเท่านั้นแม้ว่าจะมีเครื่องมือ GUI เช่น systemd-manager ให้ใช้งานได้เช่นกัน

systemdบันทึกคำสั่งเริ่มต้นสำหรับแต่ละ daemon ในไฟล์การกำหนดค่า (เรียกว่า "ไฟล์หน่วย") ซึ่งใช้ภาษาเชิงประกาศ แทนที่ สคริปต์เชลล์เริ่มต้นต่อ daemon ที่ใช้กันทั่วไป ไวยากรณ์ของภาษานี้ได้รับแรงบันดาลใจจากไฟล์ . ini ^{[ 64 ]}

ประเภทไฟล์หน่วย^{[ 65 ]}ประกอบด้วย:

• .บริการ
• ซ็อกเก็ต
• .อุปกรณ์ (เริ่มต้นโดยอัตโนมัติโดย systemd ^{[ 66 ]} )
• .mount
• .automount
• .แลกเปลี่ยน
• .เป้า
• .เส้นทาง
• .timer (ซึ่งสามารถใช้เป็นตัวกำหนดตารางเวลางานแบบcron ได้ ^{[ 67 ]} )
• .สแนปช็อต
• .slice (ใช้สำหรับจัดกลุ่มและจัดการกระบวนการและทรัพยากร^{[ 68 ]} )
• .scope (ใช้สำหรับจัดกลุ่มกระบวนการทำงาน ไม่ได้มีจุดประสงค์เพื่อกำหนดค่าผ่านไฟล์หน่วย^{[ 69 ]} )

ในขณะที่ดิสทริบิวชันจำนวนมากบูต systemd เป็นค่าเริ่มต้น แต่บาง ดิสทริ บิวชันก็อนุญาตให้ใช้ระบบ init อื่นๆ ได้ ในกรณีนี้ การเปลี่ยนระบบ init สามารถทำได้โดยการติดตั้งแพ็กเกจที่เหมาะสม Devuan ซึ่งเป็น เวอร์ชันแยกของ Debian ได้รับการพัฒนาขึ้นเพื่อหลีกเลี่ยง systemd ^{[ 99 ] [ 100 ]}และได้พัฒนามาถึงเวอร์ชัน 5.0 สำหรับการใช้งานที่เสถียร ในเดือนธันวาคม 2019 โครงการ Debian ได้ลงมติเห็นชอบให้คง systemd ไว้เป็นระบบ init เริ่มต้นสำหรับดิสทริบิวชัน แต่ให้การสนับสนุน "การสำรวจทางเลือกอื่นๆ" ^{[ 101 ]}

เพื่อเพิ่มความสามารถในการทำงานร่วมกันระหว่าง systemd และ สภาพแวดล้อมเดสก์ท็อป GNOME Lennart Poettering ผู้ร่วมเขียน systemd ได้ขอให้โครงการ GNOMEพิจารณาทำให้ systemd เป็นส่วนประกอบ ภายนอก ของ GNOME 3.2 ^{[ 102 ]}

ในเดือนพฤศจิกายน พ.ศ. 2555 โครงการ GNOME สรุปว่าฟังก์ชันการทำงานพื้นฐานของ GNOME ไม่ควรพึ่งพา systemd ^{[ 103 ]}อย่างไรก็ตาม GNOME 3.8 ได้แนะนำตัวเลือกในการคอมไพล์ระหว่าง API logindและ ConsoleKit โดยที่ logind นั้นมีให้ใช้งานเฉพาะโดย systemd ในขณะนั้น Ubuntu ได้จัดเตรียม ไบนารี logind แยกต่างหาก แต่ systemd กลายเป็น ส่วนประกอบ ที่จำเป็นของ GNOME สำหรับการแจกจ่าย Linux ส่วนใหญ่ โดยเฉพาะอย่างยิ่งเนื่องจาก ConsoleKit ไม่ได้รับการบำรุงรักษาอย่างต่อเนื่องอีกต่อไป และผู้พัฒนาหลักแนะนำให้ใช้systemd-logindแทน^{[ 104 ]}นักพัฒนาGentoo Linuxพยายามปรับใช้การเปลี่ยนแปลงเหล่านี้ในOpenRC เช่นกัน แต่การใช้งานมีข้อบกพร่องมากเกินไป ทำให้การแจกจ่ายระบุ systemd เป็นส่วนประกอบที่จำเป็นของ GNOME ^{[ 105 ] [ 106 ]}

GNOME ได้รวมlogindเข้าไป ด้วย ^{[ 107 ]}ตั้งแต่Mutterเวอร์ชัน 3.13.2 เป็นต้นไปlogind ถือเป็นส่วนประกอบที่จำเป็นสำหรับเซสชันWayland ^{[ 108 ]}

การออกแบบของ systemd ได้ก่อให้เกิดข้อโต้แย้งภายในชุมชนซอฟต์แวร์เสรีนักวิจารณ์มองว่า systemd มีความซับซ้อนมากเกินไปและประสบปัญหาจากการเพิ่มฟีเจอร์ อย่างต่อเนื่อง โดยโต้แย้งว่าสถาปัตยกรรมของมันขัดกับปรัชญาของ Unixนอกจากนี้ยังมีความกังวลว่ามันสร้างระบบการพึ่งพาที่เชื่อมโยงกัน ทำให้ผู้ดูแลการแจกจ่ายแทบไม่มีทางเลือกอื่นนอกจากต้องนำ systemd มาใช้เมื่อซอฟต์แวร์ในพื้นที่ผู้ใช้พึ่งพาส่วนประกอบของมันมากขึ้น^{[ 109 ]}

ในการสัมภาษณ์เมื่อปี 2555 Patrick Volkerdingหัวหน้าทีมSlackwareได้แสดงความกังวลเกี่ยวกับสถาปัตยกรรม systemd โดยระบุว่าเขาเชื่อว่าการออกแบบนั้นขัดกับปรัชญาของ Unix ในเรื่องยูทิลิตี้ที่เชื่อมต่อกันซึ่งมีฟังก์ชันการทำงานที่กำหนดไว้อย่างแคบ^{[ 110 ]}ณ เดือนสิงหาคม 2561 Slackware ไม่รองรับหรือใช้งาน systemd แต่ Volkerding ก็ไม่ได้ตัดความเป็นไปได้ที่จะเปลี่ยนไปใช้ systemd ออกไป^{[ 111 ]}

ในเดือนมกราคม พ.ศ. 2556 Lennart Poettering พยายามแก้ไขข้อกังวลเกี่ยวกับ systemd ในบทความบล็อกชื่อ The ^Biggest Myths [ ^{42 ]}

ในเดือนกุมภาพันธ์ พ.ศ. 2557 Rich Felker จากmusl แสดงความคิดเห็นว่า PID 1 นั้นพิเศษเกินกว่าที่จะต้องรับภาระหน้าที่เพิ่มเติม โดยเชื่อว่า PID 1 ควรรับผิดชอบเพียงแค่การเริ่มต้นระบบ init ที่เหลือและกำจัดกระบวนการซอมบี้เท่านั้น และฟังก์ชันเพิ่มเติมที่เพิ่มโดย systemd สามารถจัดหาได้จากที่อื่นและไม่ได้เพิ่มความซับซ้อนและช่องโหว่การโจมตีของ PID 1 อย่างที่ควรจะเป็น^{[ 112 ]}

ในเดือนมีนาคม พ.ศ. 2557 Eric S. Raymondแสดงความคิดเห็นว่าเป้าหมายการออกแบบของ systemd มีแนวโน้มที่จะขยายขอบเขตภารกิจและทำให้ซอฟต์แวร์มีขนาดใหญ่เกินไป [ ^{113 ] ใน}เดือนเมษายน พ.ศ. 2557 Linus Torvaldsแสดงความกังวลเกี่ยวกับทัศนคติของKay Sieversนักพัฒนาหลักของ systemd ที่มีต่อผู้ใช้และรายงานข้อบกพร่องเกี่ยวกับการแก้ไขเคอร์เนล Linux ที่ส่งโดย Sievers ^{[ 114 ]}ในช่วงปลายเดือนเมษายน พ.ศ. 2557 ได้มีการเปิดตัวแคมเปญคว่ำบาตร systemd โดยมีเว็บไซต์ที่แสดงรายการเหตุผลต่างๆ ที่คัดค้านการนำไปใช้^{[ 115 ] [ 116 ]}

ในบทความเดือนสิงหาคม 2014 ที่ตีพิมพ์ในInfoWorld Paul Venezia ได้เขียนเกี่ยวกับข้อโต้แย้งเรื่อง systemd และระบุว่าข้อโต้แย้งดังกล่าวเกิดจากการละเมิดปรัชญาของ Unix และเกิดจาก "อัตตาอันใหญ่หลวงที่เชื่อมั่นอย่างแน่วแน่ว่าตนเองไม่สามารถทำอะไรผิดได้" ^{[ 117 ]}บทความนี้ยังอธิบายลักษณะสถาปัตยกรรมของ systemd ว่าคล้ายคลึงกับsvchost.exeซึ่งเป็นส่วนประกอบระบบที่สำคัญในMicrosoft Windowsที่มีขอบเขตการทำงานที่กว้างขวาง^{[ 117 ]}

ใน การสัมภาษณ์ กับ ZDNet เมื่อเดือนกันยายน 2014 Theodore Ts'oนักพัฒนาเคอร์เนล Linux ที่มีชื่อเสียงได้แสดงความคิดเห็นว่าข้อพิพาทเกี่ยวกับปรัชญาการออกแบบส่วนกลางของ systemd มากกว่าข้อกังวลทางเทคนิค บ่งชี้ถึงแนวโน้มทั่วไปที่อันตรายในการทำให้ระบบนิเวศ Linux เป็นมาตรฐานเดียวกัน ทำให้ชุมชนโอเพนซอร์สบางส่วนถูกกีดกันและถูกลดบทบาทลง และเหลือพื้นที่น้อยสำหรับโครงการทางเลือก เขาอ้างถึงความคล้ายคลึงกับทัศนคติที่เขาพบในโครงการ GNOME ที่มีต่อการกำหนดค่าที่ไม่เป็นมาตรฐาน^{[ 118 ]}ต่อมา Ts'o ยังเปรียบเทียบทัศนคติของ Sievers และ Lennart Poettering ผู้ร่วมพัฒนาของเขากับนักพัฒนาของ GNOME บนโซเชียลมีเดียอีกด้วย^{[ 119 ]}

การแยกสาขาของ systemd เกี่ยวข้องอย่างใกล้ชิดกับการวิจารณ์ที่กล่าวไว้ในส่วนด้านบน โดยทั่วไปแล้ว การแยกสาขาจะพยายามปรับปรุงอย่างน้อยหนึ่งอย่างในด้านความสามารถในการพกพา (ไปยัง libcs ​​อื่นๆ และระบบที่คล้าย Unix) ความเป็นโมดูล หรือขนาด การแยกสาขาบางส่วนได้ร่วมมือกันภายใต้แบนเนอร์ FreeInit ^{[ 120 ]}

ในปี 2012 โครงการ Gentoo Linuxได้สร้างforkของudevเพื่อหลีกเลี่ยงการพึ่งพาสถาปัตยกรรม systemd fork ที่ได้นั้นเรียกว่าeudevและทำให้ฟังก์ชันการทำงานของ udev สามารถใช้งานได้โดยไม่ต้องใช้ systemd ^{[ 121 ]}เป้าหมายที่ระบุไว้ของโครงการคือการทำให้ eudev เป็นอิสระจากการแจกจ่าย Linux หรือระบบ init ใดๆ^{[ 122 ]}ในปี 2021 Gentoo ประกาศว่าจะยุติการสนับสนุน eudev ในช่วงต้นปี 2022 ตั้งแต่นั้นมากลุ่มผู้ดูแลอิสระได้เข้ามาดูแล eudev ต่อ^{[ 123 ]}

Elogind คือ "logind" ของโครงการ systemd ซึ่งแยกออกมาเป็น daemon แบบสแตนด์อโลน มันทำงานร่วมกับ PAM เพื่อทราบชุดของผู้ใช้ที่ล็อกอินเข้าสู่ระบบ และไม่ว่าพวกเขาจะล็อกอินผ่านกราฟิก ผ่านคอนโซล หรือจากระยะไกล Elogind เปิดเผยข้อมูลนี้ผ่าน อินเทอร์เฟซ D-Bus มาตรฐาน org.freedesktop.login1 รวมถึงผ่านระบบไฟล์โดยใช้ โครงสร้าง /run/systemd มาตรฐานของ systemd นอกจากนี้ Elogind ยังมี "libelogind" ซึ่งเป็นส่วนย่อยของฟังก์ชันที่ "libsystemd" นำเสนอ และยังมี ไฟล์ pkg-config "libelogind.pc" อีกด้วย^{[ 124 ]}

ConsoleKit ถูกแยกออกมาในเดือนตุลาคม 2014 โดย นักพัฒนา Xfceที่ต้องการให้ฟีเจอร์ต่างๆ ยังคงได้รับการบำรุงรักษาและใช้งานได้บนระบบปฏิบัติการอื่นๆ นอกเหนือจาก Linux แม้ว่าจะไม่ได้ตัดความเป็นไปได้ที่จะฟื้นฟูคลังเก็บข้อมูลเดิมในระยะยาว แต่นักพัฒนาหลักถือว่า ConsoleKit2 เป็นสิ่งจำเป็นชั่วคราวจนกว่า systembsd จะสมบูรณ์^{[ 125 ]}

LoginKit เป็นความพยายามในการใช้งานshim ของ logind (systemd-logind) ซึ่งจะช่วยให้แพ็กเกจที่ขึ้นอยู่กับ systemd-logind สามารถทำงานได้โดยไม่ต้องพึ่งพาระบบ init เฉพาะ^{[ 126 ]}โครงการนี้หยุดดำเนินการตั้งแต่เดือนกุมภาพันธ์ 2015 ^{[ 127 ]}

ในปี 2014 โครงการ Google Summer of Codeที่ชื่อว่า "systembsd" ได้เริ่มต้นขึ้นเพื่อจัดหาการใช้งานทางเลือกของ API เหล่านี้สำหรับOpenBSDผู้พัฒนาโครงการดั้งเดิมเริ่มต้นโครงการนี้เพื่อช่วยให้การเปลี่ยนจาก Linux ไปเป็น OpenBSD ง่ายขึ้น^{[ 128 ]}การพัฒนาโครงการเสร็จสิ้นในเดือนกรกฎาคม 2016 ^{[ 129 ]}

โครงการ systembsd ไม่ได้จัดหาการทดแทน init แต่มีจุดมุ่งหมายเพื่อให้ OpenBSD มี daemon ที่เข้ากันได้สำหรับhostnamed , timedated , localedและlogindโครงการนี้ไม่ได้สร้างฟังก์ชันการทำงานใหม่ที่คล้ายกับ systemd และมีจุดประสงค์เพียงเพื่อทำหน้าที่เป็น wrapper เหนือระบบ OpenBSD ดั้งเดิม นักพัฒนาตั้งเป้าหมายให้ systembsd สามารถติดตั้งได้เป็นส่วนหนึ่งของชุด portsไม่ใช่เป็นส่วนหนึ่งของระบบพื้นฐาน โดยระบุว่า "systemd และ *BSD แตกต่างกันโดยพื้นฐานในแง่ของปรัชญาและแนวทางการพัฒนา" ^{[ 128 ]}

Notsystemd มีจุดประสงค์เพื่อนำคุณสมบัติทั้งหมดของ systemd มาใช้โดยทำงานบนระบบ init ใดๆ ก็ได้^{[ 130 ]}มันถูกแยกออกมาโดย นักพัฒนา Parabola GNU/Linux-libreเพื่อสร้างแพ็กเกจด้วยเครื่องมือพัฒนาของพวกเขาโดยไม่จำเป็นต้องติดตั้ง systemd เพื่อเรียกใช้ systemd-nspawn การพัฒนาหยุดลงในเดือนกรกฎาคม 2018 ^{[ 131 ]}

ในปี 2014 uselessdถูกสร้างขึ้นเป็นเวอร์ชันที่เบากว่าของ systemd โครงการนี้มุ่งที่จะลบคุณสมบัติและโปรแกรมที่ถือว่าไม่จำเป็นสำหรับระบบ init รวมถึงแก้ไขข้อผิดพลาดอื่นๆ ที่พบ^{[ 132 ]}การพัฒนาโครงการหยุดลงในเดือนมกราคม 2015 ^{[ 133 ]}

uselessd รองรับ ไลบรารี muslและμClibcดังนั้นจึงอาจถูกนำไปใช้ในระบบฝังตัวในขณะที่ systemd รองรับเฉพาะglibc เท่านั้น โครงการ uselessd วางแผนที่จะปรับปรุงความเข้ากันได้ข้ามแพลตฟอร์มเพิ่มเติม รวมถึงการปรับปรุงโครงสร้างและปรับโครงสร้างใหม่สำหรับการสร้าง Linux ในอนาคต^{[ 134 ]}

InitWare เป็นการปรับโครงสร้างโมดูลาร์ของ systemd โดยพอร์ตระบบไปยังแพลตฟอร์ม BSD โดยไม่ต้องใช้ glibc หรือการเรียกใช้ระบบเฉพาะของ Linux เป็นที่ทราบกันว่าใช้งานได้บน DragonFly BSD, FreeBSD, NetBSD และ GNU/Linux ส่วนประกอบที่ถือว่าไม่จำเป็นจะถูกตัดออก^{[ 135 ]}

All Systems Go! คือการประชุม systemd ประจำปี ซึ่งจัดขึ้นที่เบอร์ลิน^{[ 136 ]}หัวข้อหลักคือ systemd แต่ยังครอบคลุมพื้นที่ Linux อื่นๆ ด้วย เช่นTPM , DBus , สภาพแวดล้อมเดสก์ท็อป , คอนเทนเนอร์ , eBPFเป็นต้น

• บัสซี่บ็อกซ์
• เปิดตัว
• ระบบปฏิบัติการลินุกซ์ที่ไม่มี systemd
• การจัดการบริการระบบปฏิบัติการ
• อ่านล่วงหน้า
• รูนิต
• สิ่งอำนวยความสะดวกในการจัดการบริการ
• จีเอ็นยู เดมอน เชพเพิร์ด
• อัพสตาร์ท
• svchost.exe

• เว็บไซต์อย่างเป็นทางการ
• SystemdบนGitHub
• การทบทวน PID 1