Tôi có thể khởi động lại systemd mà không cần khởi động lại không?

Tôi đang cố gắng khởi động lại các dịch vụ sau khi yum updatevào RHEL 7.4. Tôi có thể khởi động lại mọi dịch vụ bằng systemctl, nhưng needs-restartingtừ đó yum utilscho tôi biết rằng tôi cũng nên tự khởi động lại systemd:

# needs-restarting
1 : /usr/lib/systemd/systemd --system --deserialize 21

Tôi có thể khởi động lại systemdmà không cần khởi động lại máy chủ không, và làm thế nào?

Tôi đã tìm thấy một vài đề cập đến systemctl daemon-reload, nhưng điều này không làm cho nó biến mất khỏi danh sách cần khởi động lại.

rhel systemd

— Benjamin
nguồn

Để khởi động lại daemon, hãy chạy

systemctl daemon-reexec

Đây là tài liệu trong các systemctlmanpage :

Xem lại trình quản lý systemd. Điều này sẽ tuần tự hóa trạng thái người quản lý, xem xét lại quy trình và giải tuần tự hóa lại trạng thái. Lệnh này ít được sử dụng trừ việc gỡ lỗi và nâng cấp gói. Đôi khi, nó có thể hữu ích như một trọng lượng nặng daemon-reload. Trong khi daemon đang được thực hiện lại, tất cả các socket hệ thống nghe thay mặt cho cấu hình người dùng sẽ vẫn có thể truy cập được.

Thật không may, không needs-restartingthể xác định rằng systemdđã thực sự khởi động lại. systemd execschính nó để khởi động lại, mà không thiết lập lại thời gian bắt đầu của quá trình; nhưng needs-restartingso sánh thời gian sửa đổi của thực thi với thời gian bắt đầu của quy trình để xác định xem có cần khởi động lại một quy trình hay không (và trong số những thứ khác), và kết quả là nó luôn luôn systemdcần phải khởi động lại ... Để xác định xem có systemdthực sự cần phải khởi động lại hay không, bạn có thể kiểm tra đầu ra của lsof -p1 | grep deleted: systemdsử dụng một thư viện, libsystemd-sharedđược gửi trong cùng một gói và do đó được nâng cấp cùng với trình nền, vì vậy nếu systemdcần được khởi động lại, bạn sẽ thấy nó sử dụng phiên bản thư viện đã xóa. Nếu lsofhiển thị không có tập tin bị xóa, systemdkhông cần phải khởi động lại. (Nhờ vàoJeff Schaller cho gợi ý!)

— Stephen Kitt
nguồn

@Raman, daemon-reexecđược cho là hoạt động ngay cả với systemdtư cách là 1.

— Stephen Kitt

Mấu chốt của việc khởi động lại nhu cầu đã rút xuống github.com/rpm-software-man quản lý / yum / blog / master / trộm nơi nó truy vấn "start_time" của PID; nếu daemon-reexec không cập nhật điều đó, thì việc khởi động lại sẽ vẫn bị "nhầm lẫn".

— Jeff Schaller

Đừng cho rằng bất kỳ loại tiền mã hóa nào có liên quan đều được kiểm tra tốt, đặc biệt là trên các hệ thống không phải RedHat. Về mặt kỹ thuật có thể chạy daemon-reexec, nhưng an toàn hơn khi khởi động lại.

— Harald

@Harald nó được sử dụng bất cứ lúc nào bất cứ ai nâng cấp systemdtrên Debian và các dẫn xuất, vì vậy nó được kiểm tra tốt. Nó cũng khá đơn giản (tìm kiếm do_reexecute).

— Stephen Kitt

@StephenKitt - Khi tôi cố chạy lsof -p1 | grep deletedđầu ra sau đây được tạo lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. Khi đọc ( unix.stackexchange.com/questions/171519/ ,), có vẻ như ngay cả root cũng không thể truy cập được. Điều gì sẽ thay thế lsof -p1 | grep deleted?

— động lực vào

Trong trường hợp của tôi, tôi vừa nâng cấp systemdvà bất kỳ systemctllệnh nào đều thất bại:

# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied

Tuy nhiên, theo initmanpage, bạn có thể làm điều tương tự bằng cách gửi SIGTERMtới daemon đang chạy dưới dạng PID 1, hoạt động:

kill -TERM 1

Điều này đã tải lại daemon, sau đó tất cả các systemctllệnh bắt đầu hoạt động trở lại.

— Ác mộng
nguồn