הגדרת עדכוני אבטחה אוטומטיים ב-Rocky Linux ו-AlmaLinux

מה עושה dnf-automatic ב-Rocky Linux וב-AlmaLinux

הכלי dnf-automatic הוא הדרך לבצע עדכוני אבטחה ללא השגחה ב-Rocky Linux וב-AlmaLinux. מדובר בתוכנית קטנה, המופעלת על ידי טיימר של systemd, הקוראת את /etc/dnf/automatic.conf ומיישמת את מה שקובץ זה מתיר. ההתקנה דורשת פקודה אחת בלבד. שאר המדריך עוסק בהגדרות הקובעות אם הכלי יגן על השרת או יפעל בשקט מבלי לבצע דבר.

אם הגעתם מ-Debian או מ-Ubuntu, מדובר באותו תפקיד ש-unattended-upgrades מבצע ב-VPS מבוסס Ubuntu. הבדל אחד חשוב יותר מכל השאר: מה המשמעות של המילה "אבטחה" עבור מנהל החבילות. ב-Ubuntu מדובר במאגר נפרד. במשפחת RHEL מדובר במטא-דאטה המצורף להודעות אבטחה (advisories), ומטא-דאטה זה עלול להיות חסר או לא מעודכן. אם תפנו את dnf-automatic למאגר ללא נתוני אבטחה, הוא לא יתקין דבר וידווח על הצלחה.

מדריך זה נכתב עבור Rocky Linux 9 ו-AlmaLinux 9, המשתמשות ב-DNF 4 (מנהל החבילות במשפחת RHEL), נכון לאוגוסט 2026. גרסאות 10 עברו ל-DNF5 ושם שמות הקבצים משתנים, לכן הן קיבלו סעיף נפרד לקראת הסוף. כל פקודה להלן מיועדת להרצה בשרת שלכם, כאשר הפלט הצפוי מופיע לצדה.

התקנת dnf-automatic וקריאת קובץ התצורה המצורף

הפעלת עדכונים אוטומטיים צריכה להתבצע כחלק מהגדרת השרת הראשונית, כפי שמתואר ב-עשר הדקות הראשונות בשרת VPS חדש, מיד לאחר יצירת משתמש שאינו root והגדרת חומת אש. אם טרם הגדרתם חומת אש, firewalld הוא הכלי שמגיע כברירת מחדל ב-Rocky ו-AlmaLinux, ובעזרת מספר פקודות בודדות ניתן לאפשר גישת SSH, לפתוח את הפורט שבו השירות שלכם מאזין, ולוודא שהגדרות אלו נשמרות גם לאחר אתחול.

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

systemctl is-enabled מציג disabled בהתקנה נקייה, כיוון שהתקנת החבילה אינה מפעילה דבר. זו הסיבה הנפוצה ביותר לכך ששרת שבו מותקן dnf-automatic מעולם לא החיל עדכון אחד.

גרסת ה-DNF משפיעה על אפשרות אחת. ההגדרה reboot נוספה במעלה הזרם (upstream) ב-DNF 4.15, ו-Red Hat ביצעה לה backport ל-dnf-4.14.0-6.el9 בנובמבר 2023 באמצעות העדכון RHBA-2023:6645. הפצות Rocky 9 ו-AlmaLinux 9 בונות מחדש את החבילה הזו, לכן שרת מעודכן יכלול אותה, בעוד שרת שלא עודכן מאז 2023 לא יכלול אותה.

קובץ התצורה הוא /etc/dnf/automatic.conf. העותק שמגיע עם החבילה מפרט את כל האפשרויות שהגרסה הנוכחית מכירה, כאשר ערכי ברירת המחדל מופיעים כהערות. קראו את הקובץ פעם אחת לפני העריכה, שכן הוא המקור המהימן ביותר להגדרות בגרסה שלכם.

שני המתגים הקובעים את אופן הפעולה

download_updates ו-apply_updates במקטע [commands] קובעים את התנהגות המערכת. שניהם מוגדרים כ-no כברירת מחדל ב-EL9 (Enterprise Linux 9, בסיס המערכת המשותף ל-Rocky 9 ו-AlmaLinux 9), לכן הפעלה של dnf-automatic ללא שינויים תציג רק את העדכונים הזמינים.

• שניהם no: dnf-automatic מדווח על עדכונים זמינים ואינו משנה דבר בשרת.
• download_updates = yes עם apply_updates = no: חבילות נמשכות אל ה-cache של DNF. ההתקנה תהיה מהירה ולא תדרוש רשת, אך שום דבר לא ישתנה הלילה.
• שניהם yes עם upgrade_type = default: כל עדכון זמין מותקן, ללא קשר לסיווג האבטחה שלו.
• שניהם yes עם upgrade_type = security: רק חבילות המופיעות בהתראת אבטחה מותקנות.

נקודת התחלה סבירה עבור שרת VPS חשוף לאינטרנט:

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

network_online_timeout הוא מספר השניות שהתהליך ימתין לרשת תקינה לפני שיוותר, נתון קריטי עבור שרת שזה עתה עלה. random_sleep היא שיטה ישנה לפיזור עומסים בין שרתים רבים, כיום ה-timer מבצע את התפקיד הזה. הריצו את systemctl cat dnf-automatic.service כדי לראות את ה-flags המדויקים שמועברים לשירות כפי שהוא מגיע מהפצתו.

ודאו שהקובץ מבצע את הפעולה הרצויה, מבלי להמתין לשעה 06:00:

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

ה-journal מציג את מה שהתהליך בחן ואת הפעולות שביצע. ניתן גם לכפות התנהגות מסוימת משורת הפקודה, מה שדורס את הגדרות הקובץ עבור הרצה זו בלבד:

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

מה המשמעות האמיתית של upgrade_type = security ב-Rocky וב-Alma

‏DNF לא קובע אם עדכון הוא עדכון אבטחה על ידי השוואת מספרי גרסאות. הוא קורא מטא-נתונים של errata: קובץ בשם updateinfo.xml המתפרסם בתוך המאגר (repository), שבו כל התראה (advisory) מפרטת את החבילות שמתקנות אותה. AlmaLinux מפרסמת התראות אלו כ-ALSA, ו-Rocky מפרסמת אותן כ-RLSA. ‏upgrade_type = security בונה מסנן מתוך המטא-נתונים האלו ומשדרגת רק את החבילות התואמות לו.

נובעות מכך שתי השלכות, ושתי הן מפתיעות משתמשים.

ראשית, ללא מטא-נתונים אין עדכונים. אם המאגר אינו מכיל updateinfo.xml, המסנן לא מוצא התאמות והפעולה מסתיימת עם השורה הבאה ביומן (journal):

No security updates needed, but 3 updates available

המערכת אינה מעודכנת בתיקוני אבטחה, ושום דבר לא דיווח על כשל. בדקו זאת בעצמכם:

dnf updateinfo list --security
dnf check-update

אם dnf check-update מציג רשימת חבילות בעוד ש-dnf updateinfo list --security אינו מדפיס דבר, סימן שאו שאין עדכונים ממתינים עם התראה, או שלמאגר אין נתוני התראות לקריאה. Rocky ו-AlmaLinux שתיהן מפרסמות נתונים אלו, כך שבשתי ההפצות הללו רשימה ריקה היא בדרך כלל מצב תקין. CentOS Stream אינה מפרסמת נתונים אלו כלל.

שנית, מצב אבטחה אינו מבצע שינוי מינימלי. ‏dnf-automatic מוסיף את מסנן האבטחה ולאחר מכן מריץ את נתיב השדרוג הרגיל; לכן, חבילה המופיעה בהתראה עוברת לגרסה החדשה ביותר במאגר וגוררת איתה את התלויות שלה. הצעד המצומצם יותר, מעבר רק לגרסה המוקדמת ביותר שמתקנת את ההתראה, הוא dnf upgrade-minimal --security שמתבצע ידנית. ל-dnf-automatic אין הגדרה לכך.

סייג נוסף חל על Rocky. ‏Rocky מייצרת את ה-errata שלה מנתוני Red Hat דרך צינור עיבוד (pipeline) משלה, וצינור זה לעיתים מפגר מאחור. בספטמבר 2025 דיווחו משתמשים כי ה-updateinfo.xml של Rocky 9 BaseOS לא התעדכן מאז דצמבר 2024, ולכן --security החסיר התראות עדכניות; צוות Rocky אישר כי מדובר בבעיה ידועה. אם אתם מסתמכים על upgrade_type = security, השוו את רשימת ההתראות מול הודעות RLSA האחרונות מעת לעת. במערכת שבה הכיסוי חשוב יותר מבקרת שינויים, upgrade_type = default בלוח זמנים שתבחרו הוא ההגדרה הבטוחה יותר.

טיימר ה-systemd שמריץ את המשימה בפועל

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

list-timers אמור להציג שורה אחת עם זמן NEXT שחל בעוד כיום. טבלה ריקה משמעותה שהטיימר אינו פעיל, ולכן המשימה לא תרוץ לעולם.

הטיימר שמגיע עם החבילה מופעל ב-*-*-* 6:00 עם RandomizedDelaySec=60m ו-Persistent=true. השהיה אקראית מפזרת את העומס על פני שעה, כדי שלא כל השרתים יפנו למראה (mirror) באותה שנייה בדיוק. Persistent=true משמעותו שמכונה שהייתה כבויה בשעה 06:00 תריץ את המשימה שהוחמצה מיד לאחר העלייה, במקום לדלג על אותו יום.

שנו את לוח הזמנים באמצעות קובץ drop-in. אל תערכו את יחידת ה-unit המקורית, כיוון ששדרוג חבילה דורס קבצים תחת /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

שורת ה-OnCalendar= הריקה היא הכרחית. OnCalendar מצטבר, לכן ללא איפוס זה, הערך של 06:00 יישאר ותתווסף כניסה שנייה, מה שיגרום למשימה לרוץ פעמיים ביום. אשרו את התוצאה באמצעות systemctl list-timers dnf-automatic.timer וקראו את עמודת ה-NEXT. אותם כללי drop-in חלים על כל משימה אחרת שתתזמנו, נושא המכוסה ב-כתיבת יחידות service ו-timer ב-systemd.

כעת, המלכודת. החבילה מספקת שלושה טיימרים נוספים: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer ו-dnf-automatic-install.timer. כל אחד מהם מפעיל את אותה תוכנית עם דגלי שורת פקודה, ודגלים אלו דורסים את download_updates ו-apply_updates מקובץ התצורה שלכם. אם תפעילו אחד מהם לצד dnf-automatic.timer, המשימה תרוץ פעמיים עם התנהגויות שונות, מה שייראה בדיוק כאילו קובץ התצורה שלכם אינו נלקח בחשבון. הפעילו טיימר אחד ובדקו:

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

כיצד אדע מתי בוצעה התקנה?

emit_via במקטע [emitters] שולט על הדיווח. תחת systemd, הפולט stdio כותב ל-journal, וזו האפשרות האמינה ביותר כיוון שהיא אינה דורשת התקנה של רכיבים נוספים:

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

הפולט motd כותב את הדוח לתוך /etc/motd ומחליף את תוכן הקובץ. אם אתם שומרים שם באנר התחברות (login banner), אל תשתמשו בפולט זה.

הפולט email פותח חיבור SMTP (פרוטוקול העברת דואר פשוט) אל email_host בפורט email_port, שערכי ברירת המחדל שלהם הם localhost ו-25. בשרת VPS חדש אין שירות המאזין בפורט זה, לכן החיבור נדחה ולא נשלח דואר. הריצו את ss -lnt | grep ':25' לפני שתסתמכו על אפשרות זו, והגדירו Postfix במצב relay-only אם הפלט נותר ריק. כאשר הדואר עובד, שורת הנושא תהיה Updates applied on 'web01'., והיא תשאב את השם מתוך system_name.

לכל מטרה אחרת, הפולט command מעביר את הדוח לתוכנית שלכם דרך הקלט הסטנדרטי (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 הוא no, מה שאומר שריצה שנכשלה לא תדווח על דבר. הפעילו הגדרה זו. מערכת עדכונים שמדווחת רק על הצלחות גרועה יותר ממערכת שאינה מדווחת כלל, כיוון שהשתיקה מתפרשת כמצב תקין.

dnf-automatic אינו מבצע הפעלה מחדש לשירותים שלכם

התקנת חבילה מחליפה קבצים על הדיסק. תהליך שכבר רץ שומר את הקוד הישן בזיכרון, לכן ספרייה שעברה תיקון (patch) אינה משפיעה על daemon שהופעל לפני חודש. הפער הזה בין מה שמותקן לבין מה שפעיל בפועל הוא הסיבה לכך שעדכונים אוטומטיים דורשים מדיניות הפעלה מחדש, ולא רק מדיניות התקנה.

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

-s מציג את שירותי ה-systemd שהקבצים שלהם השתנו מאז שהם הופעלו. -r עונה על שאלה אחת ומדפיס אחד משני בלוקים:

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 אינו כלי לניתוח מעמיק. הוא בודק רשימה קבועה של חבילות: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon ו-microcode_ctl. אם אחת מהן הותקנה לאחר ה-boot האחרון, תקבלו את התשובה הראשונה. הוסיפו שמות חבילות משלכם לקובץ שמסתיים ב-.conf תחת /etc/dnf/plugins/needs-restarting.d/ כאשר רכיב אחר בשרת דורש גם הוא הפעלה מחדש כדי שהשינויים ייכנסו לתוקף.

סייג אחד עבור סקריפטים: dnf needs-restarting -r מסיים עם קוד יציאה שאינו אפס גם כאשר נדרש reboot וגם כאשר הפקודה עצמה נכשלה, לכן לא ניתן להבחין ביניהם רק לפי קוד היציאה. קראו את טקסט הפלט.

הפעלה מחדש של שירות היא הצעד הקטן יותר ובדרך כלל הנכון. הפעילו מחדש את ה-SSH daemon מתוך סשן SSH שני שכבר פתוח, כדי שתצורה שגויה לא תנעל אתכם מחוץ לשרת. kernel חדש הוא המקרה שבו רק reboot עוזר, כיוון שלא ניתן להחליף kernel פעיל בזמן ריצה. אם ברצונכם למיין את העדכונים של בוקר נתון לשתי הקטגוריות הללו, אילו עדכונים דורשים reboot ואילו דורשים רק הפעלה מחדש של שירות עובר על הפלט חבילה אחר חבילה.

מכולות (Containers) הן מקרה נפרד, כיוון ש-dnf-automatic מעדכן את החבילות של ה-host ולעולם אינו נוגע ב-userland המוטמע בתוך image. לכן, שרת שמריץ Docker Engine על Rocky Linux או AlmaLinux דורש גם משיכה מחדש של ה-images ויצירה מחדש של המכולות לפני שהתיקון יגיע לקוד שמשרת בפועל את התעבורה.

האם על השרת לבצע אתחול עצמי?

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

ברירת המחדל היא reboot = never. ההגדרה when-changed מבצעת אתחול לאחר כל עדכון שיושם. ההגדרה when-needed מבצעת אתחול רק כאשר הבדיקה שמאחורי needs-restarting -r מזהה שחבילת ליבה הוחלפה; זהו המצב המועדף על רוב בעלי השרתים הבודדים, בשילוב עם חלון זמן שהוגדר על ידם. ברירת המחדל reboot_command מספקת למשתמשים מחוברים התראה של חמש דקות באמצעות shutdown, וניתן להרחיב טווח זה.

הסדירו שני דברים לפני הפעלת אפשרות זו. כל שירות שאתם מסתמכים עליו חייב לעלות באופן עצמאי בזמן האתחול; זהו הפער הנפוץ במערך Docker Compose שהופעל ידנית. כמו כן, עליכם לוודא שיש לכם גישת קונסולה או גישת הצלה (rescue) מהספק שלכם, כיוון שלא ניתן לתקן ליבה שאינה עולה דרך SSH. אם אחד מהתנאים הללו חסר, השאירו את reboot = never ובצעו אתחול בעצמכם לאחר קריאת ה-journal.

Rocky, AlmaLinux ו-CentOS Stream: ההבדלים ביניהן

ב-Rocky 9 וב-AlmaLinux 9 כל האמור לעיל זהה לחלוטין, עד לרמת נתיבי התצורה ושמות ה-unit. שתי ההפצות מפרסמות errata, ולכן ל-upgrade_type = security יש נתונים שניתן לסנן לפיהם. ה-errata המיושן של Rocky שתואר קודם לכן הוא אחד המקומות הבודדים שבהם התנהלותן היומיומית נבדלת; אם השרת טרם הוקם, שקלו זאת לצד הבטחת התאימות והתמיכה במעבדים ישנים שמבדילות בין השתיים.

CentOS Stream היא היוצאת מן הכלל, וההבדל בה משמעותי. מאגרי החבילות של Stream אינם מכילים updateinfo.xml, ולכן מסנן האבטחה לעולם לא ימצא התאמה וכל הרצה תדווח על No security updates needed. ב-Stream, השתמשו ב-upgrade_type = default וקבלו את העובדה שאתם מקבלים את כל העדכונים. בנוסף, Stream מקדימה את RHEL, ולכן הגדרה מסוימת עשויה להשתנות בשרת Stream בתדירות גבוהה יותר מאשר ב-Rocky או ב-AlmaLinux. הבדל זה אינו מקרי, אלא תוצאה של החלטת Red Hat משנת 2020 להפוך את CentOS לגרסת תצוגה מקדימה מתגלגלת (rolling preview) של RHEL, שהיא אותה החלטה שהובילה להקמתן של Rocky Linux ו-AlmaLinux.

גרסאות Rocky 10 ו-AlmaLinux 10 עברו ל-DNF5, מה שמשנה את שמות הרכיבים. תיעוד ה-DNF5 הרשמי מציין את הטיימר כ-dnf5-automatic.timer, מציב את ברירות המחדל המופצות ב-/usr/share/dnf5/dnf5-plugins/automatic.conf כאשר הדריסות (overrides) שלכם נשמרות ב-/etc/dnf/automatic.conf, קובע את ברירת המחדל של download_updates ל-yes במקום ל-no, ומוסיף את distro-sync כ-upgrade_type. שאילתת ה-advisory מתבצעת כעת באמצעות dnf advisory list, כאשר updateinfo נשמר ככינוי (alias). ודאו מה מותקן בפועל בגרסה שלכם לפני העתקת שמות חבילות או שמות unit ממדריך שנכתב עבור גרסה 9:

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

מדריכים רבים שפורסמו בנושא זה עדיין מכסים רק את Rocky 8. מאז כתיבתם נוספו אפשרויות חדשות, לכן בדקו את הקובץ עם ההערות בשרת שלכם במקום להסתמך על מאמר ישן.

מצבי כשל והודעות שתיתקל בהן

שום דבר לא רץ. systemctl list-timers dnf-automatic.timer מדפיס טבלה ריקה ו-systemctl is-enabled dnf-automatic.timer מדפיס disabled. החבילה הותקנה, אך ה-timer מעולם לא הופעל.

המשימה רצה אך לא מתקינה דבר. ה-journal מכיל No security updates needed, but 3 updates available. מסנן האבטחה לא מצא התאמות, או משום שאין עדכונים ממתינים עם advisory, או משום שה-repository אינו מפרסם נתוני advisory כלל.

הגדרה נראית כאילו התעלמו ממנה. DNF מתעד אפשרות לא מוכרת ב-automatic.conf ברמת debug ואז משתמש בערך ברירת המחדל; לכן, מפתח עם שגיאת כתיב לא משנה דבר ולא מזהיר איש. כתוב apply_update = yes ו-apply_updates נשאר על no, כך שהשרת מוריד נתונים לנצח אך לא מתקין דבר. לאחר כל עריכה, הרץ את sudo systemctl start dnf-automatic.service וקרא את ה-journal במקום להסתמך על הקובץ.

המשימה רצה פעמיים ביום. שני timers מופעלים. systemctl list-unit-files 'dnf-automatic*' מציג אילו מהם פעילים, והנוספים מעבירים flags שגוברים על קובץ התצורה שלך.

לא מגיעים דוא"לים. או שאין שירות המאזין בפורט 25 עבור ה-emitter מסוג email, או ש-send_error_messages עדיין מוגדר כ-no והדבר היחיד שהיה ראוי לדווח עליו היה שגיאה.

שירות שעבר patch עדיין מדווח על גרסה ישנה. הקובץ בדיסק חדש אך התהליך בזיכרון ישן. dnf needs-restarting -s מציין את השירותים שיש לבצע להם restart.

FAQ

האם dnf-automatic מתקין רק עדכוני אבטחה ב-Rocky Linux?

רק אם תגדירו upgrade_type = security בתוך /etc/dnf/automatic.conf, ורק אם המאגרים (repositories) שלכם מפרסמים מטא-נתונים של errata. גם Rocky Linux וגם AlmaLinux מפרסמים נתונים אלו, לכן מסנן העדכונים יכול להשוות מול התראות אבטחה. ברירת המחדל שמגיעה עם התוכנה היא upgrade_type = default, אשר מתקינה כל עדכון זמין ברגע ש-apply_updates = yes מופעל.

מדוע dnf-automatic מדווח "No security updates needed, but 3 updates available"?

DNF קובע מה נחשב לעדכון אבטחה על ידי קריאת updateinfo.xml מהמאגר, שם כל התראה מפרטת את החבילות שמתקנות אותה. כאשר מטא-נתונים אלו חסרים או אינם מעודכנים, מסנן האבטחה לא מוצא התאמות בעוד שעדכונים רגילים עדיין ממתינים, מה שמפיק בדיוק את השורה הזו. זהו מצב צפוי ב-CentOS Stream, שאינו מפרסם errata כלל. ב-Rocky או ב-AlmaLinux, השוו את dnf updateinfo list --security מול dnf check-update וודאו שהמטא-נתונים שלכם מעודכנים.

האם dnf-automatic יבצע אתחול לשרת שלי לאחר עדכון ליבה (kernel)?

לא, אלא אם תגדירו זאת. האפשרות reboot מוגדרת כברירת מחדל ל-never. הגדירו reboot = when-needed והרצה תבצע אתחול רק כאשר הבדיקה שמאחורי dnf needs-restarting -r מזהה שחבילת ליבה כגון kernel או glibc הוחלפה מאז האתחול האחרון. reboot = when-changed מבצע אתחול לאחר כל עדכון שיושם. שניהם משתמשים ב-reboot_command, שמוגדר כברירת מחדל ל-shutdown -r +5 עם הודעת אזהרה למשתמשים מחוברים.

איך משנים את השעה שבה dnf-automatic רץ?

הריצו את sudo systemctl edit dnf-automatic.timer והוסיפו מקטע [Timer] עם שורת OnCalendar= ריקה, ולאחריה לוח הזמנים שלכם, לדוגמה OnCalendar=*-*-* 03:30. השורה הריקה נדרשת מכיוון ש-OnCalendar מצטבר, לכן השמטתה תשאיר את זמן ההרצה המקורי של 06:00 ותוסיף הרצה שנייה. אמת זאת באמצעות systemctl list-timers dnf-automatic.timer וקראו את עמודת NEXT.

האם אני עדיין צריך לבדוק שרת שמבצע לעצמו תיקוני אבטחה?

כן. dnf-automatic מתקין חבילות ועוצר שם. הוא אינו מבצע הפעלה מחדש לשירותים (daemons), והוא לא מדווח על דבר שתראו אלא אם emit_via מגדיר מפיץ התראות (emitter) שאתם באמת קוראים. הגדירו את emit_via ל-stdio לכל הפחות, הפעילו את send_error_messages כדי שגם כשלים ידווחו, והריצו את dnf needs-restarting -s לאחר חלון עדכונים כדי למצוא שירותים שעדיין מריצים קוד ישן.