it-swarm-vi.com

Những ưu / nhược điểm của Upstart và systemd là gì?

Nó xuất hiện systemd là hệ thống mới nóng init trên khối, giống như pstart là một vài năm trước. Những ưu/nhược điểm cho mỗi là gì? Ngoài ra, làm thế nào để mỗi so sánh với các hệ thống init khác?

187
tshepang

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 wiki 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 wiki bạn vẫn có thể chạy khởi động trên các phiên bản Ubuntu hiện tại theo mặc định bằng cách cài đặt upstart-sysv và chạy Sudo update-initramfs -u nhưng khi xem xét phạm vi của dự án systemd tôi không biết nó hoạt động như thế nào trong thực tế, hoặc liệu systemd có thể gỡ cài đặt hay không.)

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
  • systemd: 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
  • systemd: 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
  • systemd: 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
  • systemd: systemctl start foo

Dừng công việc foo:

  • mới bắt đầu: stop foo
  • systemd: systemctl stop foo

Khởi động lại công việc foo:

  • mới bắt đầu: restart foo
  • systemd: systemctl restart foo

Liệt kê các công việc:

  • mới bắt đầu: initctl list
  • systemd: 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
  • systemd: 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
  • systemd: 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
  • systemd: 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
  • systemd: systemctl unset-environment foo

Nhật ký

Khi bắt đầu, 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 bên trong (không phải là tệp văn bản), do đó bạn cần sử dụng lệnh journalctl để truy cập chúng:

Sudo journalctl -u foo
Sudo journalctl -u foo -f

Chữ viết

Ví dụ tập lệnh khởi động đượ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 systemd đượ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 thay thế lệnh su đã được hợp nhất vào systemd trong yêu cầu kéo # 1022:

bởi vì, theo Lennart Poettering, "su thực sự là một khái niệm bị hỏng" .

Anh ta giải thích rằng "bạn có thể sử dụng su và Sudo như trước đây, nhưng không mong đợi rằng nó sẽ hoạt động đầy đủ " .

Cách chính thức để đạt được hành vi giống như su- là:

machinectl Shell

Nó đã được tiếp tục được giải thích 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 Shell 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 hoạt động như mong đợi . Ví dụ: Nohup là 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ư screentmux cần phải được gọi theo 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 nhận được chúng các quá trình bị giết thường là lý do chính của màn hình chạy hoặc tmux ở nơi đầ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ó:

Mô hình khởi động để bắt đầu các quy trình (công việc) là "dựa trên sự kiện tham lam", i. e. tất cả các công việc có sẵn mà các sự kiện khởi nghiệp 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ũ 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à "lười biếng dựa trên phụ thuộc", i. e. 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 . Devuan GNU + Linux đã được tạo - một nhánh của Debian không có systemd (cảm ơn fpmurphy1 để chỉ ra nó trong các nhận xét).

Để 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 GR Debian 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 khóa 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 có đầ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 Cuộc tranh cãi về hệ thống . 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 chúng 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:

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

mới bắt đầu tuân 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 được 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 tin tức [~ # ~] [~ # ~] tệp cho một số tính năng.

Kế hoạch mở rộng

Theo Một viễn cảnh cho systemd Những gì đã đạt được và những gì nói dối trước Trình bày của 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 đề cập và những lĩnh vực đã được đề cập 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 Internet thế hệ tiếp theo 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, readahead, 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àn đ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
  • Đồ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ệ điều hành
  • / 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

As 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

LinOxide Nhóm đã tạo a Systemd vs SysV init Linux Chcoateet .

92
rsp

Cả upstart và systemd đều cố gắng giải quyết một số vấn đề với những hạn chế của hệ thống init SysV truyền thống. Ví dụ: một số dịch vụ cần khởi động sau các dịch vụ khác (ví dụ: bạn không thể gắn hệ thống tệp NFS cho đến khi mạng đang chạy), nhưng cách duy nhất trong SysV để xử lý đó là đặt các liên kết trong thư mục RC # .d cái này trước cái kia Thêm vào đó, bạn có thể cần đánh số lại mọi thứ sau này khi phụ thuộc được thêm hoặc thay đổi. Upstart và Systemd có nhiều cài đặt thông minh hơn để xác định các yêu cầu. Ngoài ra, có một vấn đề với thực tế là mọi thứ đều là một tập lệnh Shell, và không phải ai cũng viết các tập lệnh init tốt nhất. Điều đó cũng tác động đến tốc độ khởi động.

Một số ưu điểm của systemd tôi có thể thấy:

  • Mỗi quá trình bắt đầu có một nhóm riêng hoặc một nhóm cụ thể.
  • Tạo trước các socket và xử lý tệp cho các dịch vụ, tương tự như cách xinetd làm cho các dịch vụ của nó, cho phép các dịch vụ phụ thuộc bắt đầu nhanh hơn. Ví dụ, systemd sẽ giữ mở filehandle cho/dev/log cho syslog và các dịch vụ tiếp theo gửi đến/dev/log sẽ có các thông điệp của chúng được đệm cho đến khi syslogd sẵn sàng tiếp quản.
  • Ít quá trình chạy để thực sự bắt đầu một dịch vụ. Điều này có nghĩa là bạn không viết kịch bản Shell để khởi động dịch vụ của mình. Đây có thể là một cải tiến tốc độ và (IMO) một cái gì đó dễ dàng hơn để thiết lập ở nơi đầu tiên.

Một nhược điểm mà tôi biết là để tận dụng lợi thế của việc mở ổ cắm/FH của systemd, nhiều trình tiện ích sẽ phải được vá để FH được truyền cho họ bởi systemd.

68
jsbillings

Saw systemd được đề cập trên Arch General ML hôm nay. Vì vậy, đọc lên trên nó. The H Online như một nguồn tuyệt vời cho Công nghệ Linux và là nơi tôi tìm thấy nơi để bắt đầu nghiên cứu Systemd là SysV init và Upstart thay thế . Tuy nhiên, bài viết H Online (trong trường hợp này) không phải là một bài đọc rất hữu ích, công dụng thực sự đằng sau nó là nó cung cấp các liên kết đến các bài đọc hữu ích.

Câu trả lời thực sự nằm ở thông báo của systemd . Điều này đưa ra một số điểm quan trọng về những gì sai với SysV initd và những hệ thống mới cần phải làm gì

  • Để bắt đầu ít hơn.
  • Và để bắt đầu song song hơn.

Kế hoạch chính của nó để thực hiện điều này dường như là chỉ bắt đầu các dịch vụ khi cần thiết và bắt đầu một ổ cắm cho dịch vụ đó, để dịch vụ cần nó có thể kết nối với ổ cắm được tạo ra từ lâu trước khi daemon hoàn toàn trực tuyến. Rõ ràng một ổ cắm sẽ giữ lại một lượng nhỏ dữ liệu được đệm có nghĩa là không có dữ liệu nào bị mất trong thời gian trễ, nó sẽ được xử lý ngay khi daemon trực tuyến.

Một phần khác của kế hoạch dường như là không tuần tự hóa các hệ thống tập tin, mà thay vào đó cũng gắn kết những thứ đó theo yêu cầu, theo cách đó bạn không chờ đợi /home/, v.v (đừng nhầm với /etc) để gắn kết và/hoặc fsck khi bạn có thể bắt đầu trình nền dưới dạng //var/ vv, đã được gắn kết. Nó nói rằng nó sẽ sử dụng autofs cho đến cuối này.

Nó cũng có mục tiêu tạo ra .desktop kiểu mô tả init thay thế cho tập lệnh. Điều này sẽ ngăn hàng tấn các tiến trình sh chậm và thậm chí nhiều nhánh quá trình từ những thứ như sedgrep thường được sử dụng trong các tập lệnh Shell.

Họ cũng có kế hoạch không bắt đầu một số dịch vụ cho đến khi được yêu cầu và thậm chí có thể tắt chúng nếu không còn cần thiết, mô-đun bluetooth và daemon chỉ cần thiết khi bạn sử dụng thiết bị bluetooth chẳng hạn. Một ví dụ khác được đưa ra là daemon ssh. Đây là loại điều mà inetd có khả năng. Cá nhân tôi không chắc chắn tôi thích điều này, vì nó có thể có nghĩa là độ trễ khi tôi cần chúng, và trong trường hợp của ssh tôi nghĩ nó có nghĩa là một lỗ hổng bảo mật có thể xảy ra, nếu inetd của tôi bị xâm phạm toàn bộ hệ thống. Tuy nhiên, tôi đã được thông báo rằng việc sử dụng điều này để vi phạm hệ thống này là không thể thực hiện được và nếu tôi muốn, tôi có thể vô hiệu hóa tính năng này trên mỗi dịch vụ và theo những cách khác.

Một tính năng khác rõ ràng là khả năng bắt đầu dựa trên các sự kiện thời gian, tại một khoảng thời gian được lên lịch thường xuyên hoặc tại một thời điểm nhất định. Điều này tương tự với những gì crondatd làm ngay bây giờ. Mặc dù tôi đã nói rằng nó sẽ không hỗ trợ người dùng "cron". Cá nhân điều này nghe có vẻ như là điều vô nghĩa nhất. Tôi nghĩ rằng điều này đã được viết/nghĩ ra bởi những người không làm việc trong môi trường nhiều người dùng, không có nhiều mục đích cho người dùng nếu bạn là người dùng duy nhất trên hệ thống, ngoài việc không chạy bằng root. Tôi làm việc trên các hệ thống nhiều người dùng hàng ngày và quy tắc là luôn chạy các tập lệnh người dùng với tư cách là người dùng. Nhưng có lẽ tôi không có tầm nhìn xa mà họ làm, và sẽ không có cách nào để tôi không thể chạy crond hoặc atd, vì vậy nó không làm tổn thương bất cứ ai trừ Tôi cho rằng các nhà phát triển.

Nhược điểm lớn của systemd là một số trình nền sẽ phải được sửa đổi để tận dụng tối đa lợi thế của nó. Chúng sẽ hoạt động ngay bây giờ, nhưng chúng sẽ hoạt động tốt hơn nếu chúng được viết riêng cho mô hình ổ cắm của nó.

Dường như phần lớn vấn đề con người của systemd với sự khởi đầu là hệ thống sự kiện và họ tin rằng nó không có ý nghĩa hoặc không cần thiết. Có lẽ lời nói của họ đặt nó tốt nhất.

Hay nói một cách đơn giản hơn: thực tế là người dùng mới khởi động D-Bus không phải là dấu hiệu cho thấy NetworkManager cũng nên được khởi động (nhưng đây là những gì Upstart sẽ làm). Nó đúng theo cách khác: khi người dùng yêu cầu NetworkManager, đó chắc chắn là một dấu hiệu cho thấy D-Bus cũng nên được khởi động (đó chắc chắn là điều mà hầu hết người dùng mong đợi, phải không?).
Một hệ thống init tốt chỉ nên bắt đầu những gì cần thiết và theo yêu cầu. Hoặc lười biếng hoặc song song và trước. Tuy nhiên, nó không nên bắt đầu nhiều hơn mức cần thiết, đặc biệt không phải mọi thứ được cài đặt có thể sử dụng dịch vụ đó.

Như tôi đã nói điều này được thảo luận toàn diện hơn nhiều trong thông báo về systemd .

29
xenoterracide

Vâng, một điều mà hầu hết các bạn quên là tổ chức các quy trình trong cgroups .

Vì vậy, nếu systemd bắt đầu một thứ, nó sẽ đặt thứ này vào nhóm riêng của nó và không có ý nghĩa (không bị hạn chế) cho quá trình thoát khỏi nhóm đó. Đây là hậu quả của điều đó:

  • Quản trị viên của một hệ thống lớn có nhiều người dùng có những cách mới hiệu quả để xác định người dùng/quy trình độc hại.
  • Các ưu tiên cho lập lịch CPU có thể được xác định tốt hơn khi được thực hiện bởi "Bản vá nhóm tự động kỳ diệu" .
11
enaut

Để có cái nhìn rất chi tiết về systemd, bắt đầu với các bản nháp thiết kế đầu tiên (và một bài phê bình chi tiết về các hệ thống init hiện tại, bao gồm cả khởi động và cách systemd đề xuất sửa chúng), hãy truy cập trang chủ . Theo thời gian, đã có một số bài viết về khởi động được xuất bản trong LWN . Chỉ cần lưu ý rằng bất kỳ đề cập đến systemd (hoặc pulseaudio) có kích hoạt không bao giờ flamewars.

IMVHO (và là người dùng Fedora) Tôi rất hài lòng với nó. Một cái gì đó trong dòng này đã quá hạn để xử lý sự phức tạp của các hệ thống Linux hiện tại. Fedora đã sử dụng mới bắt đầu được một thời gian, nhưng nó chưa bao giờ thoát khỏi giai đoạn trở thành một sự thay thế lạ mắt cho sysvinit, chạy các kịch bản init không thay đổi. Lời hứa đơn giản hóa cấu hình khởi động của nó có chi phí một lần nữa thiết lập thủ công phụ thuộc lẫn nhau và điều đó không hiệu quả. Các số liệu hệ thống phụ thuộc vào chính nó (hoặc chỉ cho phép bắt đầu công cụ mà không quan tâm đến các phụ thuộc, chúng tự sắp xếp). Một ưu điểm lớn khác (một số người cho rằng đó là một bất lợi nghiêm trọng) là nó khai thác các tính năng dành riêng cho Linux cho chuồng trại (đáng chú ý là các nhóm cho phép cách ly một daemon và tất cả con cháu của nó, vì vậy rất dễ theo dõi, giới hạn tài nguyên hoặc giết chúng một nhóm, có nhiều người khác).

8
vonbrand

Ghi nhật ký - Systemd có nghĩa đen giống như thư mục WinSXS khi nói đến việc ghi nhật ký, nó tạo ra các bản sao của bản sao trừ khi bạn xóa hoặc giảm kích thước tệp theo cách thủ công, nó sẽ tiếp tục ăn ở ổ đĩa của bạn. Tôi gọi nó là cookie bộ tải khởi động.

3
Bert