อัพเดทปี 2016
คำตอบส่วนใหญ่ที่นี่มีอายุห้าขวบจึงถึงเวลาสำหรับการอัปเดตบางอย่าง
อูบุนตูเคยใช้งานเครื่องพุ่งพรวดโดยปริยาย แต่พวกเขาก็ทิ้งไว้เมื่อปีที่แล้วเพื่อประโยชน์ของ systemd - ดู:
เนื่องจากการที่มีบทความดี ๆSystemd สำหรับผู้ใช้พุ่งพรวดบน Ubuntu wiki - การเปรียบเทียบรายละเอียดมากระหว่าง upstart และ systemd และคู่มือการเปลี่ยนจากพุ่งพรวดเป็น systemd
(โปรดทราบว่าตามวิกิ Ubuntuคุณยังสามารถเรียกใช้พุ่งพรวดบน Ubuntu รุ่นปัจจุบันโดยค่าเริ่มต้นโดยการติดตั้งupstart-sysvและเรียกใช้sudo update-initramfs -uแต่พิจารณาขอบเขตของโครงการ systemd ฉันไม่ทราบวิธีการทำงานในทางปฏิบัติหรือไม่ว่า systemd เป็นหรือไม่ สามารถถอนการติดตั้ง)
ข้อมูลส่วนใหญ่ในส่วนคำสั่งและสคริปต์ด้านล่างได้รับการดัดแปลงจากตัวอย่างบางส่วนที่ใช้ในบทความนั้น (ซึ่งได้รับอนุญาตอย่างสะดวกสบายเช่นเดียวกับการมีส่วนร่วมของผู้ใช้ Stack Exchange ภายใต้สิทธิ์การใช้งาน Creative Commons Attribution-ShareAlike 3.0 )
นี่คือการเปรียบเทียบคำสั่งทั่วไปและสคริปต์อย่างง่าย ๆ ดูหัวข้อด้านล่างสำหรับคำอธิบายโดยละเอียด คำตอบนี้เป็นการเปรียบเทียบพฤติกรรมเก่าของระบบที่ใช้ระบบพุ่งพรวดกับพฤติกรรมใหม่ของระบบที่ใช้ระบบตามที่ถามในคำถาม แต่โปรดทราบว่าคำสั่งที่ติดแท็กเป็น "ระบบพุ่งพรวด" ไม่จำเป็นต้องเป็นระบบพุ่งพรวดเฉพาะ - เป็นเรื่องปกติสำหรับทุกระบบที่ไม่ใช่ systemd Linux และ Unix
คำสั่ง
ใช้งาน su:
- พุ่งพรวด:
su
- systemd:
machinectl shell
(ดูหัวข้อ "การแทนที่คำสั่ง su" ด้านล่าง)
วิ่งหน้าจอ:
- พุ่งพรวด:
screen
- systemd:
systemd-run --user --scope screen
(ดูส่วน "การฆ่ากระบวนการพื้นหลังที่ไม่คาดคิด" ด้านล่าง)
ใช้ tmux:
- พุ่งพรวด:
tmux
- systemd:
systemd-run --user --scope tmux
(ดูส่วน "การฆ่ากระบวนการพื้นหลังที่ไม่คาดคิด" ด้านล่าง)
การเริ่มงาน foo:
- พุ่งพรวด:
start foo
- systemd:
systemctl start foo
การหยุดงาน foo:
- พุ่งพรวด:
stop foo
- systemd:
systemctl stop foo
การเริ่มงานใหม่ foo:
- พุ่งพรวด:
restart foo
- systemd:
systemctl restart foo
รายการงาน:
- พุ่งพรวด:
initctl list
- systemd:
systemctl status
การตรวจสอบการกำหนดค่าของ job foo:
- พุ่งพรวด:
init-checkconf /etc/init/foo.conf
- systemd:
systemd-analyze verify /lib/systemd/system/foo.service
การระบุตัวแปรสภาพแวดล้อมของงาน:
- พุ่งพรวด:
initctl list-env
- systemd:
systemctl show-environment
การตั้งค่าตัวแปรสภาพแวดล้อมของงาน:
- พุ่งพรวด:
initctl set-env foo=bar
- systemd:
systemctl set-environment foo=bar
การลบตัวแปรสภาพแวดล้อมของงาน:
- พุ่งพรวด:
initctl unset-env foo
- systemd:
systemctl unset-environment foo
ท่อน
ในพุ่งพรวดบันทึกเป็นไฟล์ข้อความปกติในไดเรกทอรี / var / log / upstart ดังนั้นคุณสามารถประมวลผลได้ตามปกติ:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
ในบันทึกของ systemd จะถูกเก็บไว้ในรูปแบบไบนารีภายใน (ไม่ใช่ไฟล์ข้อความ) ดังนั้นคุณต้องใช้journalctlคำสั่งเพื่อเข้าถึง:
sudo journalctl -u foo
sudo journalctl -u foo -f
สคริป
ตัวอย่างสคริปต์ธรรมดาที่เขียนใน/etc/init/foo.conf:
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
ตัวอย่างสคริปต์ systemd ที่เขียนใน/lib/systemd/system/foo.service:
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
การแทนที่คำสั่ง su
การsuแทนที่คำสั่งถูกรวมเข้ากับ systemd ในคำขอดึง # 1022:
เพราะตามเลนนาร์ตโพ็ตเตอริ ง , "su เป็นจริงแนวคิดเสีย"
เขาอธิบายว่า"คุณสามารถใช้ su sudo และเป็นมาก่อน แต่ไม่ได้คาดหวังว่ามันจะทำงานในเต็มรูปแบบ "
วิธีการอย่างเป็นทางการเพื่อให้บรรลุsuพฤติกรรมที่คล้ายกันคือตอนนี้:
machinectl shell
มีการอธิบายเพิ่มเติม
โดย Lennart Poettering
ในการอภิปรายเพื่อออก # 825:
"มีการพูดคุยกันมานานเกี่ยวกับเรื่องนี้ แต่ปัญหาก็คือสิ่งที่ซูควรทำนั้นไม่ชัดเจนมาก [... ] เรื่องสั้นเรื่องสั้น: su เป็นแนวคิดที่แตกสลายจริง ๆ แล้วมันจะทำให้คุณเป็นเหมือนเปลือกหอย และมันก็ดีที่จะใช้มัน แต่นั่นไม่ใช่การเข้าสู่ระบบที่สมบูรณ์และไม่ควรเข้าใจผิดว่าเป็นอย่างใดอย่างหนึ่ง " - Lennart Poettering
ดูสิ่งนี้ด้วย:
การฆ่ากระบวนการพื้นหลังที่ไม่คาดคิด
คำสั่งที่ชอบ:
ไม่ทำงานตามที่คาดไว้ ตัวอย่างเช่นnohupเป็นคำสั่ง POSIX เพื่อให้แน่ใจว่ากระบวนการทำงานต่อไปหลังจากที่คุณออกจากระบบ มันไม่ทำงานบน systemd อีกต่อไป นอกจากนี้โปรแกรมที่ต้องการscreenและtmuxจำเป็นต้องเรียกใช้ในลักษณะพิเศษมิฉะนั้นกระบวนการที่คุณใช้กับโปรแกรมจะถูกฆ่า (ในขณะที่ไม่ได้รับกระบวนการที่ถูกฆ่ามักเป็นสาเหตุหลักของการเรียกใช้หน้าจอหรือ tmux ในตอนแรก)
นี่ไม่ใช่ความผิดพลาด แต่เป็นการตัดสินใจโดยเจตนาดังนั้นจึงไม่น่าจะมีการแก้ไขในอนาคต นี่คือสิ่งที่ Lennart Poettering พูดเกี่ยวกับปัญหานี้:
ในมุมมองของฉันมันค่อนข้างแปลกที่ UNIX นั้นโดยค่าเริ่มต้นปล่อยให้รหัสผู้ใช้เองตามอำเภอใจไม่ จำกัด หลังจากออกจากระบบ ได้มีการพูดคุยกันมานานแล้วในหมู่คน OS หลาย ๆ คนซึ่งสิ่งนี้ควรเป็นไปได้ แต่ไม่แน่นอนว่าเป็นค่าเริ่มต้น แต่ไม่มีใครกล้าที่จะพลิกสวิตช์เพื่อเปลี่ยนจากค่าเริ่มต้นเป็นตัวเลือก การไม่ทำความสะอาดเซสชันผู้ใช้หลังจากออกจากระบบไม่เพียง แต่น่าเกลียดและค่อนข้างแฮ็ก แต่ยังเป็นปัญหาด้านความปลอดภัย ในที่สุด systemd 230 ก็พลิกสวิตช์และในที่สุดก็ทำความสะอาดทุกอย่างได้อย่างถูกต้องเมื่อผู้ใช้ออกจากระบบ
สำหรับข้อมูลเพิ่มเติมดู:
แนวคิดการเริ่มต้นระดับสูง
ในทางที่ systemd ทำงานไปข้างหลัง - ในงานพุ่งพรวดเริ่มต้นทันทีที่พวกเขาสามารถและในงาน systemd เริ่มเมื่อพวกเขาต้อง ในตอนท้ายของวันงานเดียวกันสามารถเริ่มต้นได้โดยทั้งสองระบบและในลำดับเดียวกัน แต่คุณคิดว่ามันมองจากทิศทางตรงกันข้ามเพื่อพูด
นี่คือวิธีที่Systemd สำหรับผู้ใช้พุ่งพรวดอธิบาย:
รูปแบบของการพุ่งพรวดสำหรับกระบวนการเริ่มต้น (งาน) คือ "โลภเหตุการณ์ตาม" นั่นคืองานที่มีอยู่ทั้งหมดซึ่งเหตุการณ์เริ่มต้นเกิดขึ้นจะเริ่มเร็วที่สุดเท่าที่จะเป็นไปได้ ในระหว่างการบูตการพุ่งพรวดสังเคราะห์เหตุการณ์เริ่มต้นบางอย่างเช่นการเริ่มต้นหรือ rcS เป็น "ทรีราก" บริการเริ่มต้นที่จะเริ่มต้นเหล่านั้นและบริการในภายหลังจะเริ่มต้นเมื่ออดีตกำลังทำงานอยู่ งานใหม่เพียงต้องการติดตั้งไฟล์กำหนดค่าลงใน / etc / init / เพื่อให้สามารถใช้งานได้
โมเดลของsystemdสำหรับกระบวนการเริ่มต้น (หน่วย) คือ "อิงการพึ่งพาแบบอิง" คือหน่วยจะเริ่มทำงานก็ต่อเมื่อและเมื่อยูนิตเริ่มต้นอื่น ๆ ขึ้นอยู่กับมัน ในระหว่างการบู๊ต systemd จะเริ่ม "รูทยูนิต" (default.target สามารถแทนที่ได้ในด้วง) ซึ่งจะขยายและเริ่มขึ้นต่อเนื่อง หน่วยใหม่ต้องเพิ่มตัวเองเป็นการพึ่งพาหน่วยของลำดับการบู๊ต (โดยทั่วไปคือ multi-user.target) เพื่อให้สามารถใช้งานได้
การใช้งานในการแจกแจง
ตอนนี้มีข้อมูลล่าสุดตาม Wikipedia:
การแจกแจงที่ใช้พุ่งพรวดโดยค่าเริ่มต้น:
การแจกแจงโดยใช้ systemd โดยค่าเริ่มต้น:
(ดูวิกิพีเดียสำหรับข้อมูลล่าสุด)
การแจกแจงโดยไม่ใช้ทั้งการพุ่งพรวดหรือ systemd:
การทะเลาะวิวาท
ในอดีตที่ผ่านส้อมของ Debian ได้รับการเสนอเพื่อหลีกเลี่ยงการ systemd Devuan GNU + ลินุกซ์ถูกสร้างขึ้น - แยกของ Debian โดยไม่ต้อง systemd (ขอบคุณfpmurphy1สำหรับการชี้มันออกมาในการแสดงความคิดเห็น)
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการโต้แย้งนี้ดู:
อย่างที่หลายคนอาจจะรู้แล้วการออกเสียงลงคะแนน Init GR Debian ที่ได้รับการสนับสนุนโดย Ian Jackson นั้นไม่มีประโยชน์ในการปกป้องมรดกของ Debian และผู้ใช้จากหิมะถล่ม systemd
สถานการณ์นี้ทำให้เกิดการล็อคในการพึ่งพา systemd ซึ่งเป็นสิ่งที่คุกคามความเป็นอิสระของการพัฒนาและมีผลกระทบร้ายแรงสำหรับ Debian, ต้นน้ำและปลายน้ำ
CTTE จัดการเพื่อสลับการพึ่งพาและทำให้เรามีเวลาในการติดตั้ง systemd ผ่าน sysvinit ที่ละเอียดอ่อน แต่กระบวนการนี้ก็เหนื่อยและเต็มไปด้วยละคร ในที่สุดหนึ่งสัปดาห์ที่ผ่านมา Ian Jackson ลาออก [ ... ]
ฉันลาออกจากคณะกรรมการด้านเทคนิคโดยมีผลทันที
ในขณะที่มันเป็นสิ่งสำคัญที่มุมมองของ 30-40% ของโครงการที่เห็นด้วยกับฉันควรจะยังคงเป็นตัวแทนใน TC ฉันเองก็เห็นได้ชัดว่าการโต้เถียงมากเกินไปตัวเลข ณ จุดนี้ที่จะทำ ฉันควรหลีกเลี่ยงการพยายามลดขอบเขตการสนทนาเกี่ยวกับการกำกับดูแลของโครงการให้เป็นแบบส่วนบุคคล [ ... ]
Devuan เกิดจากการทะเลาะวิวาทกับการตัดสินใจใช้เป็นระบบเริ่มต้นสำหรับเดเบียน ตำแหน่งอย่างเป็นทางการใน Debian systemdเต็มของการเรียกร้องที่คนอื่น ๆ ได้ debunked ผู้อ่านที่สนใจสามารถดำเนินการต่อการอภิปรายหัวข้อร้อนนี้ในการโต้เถียง systemd อย่างไรก็ตามเราขอแนะนำให้คุณรักษาความสงบและเสียงของคุณ ที่ Devuan เราสนใจที่จะเขียนโปรแกรมผิดมากกว่ามองย้อนกลับไป [ ... ]
มีการสร้างเว็บไซต์และบทความบางส่วนสำหรับข้อพิพาทของ systemd:
มีการสนทนาที่น่าสนใจมากมายเกี่ยวกับ Hacker News:
แนวโน้มที่คล้ายกันใน distros อื่น ๆ สามารถสังเกตได้เช่นกัน:
ปรัชญา
พุ่งพรวดตามปรัชญา Unix ของ DOTADIW - "ทำสิ่งหนึ่งและทำมันได้ดี" มันเป็นการทดแทนสำหรับ init daemon ดั้งเดิม มันไม่ได้ทำอะไรนอกจากการเริ่มและหยุดบริการ งานอื่น ๆ จะมอบหมายให้กับระบบย่อยพิเศษอื่น ๆ
systemdทำอะไรได้มากกว่านั้น นอกจากการเริ่มและหยุดบริการแล้วยังจัดการรหัสผ่านการล็อกอินเทอร์มินัลการจัดการพลังงานรีเซ็ตโรงงานการประมวลผลบันทึกจุดเมานท์ระบบไฟล์ระบบเครือข่ายและอื่น ๆ อีกมากมาย - ดูไฟล์NEWSสำหรับคุณสมบัติบางอย่าง
แผนการขยายตัว
ตามมุมมองของ systemd สิ่งที่ประสบความสำเร็จและการนำเสนอสิ่งที่อยู่ข้างหน้าโดย Lennart Poettering ในปี 2014 ที่ GNOME.asia นี่คือวัตถุประสงค์หลักของ systemd พื้นที่ที่ครอบคลุมแล้วและที่ยังดำเนินอยู่:
วัตถุประสงค์ของ systemd:
วัตถุประสงค์ของเรา
- เปลี่ยน Linux จากถุงบิตให้เป็นระบบปฏิบัติการเอนกประสงค์
- การสร้างระบบปฏิบัติการรุ่นต่อไปของอินเทอร์เน็ตการรวมความแตกต่างอย่างไม่มีจุดหมายระหว่างการกระจาย
นำนวัตกรรมกลับสู่ระบบปฏิบัติการหลัก
เดสก์ท็อป, เซิร์ฟเวอร์, คอนเทนเนอร์, เอ็มเบ็ดเด็ด, มือถือ, คลาวด์, คลัสเตอร์, . . พื้นที่เหล่านี้อยู่ใกล้กันมากกว่าที่คุณคิด
- ลดความซับซ้อนของผู้ดูแลระบบความน่าเชื่อถือโดยไม่มีการดูแล
- ทุกอย่างครุ่นคิด
- การค้นพบอัตโนมัติแบบพลักแอนด์เพลย์เป็นกุญแจสำคัญ
- เราแก้ไขสิ่งที่พวกเขาถูกทำลายไม่เคยปิดบังพวกเขา
พื้นที่ครอบคลุมแล้ว:
สิ่งที่เราครอบคลุมอยู่แล้ว:
ระบบ init, การบันทึกเจอร์นัล, การจัดการล็อกอิน, การจัดการอุปกรณ์, การจัดการไฟล์ชั่วคราวและการระเหย, การลงทะเบียนรูปแบบไบนารี, บันทึก / เรียกคืนแบ็คไลท์, rfkill save / restore, bootchart, readahead, การตั้งค่าการจัดเก็บข้อมูลเข้ารหัส การลงทะเบียนการจัดการคอนเทนเนอร์ขั้นต่ำการจัดการชื่อโฮสต์การจัดการโลแคลการจัดการเวลาการจัดการเมล็ดแบบสุ่มการจัดการตัวแปร sysctl การจัดการคอนโซล . .
กำลังดำเนินการ:
เรากำลังทำอะไรอยู่:
- การจัดการเครือข่าย
- systemd-networkd
- Local DNS cache, mDNS Responder, LLMNR Responder, การตรวจสอบ DNSSEC
- IPC ในเคอร์เนล
- kdbus, sd-bus
- การประสานเวลากับ NTP
- systemd-timesyncd
- บูรณาการกับตู้คอนเทนเนอร์มากขึ้น
- Sandboxing of Services
- แอป Sandbox
- รูปแบบภาพ OS
- รูปแบบภาพคอนเทนเนอร์
- รูปแบบภาพแอป
- GPT พร้อมการค้นพบอัตโนมัติ
- ระบบไร้สัญชาติ, ระบบทันใจ, รีเซ็ตเป็นค่าจากโรงงาน
- / usr เป็นระบบปฏิบัติการ
- / etc คือการกำหนดค่า (เป็นทางเลือก)
- / var คือสถานะ (เป็นทางเลือก)
- การเริ่มต้นและการปรับปรุงโหนดปรมาณู
- บูรณาการกับระบบคลาวด์
- การจัดการบริการข้ามโหนด
- ภาพ OS ที่ตรวจสอบได้
- ไปจนถึงเฟิร์มแวร์
- กำลังโหลด Boot
ขอบเขตของคำตอบนี้
ดังที่fpmurphy1ตั้งข้อสังเกตในความเห็นว่า "มันควรจะชี้ให้เห็นว่า systemd ได้ขยายขอบเขตการทำงานในช่วงหลายปีที่ผ่านมามากกว่าแค่การเริ่มต้นระบบ"
ฉันพยายามรวมข้อมูลที่เกี่ยวข้องส่วนใหญ่ไว้ที่นี่ ที่นี่ฉันกำลังเปรียบเทียบคุณสมบัติทั่วไปของ Upstart และ systemd เมื่อใช้เป็นระบบ init ตามที่ถามในคำถามและฉันพูดถึงเฉพาะคุณสมบัติของ systemd ที่อยู่นอกเหนือขอบเขตของระบบ init เพราะสิ่งเหล่านั้นไม่สามารถเปรียบเทียบกับ Startup ได้ เพื่อทำความเข้าใจความแตกต่างระหว่างทั้งสองโครงการ ควรตรวจสอบเอกสารที่เกี่ยวข้องเพื่อรับข้อมูลเพิ่มเติม
ข้อมูลเพิ่มเติม
ข้อมูลเพิ่มเติมสามารถดูได้ที่:
พิเศษ
LinOxideทีมได้สร้างSystemd VS SysV Init ลินุกซ์ Cheatsheet