Cách cài đặt dnf-automatic trên Rocky và AlmaLinux

dnf-automatic làm gì trên Rocky Linux và AlmaLinux

dnf-automatic là cách bạn thực hiện cập nhật bảo mật tự động trên Rocky Linux và AlmaLinux. Đây là một chương trình nhỏ, được khởi chạy bởi một systemd timer, đọc file /etc/dnf/automatic.conf và áp dụng các thiết lập mà file đó cho phép. Việc cài đặt chỉ cần một lệnh duy nhất. Phần còn lại của hướng dẫn này nói về các thiết lập quyết định liệu nó sẽ bảo vệ máy chủ của bạn hay chỉ âm thầm không làm gì cả.

Nếu bạn chuyển từ Debian hoặc Ubuntu sang, đây chính là công việc tương đương với những gì unattended-upgrades thực hiện trên một Ubuntu VPS. Có một điểm khác biệt quan trọng hơn tất cả các điểm khác: ý nghĩa của từ "bảo mật" (security) đối với trình quản lý gói. Trên Ubuntu, đó là một kho lưu trữ riêng biệt. Trên dòng RHEL, đó là metadata đính kèm với các thông báo (advisory) đã công bố, và metadata này có thể bị thiếu hoặc lỗi thời. Nếu bạn trỏ dnf-automatic vào một repository không có dữ liệu thông báo, nó sẽ không cài đặt gì cả trong khi vẫn báo cáo là thành công.

Hướng dẫn này được viết dựa trên Rocky Linux 9 và AlmaLinux 9, vốn sử dụng DNF 4 (DNF là trình quản lý gói trên dòng RHEL), tính đến tháng 8 năm 2026. Các bản phát hành 10 đã chuyển sang DNF5 và tên gọi ở đó đã thay đổi, vì vậy chúng có một phần riêng ở gần cuối. Mọi lệnh dưới đây là lệnh để bạn chạy trên máy chủ của chính mình, kèm theo kết quả đầu ra mà bạn nên nhận được ngay bên cạnh.

Cài đặt dnf-automatic và đọc cấu hình đi kèm

Việc bật cập nhật tự động nên được thực hiện cùng với các bước thiết lập khác trong mười phút đầu tiên trên VPS mới, ngay sau khi bạn đã tạo user không phải root và cấu hình firewall. Nếu bạn chưa làm phần firewall, firewalld là công cụ mặc định trên Rocky và AlmaLinux, và chỉ cần vài lệnh để mở SSH, mở cổng dịch vụ của bạn đang nghe và đảm bảo các thiết lập này vẫn tồn tại sau khi reboot.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled sẽ in ra disabled trên một bản cài đặt mới, vì việc cài đặt gói này không tự khởi động bất kỳ tiến trình nào. Đây là lý do phổ biến nhất khiến một máy chủ "đã có dnf-automatic" nhưng chưa bao giờ áp dụng bất kỳ bản cập nhật nào.

Phiên bản DNF rất quan trọng đối với một tùy chọn. Thiết lập reboot xuất hiện trong DNF 4.15, và Red Hat đã backport nó vào dnf-4.14.0-6.el9 vào tháng 11 năm 2023 thông qua advisory RHBA-2023:6645. Rocky 9 và AlmaLinux 9 build lại gói đó, vì vậy một máy chủ hiện tại sẽ có tính năng này, còn máy chủ không được cập nhật từ năm 2023 thì không.

File cấu hình là /etc/dnf/automatic.conf. Bản sao đi kèm liệt kê mọi tùy chọn mà bản build này hiểu, cùng với giá trị mặc định được comment lại. Hãy đọc nó một lần trước khi chỉnh sửa, vì file đó là nguồn thông tin chính xác nhất về phiên bản bạn đang dùng.

Hai tùy chọn quyết định hành vi

download_updates và apply_updates trong phần [commands] quyết định hành vi của hệ thống. Cả hai đều được đặt là no theo mặc định trên EL9 (enterprise Linux 9, nền tảng chung của Rocky 9 và AlmaLinux 9), vì vậy nếu bạn chỉ enable dnf-automatic mà không chỉnh sửa, nó sẽ chỉ thông báo cho bạn những gì đang có sẵn.

• Cả hai là no: dnf-automatic báo cáo các bản cập nhật khả dụng và không thay đổi gì trên máy chủ.
• download_updates = yes với apply_updates = no: các gói được tải về cache của DNF. Việc cài đặt sau đó sẽ nhanh và không cần mạng, nhưng không có thay đổi nào được thực hiện ngay lúc đó.
• Cả hai là yes với upgrade_type = default: mọi bản cập nhật khả dụng đều được cài đặt, bất kể đó có phải là bản vá bảo mật hay không.
• Cả hai là yes với upgrade_type = security: chỉ các gói được nêu trong thông báo bảo mật mới được cài đặt.

Một cấu hình khởi đầu hợp lý cho VPS công khai:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout là số giây tiến trình chờ mạng hoạt động trước khi bỏ cuộc, điều này quan trọng trên máy chủ vừa mới khởi động. random_sleep là cách cũ để phân bổ tải trên nhiều máy, hiện nay timer đã đảm nhận công việc đó. Chạy systemctl cat dnf-automatic.service để xem chính xác các flag mà service được cung cấp truyền vào.

Kiểm tra xem file cấu hình hoạt động đúng như bạn mong đợi mà không cần chờ đến 06:00:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

Journal hiển thị những gì tiến trình đã xem xét và đã thực hiện. Bạn cũng có thể ép buộc một hành vi từ dòng lệnh, điều này sẽ ghi đè lên file cấu hình chỉ cho lần chạy đó:

sudo dnf-automatic --downloadupdates --no-installupdates

Ý nghĩa thực sự của upgrade_type = security trên Rocky và Alma

DNF không xác định một bản cập nhật có phải là bản cập nhật bảo mật hay không bằng cách so sánh số phiên bản. Nó đọc metadata errata: một tệp tin gọi là updateinfo.xml được xuất bản bên trong repository, nơi mỗi thông báo (advisory) liệt kê các gói cần sửa lỗi. AlmaLinux xuất bản các thông báo này dưới dạng ALSA, còn Rocky xuất bản dưới dạng RLSA. upgrade_type = security xây dựng một bộ lọc từ metadata đó và chỉ nâng cấp các gói khớp với thông báo.

Có hai hệ quả xảy ra, và cả hai đều khiến người dùng bất ngờ.

Thứ nhất, không có metadata đồng nghĩa với không có cập nhật. Nếu repository không chứa updateinfo.xml, bộ lọc sẽ không khớp với bất kỳ gói nào và quá trình chạy kết thúc với dòng này trong journal:

No security updates needed, but 3 updates available

Máy chủ không được vá lỗi, và không có thông báo lỗi nào được ghi nhận. Hãy tự kiểm tra bằng lệnh:

dnf updateinfo list --security
dnf check-update

Nếu dnf check-update liệt kê các gói trong khi dnf updateinfo list --security không in ra bất cứ thứ gì, thì hoặc là không có bản cập nhật nào đi kèm thông báo bảo mật, hoặc repository không có dữ liệu thông báo để đọc. Cả Rocky và AlmaLinux đều xuất bản dữ liệu này, nên trên hai hệ điều hành đó, danh sách trống thường là kết quả chính xác. CentOS Stream hoàn toàn không xuất bản dữ liệu này.

Thứ hai, chế độ bảo mật không phải là thay đổi tối thiểu. dnf-automatic thêm bộ lọc bảo mật rồi chạy quy trình nâng cấp thông thường, vì vậy một gói được nêu tên trong thông báo sẽ được nâng cấp lên phiên bản mới nhất trong repository và kéo theo các dependency của nó. Bước nhỏ hơn, chỉ nâng cấp lên phiên bản sớm nhất có chứa bản vá, là dnf upgrade-minimal --security khi chạy thủ công. dnf-automatic không có cài đặt cho việc này.

Một lưu ý nữa áp dụng cho Rocky. Rocky tạo errata từ dữ liệu của Red Hat thông qua pipeline riêng, và pipeline đó đôi khi bị chậm trễ. Vào tháng 9 năm 2025, người dùng báo cáo rằng updateinfo.xml của Rocky 9 BaseOS đã không thay đổi từ tháng 12 năm 2024, dẫn đến việc --security thiếu các thông báo gần đây, và đội ngũ Rocky đã xác nhận đây là vấn đề đã biết. Nếu bạn phụ thuộc vào upgrade_type = security, hãy so sánh danh sách thông báo với các thông báo RLSA gần đây theo định kỳ. Trên một máy chủ mà độ bao phủ bảo mật quan trọng hơn kiểm soát thay đổi, upgrade_type = default theo lịch trình bạn chọn là cài đặt an toàn hơn.

Systemd timer thực hiện tác vụ

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers sẽ in ra một dòng với thời gian NEXT cách thời điểm hiện tại khoảng một ngày. Nếu bảng trống nghĩa là timer chưa được enable, nên tác vụ sẽ không bao giờ chạy.

Timer mặc định kích hoạt vào *-*-* 6:00 với RandomizedDelaySec=60m và Persistent=true. Độ trễ ngẫu nhiên giúp phân tán tải trên toàn bộ hệ thống trong vòng một giờ để tránh việc mọi máy chủ cùng truy cập vào mirror tại một thời điểm. Persistent=true nghĩa là nếu máy chủ tắt nguồn vào lúc 06:00, nó sẽ chạy tác vụ bị bỏ lỡ ngay sau khi khởi động thay vì bỏ qua cả ngày đó.

Thay đổi lịch trình bằng file drop-in. Không chỉnh sửa unit mặc định vì khi cập nhật gói, các file trong /usr/lib/systemd/system sẽ bị ghi đè.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

Dòng OnCalendar= trống là bắt buộc. OnCalendar có tính chất cộng dồn, nếu không reset, bạn sẽ giữ lại lịch 06:00 cũ và thêm một lịch mới, khiến tác vụ chạy hai lần mỗi ngày. Xác nhận kết quả bằng systemctl list-timers dnf-automatic.timer và kiểm tra cột NEXT. Các quy tắc drop-in tương tự áp dụng cho mọi tác vụ khác mà bạn lên lịch, nội dung này được đề cập trong viết systemd service và timer unit.

Đây là bẫy cần lưu ý. Gói phần mềm cung cấp thêm ba timer khác: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer và dnf-automatic-install.timer. Mỗi timer khởi chạy cùng một chương trình với các flag dòng lệnh, và các flag đó sẽ ghi đè lên download_updates và apply_updates trong file cấu hình của bạn. Nếu enable một trong số chúng cùng với dnf-automatic.timer, tác vụ sẽ chạy hai lần với hai hành vi khác nhau, trông giống như file cấu hình của bạn bị bỏ qua. Hãy chỉ enable một timer và kiểm tra:

systemctl list-unit-files 'dnf-automatic*'

Làm sao để biết thời điểm cài đặt một thứ gì đó?

emit_via trong phần [emitters] kiểm soát việc báo cáo. Với systemd, bộ phát stdio sẽ ghi vào journal, đây là tùy chọn đáng tin cậy vì nó không yêu cầu cài đặt thêm bất kỳ thành phần nào khác:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

Bộ phát motd ghi báo cáo vào /etc/motd và thay thế nội dung của tệp đó. Nếu bạn đang để banner đăng nhập ở đó, đừng sử dụng bộ phát này.

Bộ phát email mở một kết nối SMTP (simple mail transfer protocol) tới email_host trên cổng email_port, mặc định là localhost và 25. Một VPS mới không có dịch vụ nào đang lắng nghe tại đó, nên kết nối sẽ bị từ chối và không có email nào được gửi đi. Hãy chạy ss -lnt | grep ':25' trước khi bạn dựa vào nó, và thiết lập một Postfix chỉ làm relay nếu đầu ra trống. Khi email hoạt động, tiêu đề thư sẽ là Updates applied on 'web01'., lấy tên từ system_name.

Đối với bất kỳ mục đích nào khác, bộ phát command sẽ chuyển báo cáo đến chương trình của bạn thông qua đầu vào tiêu chuẩn (standard input):

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages mặc định là no, nghĩa là một lần chạy thất bại sẽ không báo cáo gì cả. Hãy bật nó lên. Một hệ thống vá lỗi chỉ thông báo khi thành công còn tệ hơn là không có hệ thống nào, vì sự im lặng đó dễ bị hiểu nhầm là hệ thống vẫn ổn định.

dnf-automatic không tự khởi động lại các service của bạn

Việc cài đặt một gói phần mềm chỉ thay thế các file trên ổ đĩa. Một tiến trình đang chạy vẫn giữ mã cũ trong bộ nhớ, vì vậy một thư viện đã được vá sẽ không có tác dụng gì với một daemon đã khởi động từ tháng trước. Khoảng cách giữa trạng thái đã cài đặt và trạng thái thực thi là lý do tại sao việc vá lỗi tự động cần một chính sách khởi động lại thay vì chỉ có chính sách cài đặt.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s liệt kê các service systemd có file bị thay đổi sau khi chúng khởi động. -r trả lời một câu hỏi và in ra một trong hai khối thông tin:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r không phải là một công cụ phân tích chuyên sâu. Nó kiểm tra một danh sách cố định các gói: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon và microcode_ctl. Nếu một trong số chúng được cài đặt sau lần boot cuối cùng, bạn sẽ nhận được câu trả lời đầu tiên. Hãy thêm tên các gói của riêng bạn vào một file có đuôi .conf nằm trong /etc/dnf/plugins/needs-restarting.d/ khi có thành phần khác trên máy chủ cũng cần khởi động lại để áp dụng thay đổi.

Một lưu ý cho các script: dnf needs-restarting -r trả về mã thoát khác 0 khi cần khởi động lại và cả khi bản thân lệnh đó bị lỗi, vì vậy không thể chỉ dựa vào mã thoát để phân biệt hai trường hợp này. Hãy đọc nội dung văn bản đầu ra.

Khởi động lại một service là thao tác nhỏ hơn và thường là lựa chọn đúng đắn. Hãy khởi động lại SSH daemon từ một phiên SSH thứ hai đang mở sẵn để tránh bị khóa khỏi hệ thống nếu cấu hình bị lỗi. Kernel mới là trường hợp duy nhất cần khởi động lại máy, vì kernel đang chạy không thể được thay thế trực tiếp. Nếu bạn muốn phân loại các bản cập nhật trong ngày vào hai nhóm này, những bản cập nhật nào cần khởi động lại máy và những bản nào chỉ cần khởi động lại service sẽ giúp bạn xử lý từng gói một dựa trên đầu ra.

Container là một trường hợp riêng biệt, vì dnf-automatic chỉ vá các gói trên host và không bao giờ can thiệp vào userland được đóng gói trong image. Do đó, một máy chủ đang chạy Docker Engine trên Rocky Linux hoặc AlmaLinux cũng cần phải pull lại các image và tạo lại các container trước khi bản vá có thể áp dụng cho mã nguồn đang thực sự phục vụ lưu lượng truy cập.

Máy chủ có nên tự khởi động lại không?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never là giá trị mặc định. when-changed sẽ khởi động lại sau khi áp dụng bất kỳ bản cập nhật nào. when-needed chỉ khởi động lại khi quá trình kiểm tra đằng sau needs-restarting -r xác định có gói core nào được thay thế, đây là lựa chọn mà hầu hết người dùng sở hữu một máy chủ đơn lẻ mong muốn, kết hợp với một khoảng thời gian định sẵn do họ tự chọn. Giá trị mặc định reboot_command sẽ cảnh báo người dùng đang đăng nhập trong năm phút thông qua shutdown, và bạn có thể kéo dài khoảng thời gian này.

Hãy xác định hai vấn đề trước khi bật tính năng này. Mọi dịch vụ mà bạn phụ thuộc vào phải tự khởi động cùng hệ thống, đây thường là thiếu sót đối với Docker Compose stack được khởi động thủ công. Ngoài ra, bạn cần có quyền truy cập console hoặc chế độ rescue từ nhà cung cấp, vì một kernel không khởi động được sẽ không thể sửa chữa qua SSH. Nếu thiếu một trong hai điều kiện trên, hãy giữ nguyên reboot = never và tự khởi động lại sau khi đã đọc log trong journal.

Rocky, AlmaLinux và CentOS Stream: sự khác biệt

Trên Rocky 9 và AlmaLinux 9, mọi thứ nêu trên đều giống hệt nhau, từ đường dẫn cấu hình cho đến tên unit. Cả hai đều công bố errata, vì vậy upgrade_type = security có dữ liệu để lọc. Lỗi errata cũ của Rocky đã mô tả trước đó là một trong số ít những điểm mà hành vi vận hành hàng ngày của chúng thực sự khác biệt, vì vậy nếu bạn chưa xây dựng máy chủ, hãy cân nhắc điều này cùng với cam kết tương thích và hỗ trợ CPU cũ vốn là điểm khác biệt giữa hai hệ điều hành này.

CentOS Stream là một ngoại lệ, và là một ngoại lệ khó xử lý. Các repository của Stream không chứa updateinfo.xml, vì vậy bộ lọc bảo mật không bao giờ khớp và mọi lần chạy đều báo No security updates needed. Trên Stream, hãy sử dụng upgrade_type = default và chấp nhận rằng bạn sẽ nhận mọi bản cập nhật. Stream cũng chạy trước RHEL, vì vậy các thiết lập trên máy Stream sẽ thay đổi nhiều hơn so với cùng thiết lập đó trên Rocky hoặc AlmaLinux. Sự khác biệt này không phải là lỗi đóng gói mà là kết quả từ quyết định năm 2020 của Red Hat khi chuyển CentOS thành bản xem trước (rolling preview) của RHEL, đây cũng chính là quyết định đã dẫn đến sự ra đời của Rocky Linux và AlmaLinux.

Rocky 10 và AlmaLinux 10 đã chuyển sang DNF5, dẫn đến việc đổi tên một số thành phần. Tài liệu DNF5 từ upstream chỉ định timer là dnf5-automatic.timer, đặt các mặc định được cài sẵn vào /usr/share/dnf5/dnf5-plugins/automatic.conf với các ghi đè của bạn vẫn nằm trong /etc/dnf/automatic.conf, mặc định download_updates thành yes thay vì no, và thêm distro-sync như một upgrade_type. Truy vấn advisory hiện là dnf advisory list, với updateinfo được giữ lại như một alias. Hãy xác nhận phiên bản của bạn thực sự đã cài đặt những gì trước khi sao chép tên gói hoặc tên unit từ một hướng dẫn viết cho bản 9:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

Nhiều hướng dẫn đã xuất bản về chủ đề này vẫn chỉ bao gồm Rocky 8. Tập hợp các tùy chọn đã mở rộng kể từ khi các tài liệu đó được viết, vì vậy hãy kiểm tra file cấu hình có chú thích trên chính máy chủ của bạn thay vì tin tưởng vào một bài viết cũ.

Các chế độ lỗi và thông báo bạn sẽ thấy

Không có gì chạy cả. systemctl list-timers dnf-automatic.timer in ra một bảng trống và systemctl is-enabled dnf-automatic.timer in ra disabled. Gói đã được cài đặt, nhưng timer thì chưa.

Job chạy nhưng không cài đặt gì cả. Journal chứa No security updates needed, but 3 updates available. Bộ lọc bảo mật không khớp với bất kỳ thứ gì, hoặc do không có bản tin tư vấn (advisory) nào đang chờ xử lý, hoặc do kho lưu trữ không công bố dữ liệu tư vấn.

Một thiết lập có vẻ bị bỏ qua. DNF ghi log một tùy chọn không xác định trong automatic.conf ở mức debug rồi sử dụng giá trị mặc định, vì vậy một key viết sai chính tả sẽ không thay đổi gì và không cảnh báo ai cả. Bạn viết apply_update = yes nhưng apply_updates vẫn ở mức no, khiến máy chủ tải xuống mãi mãi mà không bao giờ cài đặt. Sau bất kỳ chỉnh sửa nào, hãy chạy sudo systemctl start dnf-automatic.service và đọc journal thay vì tin tưởng vào file cấu hình.

Job chạy hai lần một ngày. Hai timer đang được enable. systemctl list-unit-files 'dnf-automatic*' sẽ cho biết timer nào, và các timer thừa đang truyền các flag ghi đè lên file cấu hình của bạn.

Không có email nào được gửi đến. Hoặc không có tiến trình nào đang lắng nghe trên cổng 25 cho bộ phát email, hoặc send_error_messages vẫn đang là no và thông tin duy nhất đáng báo cáo là lỗi.

Một service đã được patch vẫn báo phiên bản cũ. File trên đĩa đã mới nhưng tiến trình trong bộ nhớ vẫn là bản cũ. dnf needs-restarting -s liệt kê các service cần restart.

FAQ

dnf-automatic có chỉ cài đặt các bản cập nhật bảo mật trên Rocky Linux không?

Chỉ khi bạn thiết lập upgrade_type = security trong /etc/dnf/automatic.conf, và chỉ khi các repository của bạn có công bố metadata errata. Cả Rocky Linux và AlmaLinux đều công bố thông tin này, nên bộ lọc có dữ liệu để đối chiếu. Mặc định được cài sẵn là upgrade_type = default, nó sẽ cài đặt mọi bản cập nhật khả dụng ngay khi apply_updates = yes.

Tại sao dnf-automatic báo "No security updates needed, but 3 updates available"?

DNF xác định đâu là bản cập nhật bảo mật bằng cách đọc updateinfo.xml từ repository, nơi mỗi advisory liệt kê các gói cần sửa lỗi. Khi metadata này bị thiếu hoặc cũ, bộ lọc bảo mật sẽ không tìm thấy kết quả nào trong khi các bản cập nhật thông thường vẫn đang chờ xử lý, dẫn đến thông báo trên. Điều này thường xảy ra trên CentOS Stream vì hệ điều hành này không công bố errata. Trên Rocky hoặc AlmaLinux, hãy so sánh dnf updateinfo list --security với dnf check-update và kiểm tra xem metadata của bạn đã cập nhật chưa.

dnf-automatic có tự khởi động lại server sau khi cập nhật kernel không?

Không, trừ khi bạn yêu cầu. Tùy chọn reboot mặc định là never. Hãy thiết lập reboot = when-needed để hệ thống chỉ khởi động lại khi quá trình kiểm tra của dnf needs-restarting -r phát hiện các gói lõi như kernel hoặc glibc đã bị thay thế kể từ lần boot gần nhất. reboot = when-changed sẽ khởi động lại sau bất kỳ bản cập nhật nào được áp dụng. Cả hai đều sử dụng reboot_command, mặc định là shutdown -r +5 kèm theo thông báo cảnh báo cho người dùng đang đăng nhập.

Làm thế nào để thay đổi thời gian dnf-automatic chạy?

Chạy sudo systemctl edit dnf-automatic.timer và thêm một section [Timer] với một dòng OnCalendar= trống, theo sau là lịch trình của bạn, ví dụ OnCalendar=*-*-* 03:30. Dòng trống là bắt buộc vì OnCalendar có tính chất cộng dồn, nếu bỏ qua nó, hệ thống sẽ giữ lịch chạy mặc định lúc 06:00 và thêm một lịch mới. Xác nhận lại bằng systemctl list-timers dnf-automatic.timer và kiểm tra cột NEXT.

Tôi có cần kiểm tra server nếu nó đã tự vá lỗi không?

Có. dnf-automatic chỉ cài đặt các gói và dừng lại ở đó. Nó không tự khởi động lại các daemon, và nó không báo cáo bất cứ điều gì trừ khi emit_via chỉ định một emitter mà bạn thực sự đọc. Hãy thiết lập emit_via thành stdio ở mức tối thiểu, bật send_error_messages để các lỗi cũng được báo cáo, và chạy dnf needs-restarting -s sau mỗi đợt vá lỗi để tìm các service vẫn đang chạy mã cũ.