Rocky ve AlmaLinux dnf-automatic kurulumu ve ayarları

Rocky Linux ve AlmaLinux üzerinde dnf-automatic işlevi

dnf-automatic, Rocky Linux ve AlmaLinux üzerinde katılımsız güvenlik güncellemelerini almanızı sağlayan araçtır. systemd zamanlayıcısı tarafından başlatılan bu küçük program, /etc/dnf/automatic.conf dosyasını okur ve bu dosyanın izin verdiği işlemleri uygular. Kurulum tek bir komutla gerçekleştirilir. Bu kılavuzun geri kalanı, sunucunuzu koruyup korumayacağına veya sessizce hiçbir şey yapmayacağına karar veren ayarlar hakkındadır.

Debian veya Ubuntu sistemlerinden geliyorsanız, bu araç Ubuntu VPS üzerinde unattended-upgrades ile aynı işi yapar. Tüm farkların ötesinde tek bir ayrım önemlidir: paket yöneticisi için "güvenlik" teriminin ne anlama geldiği. Ubuntu'da bu ayrı bir arşiv havuzudur. RHEL ailesinde ise yayınlanan bildirimlere eklenmiş meta verilerdir ve bu meta veriler eksik veya güncel olmayabilir. dnf-automatic aracını bildirim verisi içermeyen bir depoya yönlendirirseniz, hiçbir şey yüklemez ancak başarılı olduğu raporunu verir.

Bu kılavuz, Ağustos 2026 itibarıyla DNF 4 (RHEL ailesindeki paket yöneticisi) kullanan Rocky Linux 9 ve AlmaLinux 9 sürümleri temel alınarak hazırlanmıştır. 10 sürümleri DNF5'e geçiş yapmıştır ve isimler değiştiği için bu sürümlerle ilgili özel bir bölüm sona eklenmiştir. Aşağıdaki her komut, kendi sunucunuzda çalıştırmanız içindir ve yanında görmeniz gereken çıktı yer almaktadır.

dnf-automatic paketini kurun ve gelen yapılandırma dosyasını inceleyin

Otomatik güncellemeleri etkinleştirmek, yeni bir VPS üzerindeki ilk on dakika rehberinde belirtilen kurulum adımlarının bir parçasıdır; bu işlem, root olmayan bir kullanıcı oluşturup güvenlik duvarını yapılandırdıktan hemen sonra yapılmalıdır.

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

systemctl is-enabled, yeni bir kurulumda disabled çıktısını verir; çünkü paketin kurulması herhangi bir servisi başlatmaz. "dnf-automatic" yüklü olduğu halde tek bir güncelleme bile almamış sunucuların en yaygın sebebi budur.

DNF sürümü, bir seçenek için önem taşır. reboot ayarı, DNF 4.15 sürümüyle upstream olarak gelmiş olup, Red Hat tarafından Kasım 2023'te RHBA-2023:6645 duyurusu ile dnf-4.14.0-6.el9 paketine backport edilmiştir. Rocky 9 ve AlmaLinux 9 bu paketi yeniden derlediği için, güncel bir sunucuda bu özellik mevcuttur; ancak 2023'ten beri güncellenmemiş bir sunucuda bulunmayabilir.

Yapılandırma dosyası /etc/dnf/automatic.conf konumundadır. Paketin içinden çıkan dosya, bu sürümün desteklediği tüm seçenekleri ve varsayılan değerlerini yorum satırı olarak listeler. Düzenleme yapmadan önce bu dosyayı mutlaka okuyun; çünkü kullandığınız sürüm için geçerli olan gerçek yapılandırma bu dosyadır.

Ne olacağına karar veren iki anahtar

download_updates ve apply_updates, [commands] bölümündeki davranışa karar verir. Her ikisi de EL9 (Rocky 9 ve AlmaLinux 9'un ortak temeli olan enterprise Linux 9) üzerinde varsayılan olarak no durumundadır; bu nedenle, düzenlenmemiş ve etkinleştirilmiş bir dnf-automatic yalnızca nelerin mevcut olduğunu size bildirir.

• Her ikisi de no: dnf-automatic mevcut güncellemeleri raporlar ve sunucu üzerinde hiçbir şeyi değiştirmez.
• download_updates = yes ve apply_updates = no: paketler DNF önbelleğine indirilir. Kurulum hızlı gerçekleşir ve ağ bağlantısı gerektirmez, ancak o gece hiçbir şey değiştirilmez.
• Her ikisi de yes ve upgrade_type = default: güvenlik güncellemesi olup olmadığına bakılmaksızın tüm mevcut güncellemeler kurulur.
• Her ikisi de yes ve upgrade_type = security: yalnızca güvenlik bültenlerinde adı geçen paketler kurulur.

İnternete açık bir VPS için makul bir başlangıç noktası:

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

network_online_timeout, çalışmanın pes etmeden önce çalışan bir ağ için bekleyeceği saniye sayısıdır; bu, yeni açılmış bir sunucuda önemlidir. random_sleep, yükü birçok makineye yaymak için kullanılan eski bir yöntemdir; günümüzde bu işi zamanlayıcı (timer) yapmaktadır. Yazılımla birlikte gelen servisin tam olarak hangi bayrakları kullandığını görmek için systemctl cat dnf-automatic.service komutunu çalıştırın.

Dosyanın 06:00'yı beklemeden, düşündüğünüz işlemi yaptığını doğrulayın:

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

Journal, çalışmanın neleri değerlendirdiğini ve neler yaptığını gösterir. Ayrıca, komut satırından belirli bir davranışı zorlayabilirsiniz; bu, yalnızca o çalışma için dosyadaki ayarları geçersiz kılar:

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

Rocky ve Alma üzerinde upgrade_type = security ifadesinin gerçek anlamı

DNF, bir güncellemenin güvenlik güncellemesi olup olmadığını sürüm numaralarını karşılaştırarak belirlemez. Bunun yerine errata meta verilerini okur: depo içerisinde yayınlanan updateinfo.xml adlı bir dosya. Bu dosyada her bir bildirim, ilgili açığı kapatan paketleri listeler. AlmaLinux bunları ALSA bildirimleri, Rocky ise RLSA olarak yayınlar. upgrade_type = security bu meta verilerden bir filtre oluşturur ve yalnızca eşleşen paketleri yükseltir.

Bunun iki sonucu vardır ve her ikisi de kullanıcıları şaşırtır.

Birincisi, meta veri yoksa güncelleme de yoktur. Eğer depo herhangi bir updateinfo.xml içermiyorsa, filtre hiçbir şeyle eşleşmez ve işlem günlük kaydında şu satırla sona erer:

No security updates needed, but 3 updates available

Sunucu yamalanmamıştır ve hiçbir hata rapor edilmemiştir. Bunu kendiniz kontrol edin:

dnf updateinfo list --security
dnf check-update

Eğer dnf check-update paketleri listeliyor ancak dnf updateinfo list --security hiçbir çıktı vermiyorsa, ya bekleyen güncellemelerin hiçbirinde bildirim yoktur ya da depo okunacak bir bildirim verisine sahip değildir. Rocky ve AlmaLinux her ikisi de bu veriyi yayınladığından, bu iki dağıtımda boş bir liste genellikle durumun gerçek halidir. CentOS Stream ise bu veriyi hiç yayınlamaz.

İkincisi, güvenlik modu minimal bir değişiklik değildir. dnf-automatic güvenlik filtresini ekler ve ardından standart yükseltme yolunu izler; bu nedenle bir bildirimde adı geçen paket, depodaki en yeni sürüme yükseltilir ve bağımlılıklarını da beraberinde getirir. Yalnızca bildirimi gideren en erken sürüme geçmek gibi daha küçük bir adım, ancak dnf upgrade-minimal --security manuel olarak çalıştırıldığında mümkündür. dnf-automatic içinde bunun için bir ayar bulunmamaktadır.

Rocky için bir uyarı daha mevcuttur. Rocky, errata verilerini Red Hat verilerinden kendi hattı üzerinden oluşturur ve bu hat bazen geride kalabilir. Eylül 2025'te kullanıcılar, Rocky 9 BaseOS updateinfo.xml verisinin Aralık 2024'ten beri güncellenmediğini, bu nedenle --security içinde yakın tarihli bildirimlerin eksik olduğunu rapor etmiş ve Rocky ekibi bunu bilinen bir sorun olarak doğrulamıştır. Eğer upgrade_type = security sistemine güveniyorsanız, bildirim listesini zaman zaman güncel RLSA duyurularıyla karşılaştırın. Değişiklik kontrolünden ziyade güvenliğin ön planda olduğu bir sunucuda, upgrade_type = default ayarını kendi belirlediğiniz bir zaman çizelgesinde kullanmak daha güvenli bir yöntemdir.

Çalıştırmayı gerçekleştiren systemd zamanlayıcısı

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

list-timers komutu, yaklaşık bir gün sonrasına ait bir NEXT zamanı içeren tek bir satır döndürmelidir. Boş bir tablo, zamanlayıcının etkinleştirilmediği anlamına gelir; bu durumda hiçbir işlem çalışmayacaktır.

Paketle gelen zamanlayıcı *-*-* 6:00 saatinde, RandomizedDelaySec=60m ve Persistent=true ayarlarıyla tetiklenir. Rastgele gecikme, tüm sunucuların aynı saniyede yansıma sunucusuna (mirror) yüklenmemesi için iş yükünü bir saatlik zaman dilimine yayar. Persistent=true ayarı, 06:00'da kapalı olan bir makinenin, açıldıktan kısa bir süre sonra kaçırılan işi çalıştırmasını sağlar; böylece o gün atlanmamış olur.

Zamanlamayı bir drop-in dosyası ile değiştirin. Paket yükseltmeleri /usr/lib/systemd/system altındaki dosyaları değiştirdiği için, paketle gelen unit dosyasını doğrudan düzenlemeyin.

sudo systemctl edit dnf-automatic.timer

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

Boş OnCalendar= satırı gereklidir. OnCalendar ayarı birikimli (accumulative) çalışır; bu sıfırlama yapılmazsa 06:00 girdisi korunur ve üzerine ikincisi eklenir, böylece iş günde iki kez çalışır. Sonucu systemctl list-timers dnf-automatic.timer ile doğrulayın ve NEXT sütununu inceleyin. Aynı drop-in kuralları, systemd servis ve zamanlayıcı birimleri yazma bölümünde ele alınan diğer tüm zamanlamalar için de geçerlidir.

Şimdi tuzak noktası: Paket üç zamanlayıcı daha içerir: dnf-automatic-download.timer, dnf-automatic-notifyonly.timer ve dnf-automatic-install.timer. Her biri aynı programı komut satırı bayraklarıyla başlatır ve bu bayraklar yapılandırma dosyanızdaki download_updates ve apply_updates ayarlarını geçersiz kılar. dnf-automatic.timer yanında bunlardan birini etkinleştirirseniz, iş iki farklı davranışla iki kez çalışır; bu durum yapılandırma dosyanızın yok sayıldığı izlenimini verir. Bir zamanlayıcıyı etkinleştirin ve kontrol edin:

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

Bir şeyin ne zaman kurulduğunu nasıl anlarım?

emit_via, [emitters] bölümü içerisinde raporlamayı kontrol eder. systemd altında stdio yayıcısı, journal dosyasına yazar; bu, başka hiçbir yazılımın kurulmasını gerektirmediği için güvenilir bir seçenektir:

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

motd yayıcısı, raporu /etc/motd dosyasına yazar ve dosyanın mevcut içeriğinin üzerine yazar. Eğer orada bir giriş başlığı (login banner) tutuyorsanız, bu yayıcıyı kullanmayın.

email yayıcısı, email_host üzerinde email_port adresine bir SMTP (simple mail transfer protocol) bağlantısı açar; bunlar varsayılan olarak localhost ve 25 değerlerindedir. Yeni bir VPS üzerinde bu portu dinleyen bir servis bulunmadığından bağlantı reddedilir ve e-posta gönderilmez. Buna güvenmeden önce ss -lnt | grep ':25' komutunu çalıştırın ve çıktı boşsa yalnızca relay (aktarım) yapan bir Postfix yapılandırın. E-posta çalıştığında, konu satırı Updates applied on 'web01'. olarak görünür ve isim system_name değerinden alınır.

Diğer tüm durumlar için command yayıcısı, raporu standart girdi (standard input) üzerinden sizin bir programınıza iletir:

[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 varsayılan olarak no değerindedir; bu, başarısız bir çalışmanın hiçbir şey raporlamayacağı anlamına gelir. Bunu etkinleştirin. Sadece başarılarını duyuran bir yama sistemi, hiç olmamasından daha kötüdür; çünkü sessizlik, sistemin sağlıklı olduğu izlenimini yaratır.

dnf-automatic servislerinizi yeniden başlatmaz

Bir paketin kurulması, disk üzerindeki dosyaların üzerine yazılmasını sağlar. Hali hazırda çalışmakta olan bir süreç, eski kodu bellekte tutmaya devam eder; bu nedenle yamalanmış bir kütüphane, geçen ay başlatılmış bir daemon için hiçbir işe yaramaz. Kurulan ile etkin olan arasındaki bu fark, katılımsız yama işlemlerinin yalnızca bir kurulum politikasına değil, aynı zamanda bir yeniden başlatma politikasına da ihtiyaç duymasının nedenidir.

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

-s, dosyaları başlatıldıktan sonra değişen systemd servislerini listeler. -r tek bir soruya yanıt verir ve iki bloktan birini yazdırı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 derinlemesine bir analiz değildir. Sabit bir paket listesini kontrol eder: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon ve microcode_ctl. Bunlardan biri son önyüklemeden sonra kurulmuşsa, ilk yanıtı alırsınız. Sunucudaki başka bir şeyin de etkili olması için yeniden başlatma gerektirdiği durumlarda, kendi paket adlarınızı /etc/dnf/plugins/needs-restarting.d/ dizini altında .conf ile biten bir dosyaya ekleyin.

Betikler için bir uyarı: dnf needs-restarting -r, hem yeniden başlatma gerektiğinde hem de komutun kendisi başarısız olduğunda sıfırdan farklı bir çıkış kodu döndürür; bu nedenle sadece çıkış durumuna bakarak bu iki durumu birbirinden ayıramazsınız. Çıktı metnini okuyun.

Bir servisi yeniden başlatmak daha küçük bir işlemdir ve genellikle doğru olan budur. SSH daemon'ı, halihazırda açık olan ikinci bir SSH oturumundan yeniden başlatın; böylece hatalı bir yapılandırma sizi sistemin dışında bırakmaz. Yeni bir çekirdek (kernel), yalnızca yeniden başlatmanın çözüm olduğu durumdur çünkü çalışan çekirdek yerinde değiştirilemez.

Sunucu kendiliğinden yeniden başlatılmalı mı?

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

reboot = never varsayılan ayardır. when-changed, uygulanan her güncellemeden sonra yeniden başlatma yapar. when-needed ise yalnızca needs-restarting -r arkasındaki denetim bir çekirdek paketinin değiştirildiğini bildirdiğinde yeniden başlatma yapar; çoğu tek sunucu sahibi, kendi belirledikleri bir zamanlayıcı penceresiyle birlikte bunu tercih eder. Varsayılan reboot_command ayarı, oturum açmış kullanıcılara shutdown aracılığıyla beş dakikalık bir uyarı verir; bu süreyi uzatabilirsiniz.

Bu özelliği etkinleştirmeden önce iki konuyu netleştirin. Güvendiğiniz her servisin kendi kendine önyükleme sırasında başlaması gerekir; bu durum genellikle elle başlatılan Docker Compose yığınları için bir eksikliktir. Ayrıca sağlayıcınızdan konsol veya kurtarma erişimine sahip olmanız gerekir; çünkü önyükleme yapamayan bir çekirdek SSH üzerinden düzeltilemez. Bu iki şarttan biri eksikse, reboot = never ayarını koruyun ve günlük kayıtlarını inceledikten sonra yeniden başlatmayı kendiniz yapın.

Rocky, AlmaLinux ve CentOS Stream: farklar

Rocky 9 ve AlmaLinux 9 üzerinde yukarıdaki her şey, yapılandırma yolu ve birim adlarına kadar aynıdır. Her iki dağıtım da errata yayınladığı için upgrade_type = security üzerinde filtrelenecek veri bulunur.

CentOS Stream bir istisnadır ve bu önemli bir farktır. Stream depoları updateinfo.xml içermez, bu nedenle güvenlik filtresi hiçbir zaman eşleşme sağlamaz ve her çalıştırma No security updates needed rapor eder. Stream üzerinde upgrade_type = default kullanın ve tüm güncellemeleri alacağınızı kabul edin. Stream ayrıca RHEL'in ilerisinde olduğu için, bu ayar bir Stream sunucusunda Rocky veya AlmaLinux'taki aynı ayara göre daha fazla değişiklik gösterir.

Rocky 10 ve AlmaLinux 10, DNF5'e geçiş yapmıştır ve bu durum bazı isimleri değiştirmiştir. Upstream DNF5 belgeleri zamanlayıcıyı dnf5-automatic.timer olarak belirtir, varsayılan ayarları /usr/share/dnf5/dnf5-plugins/automatic.conf içinde tutar, geçersiz kılma ayarlarınız ise /etc/dnf/automatic.conf içinde kalmaya devam eder. download_updates varsayılan olarak hayır yerine evet değerini alır ve upgrade_type olarak distro-sync eklenir. Tavsiye sorgusu dnf advisory list şeklindedir ve updateinfo takma ad olarak korunur. 9 sürümü için yazılmış bir kılavuzdan paket veya birim adlarını kopyalamadan önce dağıtımınızın gerçekte ne yüklediğini doğrulayın:

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

Bu konuyla ilgili yayınlanmış birçok kılavuz yalnızca Rocky 8'i kapsamaktadır. Seçenek seti bu kılavuzlar yazıldığından bu yana genişlemiştir, bu nedenle eski bir makaleye güvenmek yerine kendi sunucunuzdaki açıklamalı dosyayı kontrol edin.

Hata modları ve karşılaşacağınız dizgeler

Hiçbir şey çalışmıyor. systemctl list-timers dnf-automatic.timer boş bir tablo yazdırır ve systemctl is-enabled dnf-automatic.timer, disabled çıktısını verir. Paket kurulmuştur ancak zamanlayıcı (timer) kurulmamıştır.

İş çalışıyor ancak hiçbir şey kurmuyor. Günlük kayıtlarında (journal) No security updates needed, but 3 updates available yer alır. Güvenlik filtresi hiçbir şeyle eşleşmemiştir; bunun nedeni ya bekleyen hiçbir güvenlik önerisinin (advisory) bulunmaması ya da deponun (repository) herhangi bir öneri verisi yayınlamamasıdır.

Bir ayar yok sayılmış gibi görünüyor. DNF, automatic.conf dosyasındaki bilinmeyen bir seçeneği hata ayıklama (debug) seviyesinde günlüğe kaydeder ve ardından varsayılanı kullanır; bu nedenle yanlış yazılmış bir anahtar hiçbir şeyi değiştirmez ve kimseyi uyarmaz. apply_update = yes yazarsınız ancak apply_updates değeri no olarak kalır, bu yüzden sunucu sürekli indirir ancak hiçbir zaman kurmaz. Her düzenlemeden sonra sudo systemctl start dnf-automatic.service komutunu çalıştırın ve dosyaya güvenmek yerine günlük kayıtlarını okuyun.

İş günde iki kez çalışıyor. İki zamanlayıcı etkinleştirilmiştir. systemctl list-unit-files 'dnf-automatic*' hangilerinin etkin olduğunu gösterir; fazladan olanlar, yapılandırma dosyanızdaki ayarları geçersiz kılan bayraklar (flag) gönderiyor olabilir.

E-posta ulaşmıyor. Ya email yayıcısı için 25 numaralı portta dinleme yapan bir servis yoktur ya da send_error_messages hala no değerindedir ve raporlanmaya değer tek şey bir hatadır.

Yamalanmış bir servis hala eski sürümü bildiriyor. Diskteki dosya yenidir ancak bellekteki süreç eskidir. dnf needs-restarting -s, yeniden başlatılması gereken servisleri listeler.

FAQ

dnf-automatic, Rocky Linux üzerinde yalnızca güvenlik güncellemelerini mi yükler?

Yalnızca upgrade_type = security ayarını /etc/dnf/automatic.conf içerisinde yapılandırdıysanız ve kullandığınız depolar errata meta verilerini yayınlıyorsa bu gerçekleşir. Rocky Linux ve AlmaLinux her ikisi de bu veriyi yayınladığı için filtre, eşleşecek güvenlik bültenlerine sahiptir. Yazılımla birlikte gelen varsayılan ayar upgrade_type = default şeklindedir; bu ayar apply_updates = yes gerçekleştiğinde mevcut tüm güncellemeleri yükler.

dnf-automatic neden "Güvenlik güncellemesi gerekmiyor ancak 3 güncelleme mevcut" uyarısı veriyor?

DNF, bir güncellemenin güvenlik güncellemesi sayılıp sayılmayacağına depodaki updateinfo.xml verisini okuyarak karar verir; burada her bülten, ilgili açığı kapatan paketleri listeler. Bu meta veri eksik veya güncel değilse, güvenlik filtresi hiçbir şeyle eşleşmez ancak normal güncellemeler beklemeye devam eder; bu da tam olarak söz konusu çıktıyı üretir. Hiçbir errata yayınlamayan CentOS Stream üzerinde bu durum beklenir. Rocky veya AlmaLinux üzerinde, dnf updateinfo list --security ile dnf check-update değerlerini karşılaştırın ve meta verilerinizin güncel olduğundan emin olun.

dnf-automatic, çekirdek güncellemesinden sonra sunucumu yeniden başlatır mı?

Siz istemediğiniz sürece hayır. reboot seçeneği varsayılan olarak never değerindedir. reboot = when-needed ayarını yaparsanız, sistem yalnızca dnf needs-restarting -r arkasındaki kontrol kernel veya glibc gibi temel bir paketin sistem açılışından sonra değiştirildiğini tespit ettiğinde yeniden başlatılır. reboot = when-changed ise uygulanan herhangi bir güncellemeden sonra yeniden başlatma yapar. Her ikisi de varsayılan olarak oturum açmış kullanıcılara uyarı mesajı gönderen shutdown -r +5 değerine sahip reboot_command komutunu kullanır.

dnf-automatic'in çalışma zamanını nasıl değiştirebilirim?

sudo systemctl edit dnf-automatic.timer komutunu çalıştırın ve boş bir OnCalendar= satırı ile ardından zamanlamanızı içeren bir [Timer] bölümü ekleyin; örneğin OnCalendar=*-*-* 03:30. Boş satır gereklidir çünkü OnCalendar değerleri birikir; bu satırı eklemezseniz varsayılan 06:00 zamanlaması korunur ve üzerine ikinci bir zamanlama eklenir. systemctl list-timers dnf-automatic.timer ile doğrulamayı yapın ve NEXT sütununu kontrol edin.

Kendini güncelleyen bir sunucuyu yine de kontrol etmem gerekir mi?

Evet. dnf-automatic paketleri yükler ve orada durur. Servisleri (daemon) yeniden başlatmaz ve emit_via ayarında düzenli olarak okuduğunuz bir bildirim kanalı tanımlamadığınız sürece size hiçbir rapor sunmaz. emit_via ayarını en az stdio olarak yapılandırın, hataların da raporlanması için send_error_messages özelliğini açın ve güncelleme penceresinden sonra eski kodla çalışmaya devam eden servisleri bulmak için dnf needs-restarting -s komutunu çalıştırın.