Cập nhật năm 2016
Hầu hết các câu trả lời ở đây là năm tuổi vì vậy đây là thời gian cho một số cập nhật.
Ubuntu đã từng sử dụng upstart theo mặc định nhưng họ đã từ bỏ nó vào năm ngoái để ủng hộ systemd - xem:
Do đó, có một bài viết hay Systemd dành cho người dùng mới bắt đầu trên Ubuntu wiki - so sánh rất chi tiết giữa upstart và systemd và hướng dẫn chuyển đổi từ upstart sang systemd.
(Lưu ý rằng theo wiki Ubuntu bạn vẫn có thể chạy mới nổi trên các phiên bản hiện tại của Ubuntu theo mặc định bằng cách cài đặt upstart-sysvvà chạy sudo update-initramfs -unhưng xem xét phạm vi của dự án systemd Tôi không biết làm thế nào nó hoạt động trong thực tế, hoặc có hoặc không systemd là có thể gỡ cài đặt.)
Hầu hết các thông tin trong phần Lệnh và Tập lệnh bên dưới được điều chỉnh từ một số ví dụ được sử dụng trong bài viết đó (được cấp phép thuận tiện giống như đóng góp của người dùng Stack Exchange theo Giấy phép Creative Commons Attribution-ShareAlike 3.0 ).
Dưới đây là so sánh nhanh các lệnh phổ biến và các tập lệnh đơn giản, xem các phần bên dưới để được giải thích chi tiết. Câu trả lời này là so sánh hành vi cũ của các hệ thống dựa trên Upstart với hành vi mới của các hệ thống dựa trên systemd, như đã hỏi trong câu hỏi, nhưng lưu ý rằng các lệnh được gắn thẻ là "Upstart" không nhất thiết phải là Upstart - chúng thường là các lệnh mà là phổ biến cho mọi hệ thống Linux và Unix không hệ thống.
Các lệnh
Chạy su:
- mới bắt đầu:
su
- hệ thống:
machinectl shell
(xem phần "thay thế lệnh su" bên dưới)
Màn hình đang chạy:
- mới bắt đầu:
screen
- hệ thống:
systemd-run --user --scope screen
(xem phần "Tiêu diệt quá trình nền bất ngờ" bên dưới)
Chạy tmux:
- mới bắt đầu:
tmux
- hệ thống:
systemd-run --user --scope tmux
(xem phần "Tiêu diệt quá trình nền bất ngờ" bên dưới)
Bắt đầu công việc:
- mới bắt đầu:
start foo
- hệ thống:
systemctl start foo
Dừng công việc foo:
- mới bắt đầu:
stop foo
- hệ thống:
systemctl stop foo
Khởi động lại công việc:
- mới bắt đầu:
restart foo
- hệ thống:
systemctl restart foo
Liệt kê các công việc:
- mới bắt đầu:
initctl list
- hệ thống:
systemctl status
Kiểm tra cấu hình của công việc foo:
- mới bắt đầu:
init-checkconf /etc/init/foo.conf
- hệ thống:
systemd-analyze verify /lib/systemd/system/foo.service
Liệt kê các biến môi trường của công việc:
- mới bắt đầu:
initctl list-env
- hệ thống:
systemctl show-environment
Đặt biến môi trường của công việc:
- mới bắt đầu:
initctl set-env foo=bar
- hệ thống:
systemctl set-environment foo=bar
Loại bỏ biến môi trường của công việc:
- mới bắt đầu:
initctl unset-env foo
- hệ thống:
systemctl unset-environment foo
Nhật ký
Trong phần khởi động, nhật ký là các tệp văn bản bình thường trong thư mục / var / log / upstart, vì vậy bạn có thể xử lý chúng như bình thường:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
Trong nhật ký systemd được lưu trữ ở định dạng nhị phân nội bộ (không phải là tệp văn bản), do đó bạn cần sử dụng journalctllệnh để truy cập chúng:
sudo journalctl -u foo
sudo journalctl -u foo -f
Chữ viết
Ví dụ kịch bản mới nhất được viết bằng /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
Ví dụ script script được viết bằng /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
thay thế lệnh su
Một susự thay thế lệnh đã được sáp nhập vào systemd trong kéo theo yêu cầu # 1022:
bởi vì, theo Lennart Poettering, "su thực sự là một khái niệm bị phá vỡ" .
Ông giải thích rằng "bạn có thể sử dụng su và sudo như trước đây, nhưng đừng hy vọng rằng nó sẽ hoạt động đầy đủ " .
Cách chính thức để đạt được một suhành vi giống như bây giờ là:
machinectl shell
Nó đã được giải thích thêm
bởi Lennart Poettering
trong cuộc thảo luận về vấn đề # 825:
"Chà, đã có những cuộc thảo luận dài về vấn đề này, nhưng vấn đề là những gì su được cho là rất không rõ ràng. [...] Câu chuyện dài ngắn: su thực sự là một khái niệm bị phá vỡ. Nó sẽ cho bạn một loại vỏ và sử dụng nó cho việc đó là tốt, nhưng nó không phải là một thông tin đăng nhập đầy đủ và không nên nhầm lẫn với nó. " - Lennart Poettering
Xem thêm:
Giết bất ngờ các quá trình nền
Các lệnh như:
không còn làm việc như mong đợi . Ví dụ: nohuplà lệnh POSIX để đảm bảo rằng quy trình tiếp tục chạy sau khi bạn đăng xuất khỏi phiên của mình. Nó không còn hoạt động trên systemd. Ngoài ra các chương trình như screenvà tmuxcần phải được gọi theo một cách đặc biệt hoặc nếu không các quy trình mà bạn chạy với chúng sẽ bị giết (trong khi không làm cho các quy trình đó bị giết thường là lý do chính của việc chạy màn hình hoặc tmux ở vị trí đầu tiên).
Đây không phải là một sai lầm, nó là một quyết định có chủ ý, vì vậy nó không có khả năng được sửa chữa trong tương lai. Đây là những gì Lennart Poettering đã nói về vấn đề này:
Theo quan điểm của tôi, UNIX thực sự khá lạ khi nó mặc định cho phép mã người dùng tùy ý ở xung quanh không bị hạn chế sau khi đăng xuất. Hiện nay, nó đã được thảo luận từ lâu trong số nhiều người dùng HĐH, rằng điều này có thể xảy ra nhưng chắc chắn không phải là mặc định, nhưng cho đến nay, không ai dám lật công tắc để chuyển nó từ mặc định sang tùy chọn. Không dọn dẹp các phiên của người dùng sau khi đăng xuất không chỉ xấu và hơi hack mà còn là vấn đề bảo mật. systemd 230 cuối cùng đã tắt công tắc và cuối cùng theo mặc định sẽ dọn sạch mọi thứ một cách chính xác khi người dùng đăng xuất.
Để biết thêm thông tin xem:
Khái niệm khởi nghiệp cấp cao
Theo cách mà systemd hoạt động ngược - trong các công việc mới bắt đầu bắt đầu ngay khi họ có thể và trong các công việc systemd bắt đầu khi họ phải làm. Vào cuối ngày, các công việc tương tự có thể được bắt đầu bởi cả hai hệ thống và theo thứ tự khá giống nhau, nhưng bạn nghĩ về nó nhìn từ một hướng ngược lại để nói.
Đây là cách Systemd cho người dùng mới bắt đầu giải thích nó:
Upstart mô hình 's để bắt đầu quá trình (công việc) là 'tham lam event-based', công việc tức là tất cả sẵn có các sự kiện khởi động xảy ra được bắt đầu càng sớm càng tốt. Trong quá trình khởi động, khởi động tổng hợp một số sự kiện ban đầu như khởi động hoặc RCS là "gốc cây", các dịch vụ ban đầu bắt đầu trên các dịch vụ đó và các dịch vụ sau bắt đầu khi dịch vụ cũ đang chạy. Một công việc mới chỉ cần cài đặt tệp cấu hình của nó vào / etc / init / để hoạt động.
Mô hình của systemd để bắt đầu các quy trình (đơn vị) là "dựa trên phụ thuộc lười biếng", tức là một đơn vị sẽ chỉ bắt đầu nếu và khi một số đơn vị bắt đầu khác phụ thuộc vào nó. Trong quá trình khởi động, systemd khởi động một "đơn vị gốc" (default.target, có thể được ghi đè trong grub), sau đó mở rộng liên tục và bắt đầu các phụ thuộc của nó. Một đơn vị mới cần thêm chính nó như là một phụ thuộc của một đơn vị của chuỗi khởi động (thường là multi-user.target) để hoạt động.
Sử dụng trong phân phối
Bây giờ một số dữ liệu gần đây theo Wikipedia:
Phân phối sử dụng upstart theo mặc định:
Phân phối sử dụng systemd theo mặc định:
(Xem Wikipedia để biết thông tin cập nhật)
Phân phối không sử dụng Upstart hay systemd:
Tranh cãi
Trước đây, một nhánh của Debian đã được đề xuất để tránh systemd . Các Devuan GNU + Linux đã được tạo ra - một ngã ba của Debian mà không systemd (nhờ fpmurphy1 cho trỏ nó ra trong các ý kiến).
Để biết thêm thông tin về tranh cãi này, xem:
Như nhiều người trong số các bạn có thể đã biết, phiếu bầu ban đầu của GR GR do Ian Jackson quảng bá không hữu ích để bảo vệ di sản của Debian và người dùng của nó khỏi trận tuyết lở hệ thống.
Tình huống này có thể xảy ra sự khóa trong các phụ thuộc hệ thống, thực tế đang đe dọa tự do phát triển và gây hậu quả nghiêm trọng cho Debian, ngược dòng và hạ nguồn của nó.
CTTE đã xoay sở để trao đổi một sự phụ thuộc và giúp chúng ta có thời gian cài đặt hệ thống tinh tế qua sysvinit, nhưng ngay cả quá trình này cũng mệt mỏi và đầy kịch tính. Cuối cùng, một tuần trước, Ian Jackson đã từ chức. [...]
Tôi đang từ chức từ Ủy ban Kỹ thuật có hiệu lực ngay lập tức.
Mặc dù điều quan trọng là quan điểm của 30-40% dự án đồng ý với tôi nên tiếp tục được đại diện trên TC, nhưng bản thân tôi rõ ràng là quá tranh cãi về một con số tại thời điểm này để làm điều đó. Tôi nên bước sang một bên để cố gắng giảm mức độ các cuộc hội thoại về quản trị dự án được cá nhân hóa. [...]
Devuan được sinh ra từ một cuộc tranh cãi về quyết định sử dụng làm hệ thống init mặc định cho Debian. Vị trí Debian chính thức trên systemd chứa đầy các khiếu nại mà những người khác đã gỡ lỗi . Độc giả quan tâm có thể tiếp tục thảo luận về chủ đề nóng này trong tranh cãi systemd . Tuy nhiên, chúng tôi khuyến khích bạn giữ cho đầu của bạn mát mẻ và giọng nói của bạn dân sự. Tại Devuan, chúng tôi quan tâm đến việc lập trình sai hơn là nhìn lại. [...]
Một số trang web và bài viết dành riêng cho tranh cãi systemd đã được tạo:
Có rất nhiều cuộc thảo luận thú vị trên Hacker News:
Xu hướng tương tự trong các bản phát hành khác cũng có thể được quan sát:
Triết học
khởi đầu theo triết lý Unix của DOTADIW - "Làm một điều và làm tốt". Nó là một thay thế cho init daemon truyền thống. Nó không làm gì khác hơn là bắt đầu và dừng dịch vụ. Các nhiệm vụ khác được giao cho các hệ thống con chuyên ngành khác.
systemd làm nhiều hơn thế. Ngoài việc bắt đầu và dừng dịch vụ, nó còn quản lý mật khẩu, đăng nhập, thiết bị đầu cuối, quản lý nguồn, đặt lại nhà máy, xử lý nhật ký, điểm gắn hệ thống tệp, kết nối mạng và nhiều hơn nữa - xem tệp TIN TỨC để biết một số tính năng.
Kế hoạch mở rộng
Theo quan điểm của systemd Những gì đã đạt được và những gì nói dối trước Lennart Poettering vào năm 2014 tại Gnome.asia, đây là các mục tiêu chính của systemd, các khu vực đã được bảo hiểm và những khu vực vẫn đang được tiến hành:
mục tiêu hệ thống:
Mục tiêu của chúng tôi
- Biến Linux từ một túi bit thành Hệ điều hành Mục đích chung cạnh tranh.
- Xây dựng hệ điều hành thế hệ tiếp theo của Internet Thống nhất sự khác biệt vô nghĩa giữa các bản phân phối
Đưa đổi mới trở lại hệ điều hành cốt lõi
Máy tính để bàn, Máy chủ, Container, Nhúng, Di động, Đám mây, Cụm ,. . . Những khu vực này gần nhau hơn bạn nghĩ
- Giảm độ phức tạp của quản trị viên, độ tin cậy mà không cần giám sát
- Mọi thứ nội tâm
- Tự động phát hiện, cắm và chơi là chìa khóa
- Chúng tôi sửa chữa những thứ mà chúng bị hỏng, không bao giờ băng qua chúng
Các khu vực đã được bảo hiểm:
Những gì chúng tôi đã bao gồm:
hệ thống init, ghi nhật ký, quản lý đăng nhập, quản lý thiết bị, quản lý tệp tạm thời và dễ bay hơi, đăng ký định dạng nhị phân, lưu / khôi phục đèn nền, lưu / khôi phục rfkill, bootchart, đọc, thiết lập lưu trữ được mã hóa, phát hiện phân vùng EFI / GPT, máy ảo / container đăng ký, quản lý container tối thiểu, quản lý tên máy chủ, quản lý ngôn ngữ, quản lý thời gian, quản lý hạt giống ngẫu nhiên, quản lý biến sysctl, quản lý bảng điều khiển ,. . .
Công việc đang tiến hành:
Những gì chúng tôi đang làm việc:
- quản lý mạng
- systemd-mạngd
- Bộ đệm DNS cục bộ, phản hồi mDNS, phản hồi LLMNR, xác minh DNSSEC
- IPC trong nhân
- xe buýt, xe buýt sd
- Đồng bộ hóa thời gian với NTP
- systemd-timesyncd
- Tích hợp nhiều hơn với container
- Sandboxing của dịch vụ
- Sandboxing của ứng dụng
- Định dạng hình ảnh hệ điều hành
- Định dạng hình ảnh container
- Định dạng hình ảnh ứng dụng
- GPT với tính năng tự động phát hiện
- Hệ thống không quốc tịch, hệ thống có thể khởi động, thiết lập lại nhà máy
- / usr là HĐH
- / etc là cấu hình (tùy chọn)
- / var là trạng thái (tùy chọn)
- Khởi tạo và cập nhật nút nguyên tử
- Tích hợp với đám mây
- Quản lý dịch vụ trên các nút
- Hình ảnh hệ điều hành có thể kiểm chứng
- Tất cả các cách để chương trình cơ sở
- Đang tải khởi động
Phạm vi của câu trả lời này
Như fpmurphy1 đã lưu ý trong các bình luận, "Cần chỉ ra rằng systemd đã mở rộng phạm vi công việc của mình trong nhiều năm vượt xa đơn giản là khởi động hệ thống."
Tôi đã cố gắng bao gồm hầu hết các thông tin có liên quan ở đây. Ở đây tôi đang so sánh các tính năng phổ biến của Upstart và systemd khi được sử dụng làm hệ thống init như được hỏi trong câu hỏi và tôi chỉ đề cập đến các tính năng của systemd vượt ra ngoài phạm vi của hệ thống init vì chúng không thể so sánh với Startup, nhưng sự hiện diện của chúng rất quan trọng để hiểu sự khác biệt giữa hai dự án. Các tài liệu liên quan nên được kiểm tra để biết thêm.
Thêm thông tin
Thông tin thêm có thể được tìm thấy tại:
Ngoài ra
Nhóm LinOxide đã tạo ra một chiếc áo choàng Systemd vs SysV init Linux .