phương pháp chung để gỡ lỗi chu kỳ đặt hàng trong systemd

Tôi nhận thức được theo chủ đề và được cho là một câu trả lời cho nó . Ngoại trừ một câu trả lời không phải là một câu trả lời theo nghĩa chung. Nó cho biết vấn đề là gì trong một trường hợp cụ thể, nhưng không nói chung.

Câu hỏi của tôi là: có cách nào để gỡ lỗi chu kỳ đặt hàng một cách chung chung không? Ví dụ: có một lệnh sẽ mô tả chu kỳ và những gì liên kết đơn vị này với đơn vị khác?

Ví dụ: tôi đã theo dõi journalctl -b(vui lòng bỏ qua ngày, hệ thống của tôi không có RTC để đồng bộ hóa thời gian với):

Jan 01 00:00:07 host0 systemd[1]: Found ordering cycle on sysinit.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on local-fs.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on cvol.service/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on basic.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on sockets.target/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on dbus.socket/start
Jan 01 00:00:07 host0 systemd[1]: Found dependency on sysinit.target/start
Jan 01 00:00:07 host0 systemd[1]: Breaking ordering cycle by deleting job local-fs.target/start
Jan 01 00:00:07 host0 systemd[1]: Job local-fs.target/start deleted to break ordering cycle starting with sysinit.target/start

trong đó cvol.service (dịch vụ đã được giới thiệu và phá vỡ chu trình) là:

[Unit]
Description=Mount Crypto Volume
After=boot.mount
Before=local-fs.target

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/cryptsetup open /dev/*** cvol --key-file /boot/***

[Install]
WantedBy=home.mount
WantedBy=root.mount
WantedBy=usr-local.mount

Theo tạp chí, cvol.service muốn basic.service, ngoại trừ việc nó không, ít nhất là không rõ ràng. Có một lệnh sẽ chứng minh nơi liên kết này được bắt nguồn từ đâu? Và nói chung, có một lệnh, trong đó sẽ tìm thấy các chu kỳ và hiển thị mỗi liên kết trong chu kỳ bắt nguồn từ đâu?

Có một lệnh sẽ chứng minh nơi liên kết này được bắt nguồn từ đâu?

Gần nhất bạn có thể làm là systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After cvol.service, nó sẽ hiển thị danh sách phụ thuộc kết quả (hiệu quả) cho một đơn vị nhất định.

Có một lệnh, trong đó sẽ tìm thấy các chu kỳ và hiển thị mỗi liên kết trong chu kỳ bắt nguồn từ đâu?

Theo hiểu biết của tôi, không có lệnh như vậy. Trên thực tế systemd không cung cấp gì để hỗ trợ gỡ lỗi chu kỳ đặt hàng (thở dài).

Theo tạp chí, cvol.service muốn basic.service, ngoại trừ việc nó không, ít nhất là không rõ ràng.

Thứ nhất, sự phụ thuộc yêu cầu ( Wants=, Requires=, BindsTo=vv) là độc lập phụ thuộc trật tự ( Before=và After=). Những gì bạn thấy ở đây là một chu kỳ phụ thuộc đặt hàng , tức là nó không có gì để làm với Wants=vv

Thứ hai, có một số "phụ thuộc mặc định" được tạo giữa các đơn vị của một số loại nhất định. Chúng được điều khiển bởi DefaultDependencies=chỉ thị trong [Unit]phần (được bật theo mặc định ).

Đặc biệt, trừ khi lệnh này bị vô hiệu hóa rõ ràng, bất kỳ .serviceđơn vị -type nào cũng được ẩn Requires=basic.targetvà After=basic.targetphụ thuộc, đó chính xác là những gì bạn thấy. Điều này được ghi lại trong systemd.service (5) .

Bạn có thể hình dung ra chu kỳ với các lệnh systemd-analyze verify, systemd-analyze dotvà GraphViz dot công cụ:

systemd-analyze verify default.target |&
perl -lne 'print $1 if m{Found.*?on\s+([^/]+)}' |
xargs --no-run-if-empty systemd-analyze dot |
dot -Tsvg >cycle.svg

Bạn sẽ thấy một cái gì đó như thế này:

Tại đây bạn có thể thấy chu trình: c.service->b.service->a.service->c.service

Color legend: 
    black     = Requires
    dark blue = Requisite
    dark grey = Wants
    red       = Conflicts
    green     = After

Liên kết:

• phân tích hệ thống (1)
• dấu chấm (1)

Bước 1: chạy lệnh xác minh cho default.target

systemd-analyze verify default.target

Bước 2: quan sát dịch vụ hoặc mục tiêu nào được đề cập trong thông báo "systemd Phá vỡ chu kỳ đặt hàng bằng cách xóa công việc" và hiển thị danh sách phụ thuộc hoàn chỉnh của nó

systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After <service or target name mentioned in the "breaking cycle" message>

Bước 3: xem xét các nhóm "sau" và "trước" bên trong tệp dịch vụ hoặc tệp đích thường được xác định trong

/lib/systemd/system

và tìm các dịch vụ hoặc mục tiêu nổi tiếng là tuần tự nhưng theo thứ tự bên ngoài cho dịch vụ này.

thí dụ:

dbus.service

thường là thị trường "sau"

multi-user.target

nhưng "trước"

sockets.target

sự phụ thuộc như vậy có thể dễ dàng được quan sát bằng cách gọi

systemctl list-dependencies default.target

tuy nhiên nếu tập tin

/lib/systemd/system/dbus.service

chứa các dòng như:

Before=multi-user.target

hoặc là

After=sockets.target

hoặc cả hai đồng thời, có nghĩa là dbus.service được xác định ra bên ngoài và nó gây ra một chu kỳ vô tận của hệ thống.

Cách chữa rất đơn giản - đổi từ "Sau" thành "Trước" và ngược lại nếu cần.