Rocky اور AlmaLinux پر dnf-automatic سیکیورٹی اپ ڈیٹس

Rocky Linux اور AlmaLinux پر dnf-automatic کیا کرتا ہے

dnf-automatic Rocky Linux اور AlmaLinux پر unattended security updates حاصل کرنے کا طریقہ ہے۔ یہ ایک چھوٹا پروگرام ہے جسے systemd timer شروع کرتا ہے۔ یہ /etc/dnf/automatic.conf کو پڑھتا ہے اور اس file کی اجازت کے مطابق updates لاگو کرتا ہے۔ installation کے لیے ایک command کافی ہے۔ اس guide کا باقی حصہ ان settings کے بارے میں ہے جو طے کرتی ہیں کہ یہ server کو محفوظ رکھے گا یا خاموشی سے کچھ نہیں کرے گا۔

اگر آپ Debian یا Ubuntu سے آئے ہیں تو Ubuntu VPS پر unattended-upgrades جو کام کرتا ہے، dnf-automatic بھی وہی کام کرتا ہے۔ ایک فرق باقی تمام فرقوں سے زیادہ اہم ہے: package manager کے لیے لفظ "security" کا مطلب کیا ہے۔ Ubuntu میں یہ الگ archive pocket ہوتا ہے۔ RHEL family میں یہ published advisories کے ساتھ منسلک metadata ہوتا ہے، اور یہ metadata موجود نہ بھی ہو سکتا ہے یا پرانا ہو سکتا ہے۔ dnf-automatic کو ایسے repository کی طرف متعین کریں جس میں advisory data نہ ہو، تو یہ success report کرتے ہوئے بھی کچھ install نہیں کرتا۔

یہ guide Rocky Linux 9 اور AlmaLinux 9 کے مطابق لکھی گئی ہے۔ یہ دونوں DNF 4 استعمال کرتے ہیں؛ DNF، RHEL family کا package manager ہے۔ یہ معلومات August 2026 تک کی ہیں۔ 10 releases میں DNF5 استعمال ہوتا ہے اور وہاں نام تبدیل ہو جاتے ہیں، اس لیے ان کے لیے آخر کے قریب الگ section دیا گیا ہے۔ ذیل کی ہر command آپ اپنے server پر چلائیں گے، اور اس کے ساتھ متوقع output دیا گیا ہے۔

dnf-automatic انسٹال کریں اور اس کے ساتھ فراہم کی گئی configuration پڑھیں

خودکار updates فعال کرنا نئے VPS کے پہلے دس منٹ کی setup کا حصہ ہے۔ یہ کام non-root user اور firewall configure کرنے کے فوراً بعد کریں۔

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

نئی installation پر systemctl is-enabled، disabled دکھاتا ہے، کیونکہ package انسٹال کرنے سے کوئی سروس خودکار طور پر شروع نہیں ہوتی۔ یہی سب سے عام وجہ ہے کہ کسی سرور پر "dnf-automatic موجود" ہونے کے باوجود ایک بھی update لاگو نہیں ہوئی۔

ایک option کے لیے DNF version اہم ہے۔ reboot setting upstream میں DNF 4.15 میں شامل ہوئی۔ Red Hat نے اسے November 2023 میں advisory RHBA-2023:6645 کے ذریعے dnf-4.14.0-6.el9 میں backport کیا۔ Rocky 9 اور AlmaLinux 9 اس package کو rebuild کرتے ہیں، اس لیے موجودہ box میں یہ option موجود ہوتا ہے، لیکن 2023 سے update نہ کیے گئے box میں یہ موجود نہیں ہوتا۔

configuration file /etc/dnf/automatic.conf ہے۔ فراہم کی گئی copy میں اس build کی سمجھ میں آنے والی ہر option درج ہے اور اس کی default value comment کی گئی ہے۔ edit کرنے سے پہلے اسے ایک بار پڑھیں، کیونکہ آپ کے version کے بارے میں درست معلومات اسی file میں ہوتی ہیں۔

وہ دو switches جو نتیجہ طے کرتے ہیں

download_updates اور apply_updates، [commands] section میں رویہ طے کرتے ہیں۔ EL9 (enterprise Linux 9، Rocky 9 اور AlmaLinux 9 کی مشترکہ base) میں دونوں کی default value no ہوتی ہے۔ اس لیے enable کیا گیا، بغیر ترمیم کا dnf-automatic صرف دستیاب updates کے بارے میں بتائے گا۔

• دونوں no: dnf-automatic دستیاب updates کی اطلاع دیتا ہے اور system میں کچھ تبدیل نہیں کرتا۔
• download_updates = yes کے ساتھ apply_updates = no: packages، DNF cache میں fetch کیے جاتے ہیں۔ اس کے بعد installation تیز ہوتی ہے اور network کی ضرورت نہیں رہتی، لیکن آج رات کچھ تبدیل نہیں ہوتا۔
• دونوں yes کے ساتھ upgrade_type = default: ہر دستیاب update install کیا جاتا ہے، خواہ وہ security update ہو یا نہ ہو۔
• دونوں yes کے ساتھ upgrade_type = security: صرف وہ packages install کیے جاتے ہیں جن کے نام security advisory میں موجود ہوں۔

Public-facing VPS کے لیے ایک مناسب ابتدائی configuration یہ ہے:

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

network_online_timeout وہ seconds کی تعداد ہے جن تک run، network کے کام کرنے کا انتظار کرتا ہے، پھر ناکام ہو جاتا ہے۔ یہ اس system کے لیے اہم ہے جو ابھی boot ہوا ہو۔ random_sleep متعدد machines پر load تقسیم کرنے کا پرانا طریقہ ہے، اور اب timer یہی کام کرتا ہے۔ `systemctl cat dnf-automatic.service` چلائیں تاکہ shipped service کے ذریعے pass کیے جانے والے exact flags دیکھ سکیں۔

06:00 تک انتظار کیے بغیر تصدیق کریں کہ file وہی کام کرتی ہے جس کی آپ توقع رکھتے ہیں:

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

journal میں دکھایا جاتا ہے کہ run نے کن چیزوں پر غور کیا اور کیا کارروائی کی۔ آپ command line سے ایک رویہ بھی عارضی طور پر نافذ کر سکتے ہیں۔ اس سے صرف اسی run کے لیے file کی settings override ہوتی ہیں:

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

What upgrade_type = security really means on Rocky and Alma

DNF does not work out that an update is a security update by comparing version numbers. It reads errata metadata: a file called updateinfo.xml published inside the repository, where each advisory lists the packages that fix it. AlmaLinux publishes these as ALSA advisories, Rocky publishes them as RLSA. upgrade_type = security builds a filter from that metadata and upgrades only the packages it matches.

Two consequences follow, and both surprise people.

First, no metadata means no updates. If the repository carries no updateinfo.xml, the filter matches nothing and the run ends with this line in the journal:

No security updates needed, but 3 updates available

The box is not patched, and nothing reported a failure. Check it yourself:

dnf updateinfo list --security
dnf check-update

If dnf check-update lists packages while dnf updateinfo list --security prints nothing at all, either nothing pending carries an advisory, or the repository has no advisory data to read. Rocky and AlmaLinux both publish it, so on those two an empty list is usually honest. CentOS Stream does not publish it at all.

Second, security mode is not a minimal change. dnf-automatic adds the security filter and then runs the ordinary upgrade path, so a package named in an advisory moves to the newest version in the repository and pulls its dependencies with it. The smaller step, moving only to the earliest version that fixes the advisory, is dnf upgrade-minimal --security run by hand. dnf-automatic has no setting for it.

One more caveat applies to Rocky. Rocky generates its errata from Red Hat data through its own pipeline, and that pipeline has fallen behind. In September 2025 users reported that the Rocky 9 BaseOS updateinfo.xml had not moved since December 2024, so --security was missing recent advisories, and Rocky staff confirmed it as a known issue. If you depend on upgrade_type = security, compare the advisory list against recent RLSA announcements now and then. On a box where coverage matters more than change control, upgrade_type = default on a schedule you choose is the safer setting.

وہ systemd timer جو اسے حقیقتاً چلاتا ہے

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

list-timers کو تقریباً ایک دن بعد کے NEXT وقت کے ساتھ ایک قطار دکھانی چاہیے۔ خالی table کا مطلب ہے کہ timer enabled نہیں ہے، اس لیے یہ کبھی نہیں چلے گا۔

شپ کیا گیا timer *-*-* 6:00 پر RandomizedDelaySec=60m اور Persistent=true کے ساتھ چلتا ہے۔ random delay سرورز کے ایک پورے fleet کو ایک گھنٹے میں پھیلا دیتا ہے، تاکہ ہر server اسی سیکنڈ میں mirror سے رابطہ نہ کرے۔ Persistent=true کا مطلب ہے کہ جو machine 06:00 پر powered off ہو، وہ boot ہونے کے کچھ دیر بعد چھوٹا ہوا job چلاتی ہے، دن کا job skip نہیں کرتی۔

schedule تبدیل کرنے کے لیے drop-in استعمال کریں۔ shipped unit میں ترمیم نہ کریں، کیونکہ package upgrade /usr/lib/systemd/system کے اندر موجود files کو replace کر دیتا ہے۔

sudo systemctl edit dnf-automatic.timer

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

خالی OnCalendar= line ضروری ہے۔ OnCalendar کی values جمع ہوتی رہتی ہیں، اس لیے reset کے بغیر 06:00 والی entry برقرار رہتی ہے اور دوسری entry شامل ہو جاتی ہے؛ نتیجتاً job دن میں دو مرتبہ چلتا ہے۔ systemctl list-timers dnf-automatic.timer سے نتیجہ confirm کریں اور NEXT column پڑھیں۔ یہی drop-in rules ہر دوسری scheduled چیز پر بھی لاگو ہوتے ہیں۔ اس کی وضاحت systemd service اور timer units لکھنا میں کی گئی ہے۔

اب اہم مسئلہ دیکھیں۔ package مزید تین timers بھی ship کرتا ہے: dnf-automatic-notifyonly.timer، dnf-automatic-download.timer اور dnf-automatic-install.timer۔ ہر timer اسی program کو command-line flags کے ساتھ شروع کرتا ہے، اور یہ flags آپ کی config file میں موجود download_updates اور apply_updates کو override کرتے ہیں۔ dnf-automatic.timer کے ساتھ ان میں سے کسی ایک کو enable کرنے پر job دو مختلف behaviours کے ساتھ دو مرتبہ چلتا ہے۔ یہ بالکل ایسا دکھائی دیتا ہے جیسے config file کو نظرانداز کیا جا رہا ہو۔ ایک timer enable کریں اور تصدیق کریں:

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

کسی چیز کے install ہونے کا وقت کیسے معلوم کریں؟

emit_via، [emitters] section میں reporting کو کنٹرول کرتا ہے۔ systemd کے تحت stdio emitter journal میں لکھتا ہے۔ یہ قابلِ اعتماد اختیار ہے، کیونکہ اس کے لیے کوئی اضافی چیز install کرنا ضروری نہیں:

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

motd emitter رپورٹ کو /etc/motd میں لکھتا ہے اور اس file کا موجودہ content replace کر دیتا ہے۔ اگر وہاں login banner موجود ہو تو اس emitter کو شامل نہ کریں۔

email emitter، email_host سے SMTP (simple mail transfer protocol) connection بناتا ہے۔ یہ connection email_port پر بنتا ہے، جن کی default values بالترتیب localhost اور 25 ہیں۔ نئے VPS پر وہاں کوئی چیز listening نہیں کر رہی ہوتی، اس لیے connection refused ہو جاتا ہے اور کوئی mail نہیں بھیجی جاتی۔ اس پر انحصار کرنے سے پہلے ss -lnt | grep ':25' چلائیں۔ اگر output خالی ہو تو صرف relay کے لیے Postfix configure کریں۔ جب mail کام کرنے لگے تو subject میں Updates applied on 'web01'. لکھا ہوتا ہے، اور نام system_name سے لیا جاتا ہے۔

دیگر تمام صورتوں میں command emitter رپورٹ کو standard input کے ذریعے آپ کے program تک پہنچاتا ہے:

[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 کی default value no ہے۔ اس کا مطلب ہے کہ failed run کے بارے میں بالکل کوئی رپورٹ نہیں دی جاتی۔ اسے فعال کریں۔ ایسا patching system جو صرف اپنی کامیابیوں کا اعلان کرے، کسی system سے بھی بدتر ہے، کیونکہ خاموشی صحت مند ہونے کا تاثر دیتی ہے۔

dnf-automatic اپنی services کو restart نہیں کرتا

Package install کرنے سے disk پر موجود files replace ہو جاتی ہیں۔ جو process پہلے سے چل رہا ہو، وہ پرانا code memory میں برقرار رکھتا ہے؛ اس لیے patched library ایسے daemon پر اثر نہیں ڈالتی جو گزشتہ ماہ start ہوا تھا۔ Installed اور مؤثر code کے درمیان یہی فرق ہے کہ unattended patching کے لیے صرف install policy نہیں بلکہ restart policy بھی ضروری ہے۔

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

-s ان systemd services کی فہرست دکھاتا ہے جن کی files ان کے start ہونے کے بعد تبدیل ہوئی ہیں۔ -r ایک سوال کا جواب دیتا ہے اور دو blocks میں سے ایک block print کرتا ہے:

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 گہرا تجزیہ نہیں کرتا۔ یہ packages کی ایک مقررہ فہرست check کرتا ہے: kernel، kernel-core، kernel-rt، glibc، linux-firmware، systemd، dbus، dbus-broker، dbus-daemon اور microcode_ctl۔ اگر ان میں سے کوئی package آخری boot کے بعد install ہوا ہو تو آپ کو پہلا جواب ملتا ہے۔ جب box پر کسی دوسری چیز کو مؤثر ہونے کے لیے reboot درکار ہو، تو اپنی package names /etc/dnf/plugins/needs-restarting.d/ کے تحت .conf پر ختم ہونے والی file میں شامل کریں۔

Scripts کے لیے ایک اہم بات ہے: dnf needs-restarting -r اس وقت بھی non-zero exit کرتا ہے جب reboot درکار ہو، اور اس وقت بھی جب command خود failed ہو۔ اس لیے صرف exit status سے ان دونوں صورتوں میں فرق معلوم نہیں کیا جا سکتا۔ Output text پڑھیں۔

Service کو restart کرنا کم مداخلت والا قدم ہے اور عموماً یہی درست طریقہ ہوتا ہے۔ SSH daemon کو دوسری ایسی SSH session سے restart کریں جو پہلے سے کھلی ہو، تاکہ خراب configuration آپ کو server سے lock out نہ کر دے۔ نیا kernel وہ صورت ہے جس میں صرف reboot مدد کرتا ہے، کیونکہ running kernel کو اسی جگہ replace نہیں کیا جا سکتا۔

کیا سرور کو خود reboot ہونا چاہیے؟

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

reboot = never default ہے۔ when-changed ہر applied update کے بعد reboot کرتا ہے۔ when-needed صرف اس وقت reboot کرتا ہے جب needs-restarting -r کے پیچھے موجود check بتائے کہ کوئی core package replace ہوا ہے۔ زیادہ تر single-server owners کے لیے یہی مناسب ہے، بشرطیکہ اسے ان کے منتخب کردہ timer window کے ساتھ استعمال کیا جائے۔ default reboot_command، shutdown کے ذریعے logged-in users کو پانچ منٹ پہلے warning دیتا ہے۔ آپ یہ مدت بڑھا سکتے ہیں۔

اسے فعال کرنے سے پہلے دو امور طے کریں۔ آپ جن services پر انحصار کرتے ہیں، وہ سب boot کے وقت خود start ہونی چاہییں۔ عموماً یہی مسئلہ دستی طور پر شروع کیا گیا Docker Compose stack پیدا کرتا ہے۔ آپ کے provider کی طرف سے console یا rescue access بھی دستیاب ہونی چاہیے، کیونکہ جو kernel boot نہ ہو سکے اسے SSH کے ذریعے ٹھیک نہیں کیا جا سکتا۔ اگر ان میں سے کوئی چیز موجود نہ ہو تو reboot = never برقرار رکھیں اور journal پڑھنے کے بعد خود reboot کریں۔

Rocky، AlmaLinux اور CentOS Stream: ان میں فرق کہاں ہے

Rocky 9 اور AlmaLinux 9 میں اوپر بیان کردہ تمام چیزیں یکساں ہیں، حتیٰ کہ configuration path اور unit names بھی۔ دونوں errata شائع کرتے ہیں، اس لیے upgrade_type = security میں filter کرنے کے لیے data موجود ہے۔

CentOS Stream اس سے مستثنیٰ ہے، اور یہ اہم فرق ہے۔ Stream repositories میں کوئی updateinfo.xml موجود نہیں ہوتا، اس لیے security filter کبھی match نہیں کر سکتا اور ہر run No security updates needed رپورٹ کرتا ہے۔ Stream پر upgrade_type = default استعمال کریں اور یہ قبول کریں کہ آپ ہر update حاصل کر رہے ہیں۔ Stream، RHEL سے بھی آگے چلتا ہے، اس لیے Stream box پر یہ setting، Rocky یا AlmaLinux کی اسی setting کے مقابلے میں زیادہ تبدیلیاں لاتی ہے۔

Rocky 10 اور AlmaLinux 10 نے DNF5 اختیار کیا ہے، جس سے نام تبدیل ہو گئے ہیں۔ upstream DNF5 documentation timer کو dnf5-automatic.timer بتاتی ہے، فراہم کردہ defaults کو /usr/share/dnf5/dnf5-plugins/automatic.conf میں رکھتی ہے جبکہ آپ کی overrides اب بھی /etc/dnf/automatic.conf میں رہتی ہیں، download_updates کو no کے بجائے yes پر default کرتی ہے، اور distro-sync کو upgrade_type کے طور پر شامل کرتی ہے۔ advisory query dnf advisory list ہے، جبکہ updateinfo کو alias کے طور پر برقرار رکھا گیا ہے۔ 9 کے لیے لکھی گئی guide سے package یا unit names نقل کرنے سے پہلے تصدیق کریں کہ آپ کی release نے حقیقت میں کیا install کیا ہے:

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

اس موضوع پر شائع شدہ بہت سی guides اب بھی صرف Rocky 8 کا احاطہ کرتی ہیں۔ ان guides کے لکھے جانے کے بعد options کے مجموعے میں اضافہ ہوا ہے، اس لیے پرانے article پر بھروسا کرنے کے بجائے اپنے box پر موجود commented file دیکھیں۔

خرابی کی صورتیں اور وہ strings جو آپ دیکھیں گے

کچھ بھی کبھی نہیں چلتا۔ systemctl list-timers dnf-automatic.timer ایک خالی table دکھاتا ہے اور systemctl is-enabled dnf-automatic.timer، disabled دکھاتا ہے۔ Package install ہو گیا، لیکن timer کبھی بنا ہی نہیں۔

Job چلتی ہے لیکن کچھ install نہیں کرتی۔ Journal میں No security updates needed, but 3 updates available موجود ہے۔ Security filter کو کچھ نہیں ملا۔ اس کی وجہ یہ ہو سکتی ہے کہ pending updates میں کوئی advisory شامل نہیں، یا repository کوئی advisory data شائع نہیں کرتی۔

کوئی setting نظرانداز ہوتی محسوس ہوتی ہے۔ DNF debug level پر automatic.conf میں نامعلوم option کا اندراج کرتا ہے، پھر default استعمال کرتا ہے۔ اس لیے غلط لکھا ہوا key کوئی تبدیلی نہیں کرتا اور کوئی warning بھی نہیں آتی۔ apply_update = yes لکھیں اور apply_updates کو no پر برقرار رکھیں، ورنہ box ہمیشہ download کرتا رہے گا اور install کبھی نہیں کرے گا۔ ہر edit کے بعد sudo systemctl start dnf-automatic.service چلائیں اور file پر بھروسا کرنے کے بجائے journal پڑھیں۔

Job دن میں دو مرتبہ چلتی ہے۔ دو timers enabled ہیں۔ systemctl list-unit-files 'dnf-automatic*' بتاتا ہے کہ کون سے timers enabled ہیں، اور اضافی timers ایسے flags pass کرتے ہیں جو آپ کی config file پر فوقیت رکھتے ہیں۔

کوئی mail موصول نہیں ہوتی۔ یا تو email emitter کے لیے port 25 پر کچھ listening نہیں کر رہا، یا send_error_messages اب بھی no ہے اور رپورٹ کرنے کے قابل واحد چیز ایک error تھی۔

Patched service اب بھی پرانا version دکھاتی ہے۔ Disk پر موجود file نئی ہے، لیکن memory میں موجود process پرانا ہے۔ dnf needs-restarting -s ان services کے نام دکھاتا ہے جنہیں restart کرنا چاہیے۔

FAQ

کیا dnf-automatic Rocky Linux پر صرف security updates انسٹال کرتا ہے؟

صرف اس صورت میں جب آپ upgrade_type = security کو /etc/dnf/automatic.conf میں set کریں، اور آپ کی repositories errata metadata شائع کرتی ہوں۔ Rocky Linux اور AlmaLinux دونوں اسے شائع کرتے ہیں، اس لیے filter کے پاس advisories موجود ہوتے ہیں جن سے matching کی جا سکتی ہے۔ فراہم کردہ default upgrade_type = default ہے، جو apply_updates = yes کے بعد دستیاب ہر update انسٹال کرتا ہے۔

dnf-automatic یہ رپورٹ کیوں کرتا ہے: "No security updates needed, but 3 updates available"؟

DNF یہ طے کرنے کے لیے کہ کون سا update security update ہے، repository سے updateinfo.xml پڑھتا ہے۔ ہر advisory میں وہ packages درج ہوتے ہیں جو اس مسئلے کو حل کرتے ہیں۔ جب یہ metadata غائب یا پرانا ہو، تو security filter کسی چیز سے match نہیں کرتا، جبکہ عام updates زیر التوا رہتے ہیں۔ اسی وجہ سے یہ سطر ظاہر ہوتی ہے۔ CentOS Stream پر یہ متوقع ہے، کیونکہ وہ کوئی errata شائع نہیں کرتا۔ Rocky یا AlmaLinux پر dnf updateinfo list --security کا dnf check-update سے موازنہ کریں اور تصدیق کریں کہ آپ کا metadata تازہ ہے۔

کیا kernel update کے بعد dnf-automatic میرا server reboot کرے گا؟

نہیں، جب تک آپ اسے ایسا کرنے کے لیے configure نہ کریں۔ reboot option کا default never ہے۔ reboot = when-needed set کرنے پر run صرف اسی وقت reboot کرتا ہے جب dnf needs-restarting -r کے پیچھے ہونے والی جانچ سے معلوم ہو کہ kernel یا glibc جیسے کسی بنیادی package کو boot کے بعد replace کیا گیا ہے۔ reboot = when-changed ہر applied update کے بعد reboot کرتا ہے۔ دونوں reboot_command استعمال کرتے ہیں، جس کا default shutdown -r +5 ہے اور یہ logged-in users کو warning message دکھاتا ہے۔

dnf-automatic کے run ہونے کا وقت کیسے تبدیل کروں؟

sudo systemctl edit dnf-automatic.timer چلائیں اور [Timer] section شامل کریں۔ اس میں پہلے خالی OnCalendar= line اور اس کے بعد اپنا schedule درج کریں، مثلاً OnCalendar=*-*-* 03:30۔ خالی line ضروری ہے کیونکہ OnCalendar values جمع کرتا ہے۔ اسے چھوڑنے سے فراہم کردہ 06:00 run برقرار رہتا ہے اور دوسرا run بھی شامل ہو جاتا ہے۔ systemctl list-timers dnf-automatic.timer سے تصدیق کریں اور NEXT column پڑھیں۔

کیا خود patch ہونے والے server کی جانچ پھر بھی ضروری ہے؟

ہاں۔ dnf-automatic packages انسٹال کر کے رک جاتا ہے۔ یہ daemons restart نہیں کرتا، اور کوئی ایسی اطلاع بھی نہیں بھیجتا جسے آپ دیکھ سکیں، جب تک emit_via میں ایسا emitter درج نہ ہو جسے آپ واقعی پڑھتے ہوں۔ کم از کم emit_via کو stdio پر set کریں، send_error_messages فعال کریں تاکہ failures کی بھی اطلاع ملے، اور patch window کے بعد dnf needs-restarting -s چلائیں تاکہ وہ services معلوم کی جا سکیں جو اب بھی پرانا code چلا رہی ہیں۔