Linux Sistem Yönetiminde Neden Systemd ve systemctl Hayati Öneme Sahip?

Linux sunucularınızda servisleri yönetmek, sistem kararlılığı ve performansı için kritik bir beceridir. Peki, bu karmaşık görünen dünyada Systemd ve onun ana aracı systemctl ile servisleri nasıl etkin bir şekilde kontrol edebilirsiniz? Bu rehber, başlangıç seviyesinden ileri düzeye kadar systemctl komutlarını kullanarak Linux sistemlerinizde servisleri başlatma, durdurma, durumunu sorgulama ve otomatikleştirme süreçlerini adım adım açıklayacak, böylece sistem yönetimi becerilerinizi bir üst seviyeye taşıyacaksınız.

Linux Sistem Yönetiminde Neden Systemd ve systemctl Hayati Öneme Sahip?

Linux işletim sistemlerinde servislerin ve süreçlerin yönetimi, sistemin omurgasını oluşturan temel bir görevdir. Geleneksel olarak, SysVinit ve Upstart gibi init sistemleri bu görevi üstlenirken, modern Linux dağıtımlarının çoğu artık Systemd’yi benimsemiş durumda. Systemd, sadece bir init sistemi olmanın ötesinde, sistemin başlangıcından kapanışına kadar tüm süreçleri, servisleri, cihazları ve bağlama noktalarını yöneten kapsamlı bir yazılım süitidir. Bu geçiş, sistem yöneticilerine çok daha esnek, hızlı ve güçlü bir kontrol mekanizması sunmuştur.

Systemd’nin en büyük avantajlarından biri, servisleri paralel olarak başlatabilme yeteneğidir. Bu, önyükleme sürelerini önemli ölçüde kısaltır ve sistemin daha hızlı kullanıma hazır hale gelmesini sağlar. Ayrıca, servisler arasındaki bağımlılıkları daha iyi yönetir, hatalı servislerin sistemin geri kalanını etkilemesini önler ve gelişmiş günlükleme (logging) özellikleri sunar. Tüm bu özellikler, Systemd’yi günümüzün karmaşık sunucu ortamları için vazgeçilmez kılmaktadır. Özellikle büyük ölçekli altyapılarda veya mikroservis mimarilerinde, servislerin doğru ve güvenilir bir şekilde yönetilmesi, sistemin genel sağlığı için hayati öneme sahiptir.

systemctl ise, Systemd ile etkileşim kurmak için kullanılan birincil komut satırı aracıdır. Bu güçlü araç sayesinde, kullanıcılar sistemdeki tüm “unit” adı verilen birimleri (servisler, zamanlayıcılar, bağlama noktaları, soketler vb.) kolayca yönetebilirler. Bir web sunucusunu başlatmak, bir veritabanı hizmetini yeniden başlatmak veya bir uygulamanın sistem başlangıcında otomatik olarak çalışmasını sağlamak gibi tüm görevler systemctl aracılığıyla gerçekleştirilir. Bu komut, sistem yöneticilerine anında geri bildirim sağlar, servislerin durumunu net bir şekilde gösterir ve sorun giderme süreçlerini basitleştirir. Dolayısıyla, Systemd’nin sağladığı tüm avantajları tam anlamıyla kullanabilmek için systemctl‘e hakim olmak, her Linux kullanıcısı ve sistem yöneticisi için temel bir gerekliliktir.

Systemd ve systemctl Temel Kavramları Nelerdir?

Systemd dünyasına adım atarken karşılaşacağınız en temel kavramlardan biri “unit” (birim) kavramıdır. Systemd, yönettiği her şeyi bir birim olarak ele alır. Bu birimler, farklı amaçlara hizmet eden çeşitli tiplerde olabilir ve her birinin kendine özgü bir yapılandırma dosyası bulunur. Bu birim dosyaları genellikle /etc/systemd/system/ veya /usr/lib/systemd/system/ dizinlerinde yer alır. İşte en yaygın birim tipleri:

• Service Units (.service): Arka planda çalışan daemon’ları veya uygulamaları yönetir. Örneğin, bir web sunucusu (nginx.service) veya bir veritabanı (postgresql.service).
• Target Units (.target): Geleneksel SysVinit’teki “runlevel” kavramına benzer. Bir grup birimi bir araya getirerek belirli bir sistem durumunu tanımlar. Örneğin, multi-user.target (komut satırı modu) veya graphical.target (grafiksel masaüstü).
• Socket Units (.socket): Bir servisin bekleyeceği ağ veya IPC soketlerini tanımlar. Bu sayede servis, sadece bir bağlantı geldiğinde başlatılabilir (socket activation).
• Timer Units (.timer): Cron işlevselliğine modern bir alternatif sunar. Belirli zamanlarda veya düzenli aralıklarla servisleri başlatmak için kullanılır.
• Mount Units (.mount): Dosya sistemlerinin bağlama noktalarını yönetir.
• Device Units (.device): Çekirdek tarafından algılanan cihazları temsil eder.

Bu birimler arasında, servis birimleri en sık karşılaşacağınız ve yöneteceğiniz tür olacaktır. Her servis birimi, genellikle [Unit], [Service] ve [Install] olmak üzere üç ana bölümden oluşur. [Unit] bölümü, servisin tanımını, bağımlılıklarını ve diğer birimlerle ilişkilerini içerir. [Service] bölümü, servisin nasıl başlatılacağını, durdurulacağını, hangi kullanıcıyla çalışacağını ve diğer çalışma zamanı parametrelerini belirtir. Son olarak, [Install] bölümü, servisin sistem başlangıcında nasıl etkinleştirileceğini (enable) ve hangi hedefe (target) bağlanacağını tanımlar.

systemctl komutunun gücü, bu birim dosyalarını okuyarak ve yorumlayarak sistemi yönetmesinden gelir. Temel systemctl komutları, servisleri doğrudan kontrol etmenizi sağlar: start bir servisi başlatır, stop durdurur, restart yeniden başlatır ve status o anki durumunu gösterir. Ayrıca, enable komutu, servisin sistem başlangıcında otomatik olarak çalışmasını sağlarken, disable komutu bu özelliği kaldırır. Bu komutlar, sistem yöneticilerine servislerin yaşam döngüsü üzerinde tam kontrol imkanı sunar ve Linux sunucularında güvenilir bir çalışma ortamı sağlamak için kritik öneme sahiptir.

Systemd’nin sağladığı bu modüler yapı ve systemctl‘in sunduğu basit arayüz sayesinde, servis yönetimi çok daha şeffaf ve yönetilebilir hale gelmiştir. Her birimin ayrı bir yapılandırma dosyasına sahip olması, sorun gidermeyi kolaylaştırır ve sistemdeki değişiklikleri takip etmeyi basitleştirir. Bu temel kavramları anlamak, systemctl ile etkili bir şekilde çalışmanın ilk adımıdır.

systemctl ile Servisler Nasıl Yönetilir? Adım Adım Uygulamalı Rehber

systemctl, Linux sistemlerinizdeki servisleri yönetmek için en çok kullanacağınız araçtır. İşte temel servis yönetimi görevlerini adım adım nasıl gerçekleştireceğinize dair pratik bir rehber.

Servis Başlatma, Durdurma ve Yeniden Başlatma

Bir servisi başlatmak için start komutunu kullanırız. Örneğin, Apache web sunucusunu (httpd.service veya apache2.service) başlatmak için:

sudo systemctl start apache2.service

Bir servisi durdurmak için stop komutu kullanılır:

sudo systemctl stop apache2.service

Bir serviste yaptığınız yapılandırma değişikliklerinin etkili olması veya servis düzgün çalışmıyorsa yeniden başlatmak için restart komutunu kullanabilirsiniz:

sudo systemctl restart apache2.service

Eğer bir servis zaten çalışıyorsa ve sadece yapılandırma dosyalarını yeniden yüklemesini istiyorsanız (servisi tamamen kapatıp açmadan), reload komutunu kullanabilirsiniz. Bu, genellikle kesintisiz hizmet sağlamak için tercih edilir:

sudo systemctl reload apache2.service

Ancak, her servis reload komutunu desteklemez. Eğer desteklemiyorsa, restart kullanmak zorunda kalırsınız. Bu durumu bilmek önemlidir.

Servis Durumunu Kontrol Etme ve Listeleme

Bir servisin o anki durumunu görmek, sorun giderme ve servis sağlığını izleme açısından hayati öneme sahiptir. status komutu, servisin çalışıp çalışmadığını, son hata mesajlarını ve ilgili günlük kayıtlarını gösterir:

systemctl status apache2.service

Bu komutun çıktısı, servisin aktif olup olmadığını (active/inactive), bellekte ne kadar yer kapladığını ve son birkaç günlük kaydını içerir. Tüm aktif servisleri listelemek için:

systemctl list-units --type=service --state=running

Tüm birimleri (servisler, zamanlayıcılar vb.) listelemek için ise:

systemctl list-units

veya sadece etkin olanları görmek için:

systemctl list-units --all

Servisleri Sistem Başlangıcında Etkinleştirme/Devre Dışı Bırakma

Bir servisin sistem her başlatıldığında otomatik olarak çalışmasını sağlamak için enable komutunu kullanırız. Bu komut, servisin bir sembolik bağlantısını uygun hedef (target) birimine oluşturur:

sudo systemctl enable apache2.service

Eğer bir servisin sistem başlangıcında otomatik olarak çalışmasını istemiyorsanız, disable komutunu kullanın:

sudo systemctl disable apache2.service

Bir servisin etkinleştirilip etkinleştirilmediğini kontrol etmek için is-enabled komutunu kullanabilirsiniz:

systemctl is-enabled apache2.service

Kendi Servis Dosyanızı Oluşturma: Vaka Analizi

Diyelim ki, her 5 dakikada bir sistemin yük ortalamasını bir dosyaya yazan basit bir Python betiğiniz var ve bunu bir Systemd servisi olarak çalıştırmak istiyorsunuz. İşte adım adım nasıl yapacağınız:

1. Betiği Oluşturun: /usr/local/bin/monitor_load.py adında bir dosya oluşturun ve içine şunları yazın:

#!/usr/bin/env python3
import time
import os

log_file = "/var/log/system_load.log"

def get_load_avg():
    with open("/proc/loadavg") as f:
        return f.read().split()[0]

def log_load():
    timestamp = time.strftime("%Y-%m-%d %H:%M:%S")
    load_avg = get_load_avg()
    with open(log_file, "a") as f:
        f.write(f"{timestamp} - Load Average: {load_avg}\n")

if __name__ == "__main__":
    log_load()
        

2. Betiği Çalıştırılabilir Yapın:

sudo chmod +x /usr/local/bin/monitor_load.py

3. Systemd Servis Dosyasını Oluşturun: /etc/systemd/system/load-monitor.service adında bir dosya oluşturun ve içine şunları yazın:

[Unit]
Description=System Load Monitor Service
After=network.target

[Service]
ExecStart=/usr/local/bin/monitor_load.py
Restart=always
User=nobody

[Install]
WantedBy=multi-user.target
        

4. Systemd Yapılandırmasını Yeniden Yükleyin: Yeni servis dosyasını Systemd’ye tanıtmak için daemon’ı yeniden yüklemeniz gerekir:

sudo systemctl daemon-reload

5. Servisi Başlatın ve Etkinleştirin:

sudo systemctl start load-monitor.service

sudo systemctl enable load-monitor.service

Artık load-monitor.service adında kendi Systemd servisiniz var. Bu servis, sistem başlatıldığında otomatik olarak başlayacak ve Python betiğini çalıştırarak sistem yükünü düzenli olarak log dosyasına kaydedecektir. Bu örnek, kendi özel uygulamalarınızı veya betiklerinizi bir Systemd servisi olarak nasıl kolayca entegre edebileceğinizi göstermektedir. daemon-reload komutunun, yeni veya değiştirilmiş birim dosyalarının Systemd tarafından tanınması için ne kadar önemli olduğunu unutmayın.

Gelişmiş systemctl Kullanımı: Zamanlayıcılar, Hedefler ve Bağımlılıklar

systemctl sadece servisleri başlatıp durdurmaktan çok daha fazlasını yapabilir. Systemd’nin sunduğu zamanlayıcılar (timers), hedef birimler (targets) ve servis bağımlılıkları gibi gelişmiş özellikler, sistem yöneticilerine daha sofistike otomasyon ve kontrol imkanları sunar. Bu bölümde, bu ileri düzey konuları ve gerçek dünya senaryolarındaki kullanımlarını inceleyeceğiz.

Timer Unit’leri ile Cron Alternatifleri Nasıl Oluşturulur?

Geleneksel Linux sistemlerinde düzenli görevler için cron kullanılırken, Systemd, .timer birimleri ile daha entegre ve güçlü bir alternatif sunar. .timer birimleri, .service birimlerini belirli zamanlarda veya aralıklarla tetiklemek için kullanılır. En büyük avantajlarından biri, tetiklenecek servisin sadece zamanı geldiğinde çalışması ve günlük kayıtlarının journalctl ile daha kolay izlenebilmesidir.

Örnek olarak, yukarıda oluşturduğumuz load-monitor.service‘i her 5 dakikada bir çalıştırmak için bir timer birimi oluşturalım. Bunun için /etc/systemd/system/load-monitor.timer adında bir dosya oluşturun:

[Unit]
Description=Run System Load Monitor every 5 minutes

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min
Unit=load-monitor.service

[Install]
WantedBy=timers.target
        

Burada:

• OnBootSec=1min: Sistem başladıktan 1 dakika sonra servisi bir kez çalıştır.
• OnUnitActiveSec=5min: Servis her çalıştığında, bir sonraki çalıştırmayı 5 dakika sonrasına ayarla.
• Unit=load-monitor.service: Bu zamanlayıcının tetikleyeceği servis birimi.
• WantedBy=timers.target: Zamanlayıcının sistem başlangıcında etkinleştirilmesini sağlar.

Şimdi timer’ı etkinleştirip başlatın:

sudo systemctl daemon-reload

sudo systemctl enable load-monitor.timer

sudo systemctl start load-monitor.timer

Artık Python betiğiniz, load-monitor.timer tarafından her 5 dakikada bir otomatik olarak çalıştırılacaktır. systemctl list-timers komutu ile aktif zamanlayıcıları ve bir sonraki çalışma zamanlarını görebilirsiniz.

Target Unit’leri ile Sistem Durumlarını Yönetme ve Bağımlılıklar

Target birimleri, Systemd’nin “runlevel” benzeri işlevselliğini sağlar. Bir hedef, bir grup servisi ve diğer birimleri bir araya getirerek belirli bir sistem durumunu tanımlar. Örneğin, multi-user.target, ağ ve komut satırı erişimi olan bir sistem durumunu temsil ederken, graphical.target ek olarak grafiksel kullanıcı arayüzünü de içerir. Sisteminizin varsayılan hedefi genellikle /etc/systemd/system/default.target sembolik bağlantısı ile belirlenir.

Servis bağımlılıkları, Systemd’nin en güçlü özelliklerinden biridir. Bir servisin başka bir servis başlamadan önce başlaması gerektiğini veya onunla birlikte durması gerektiğini belirtebilirsiniz. Bu, karmaşık uygulama yığınlarını yönetirken sistem kararlılığı için çok önemlidir.

• Requires=: Bu bağımlılık, belirtilen birim başlamazsa veya durursa, mevcut birimin de başlamamasını veya durmasını sağlar. Güçlü bir bağımlılıktır.
• Wants=: Daha zayıf bir bağımlılıktır. Belirtilen birimin başlatılması istenir, ancak başarısız olursa mevcut birimin çalışmaya devam etmesine engel olmaz.
• After=: Belirtilen birimden sonra başla. Başarısızlık durumunda mevcut birimin çalışmasını engellemez.
• Before=: Belirtilen birimden önce başla.

Vaka Analizi: Web Sunucusu ve Veritabanı Bağımlılıkları

Bir web uygulaması genellikle bir web sunucusu (örneğin, Nginx) ve bir veritabanı (örneğin, PostgreSQL) gerektirir. Nginx’in başlamadan önce PostgreSQL’in tamamen çalışır durumda olması önemlidir. Bu bağımlılığı Nginx servis dosyasına (/etc/systemd/system/nginx.service.d/override.conf gibi bir dosyada veya ana servis dosyasında) ekleyebiliriz:

# /etc/systemd/system/nginx.service.d/override.conf
[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target postgresql.service
Requires=postgresql.service
        

Bu yapılandırma, Nginx’in (nginx.service) başlamadan önce postgresql.service‘in ve network.target‘ın aktif olmasını sağlar. Ayrıca, Requires=postgresql.service ile PostgreSQL servisi çalışmazsa Nginx’in de başlamayacağını garanti eder. Bu tür bağımlılık yönetimi, karmaşık sistemlerde servis başlatma sırasını ve çalışma zamanı ilişkilerini doğru bir şekilde kurmak için hayati öneme sahiptir.

Maskeleme (Masking) ile Servisleri Devre Dışı Bırakmanın Güçlü Yolu

Bazen bir servisin asla başlamamasını veya etkinleştirilmemesini istersiniz. systemctl mask komutu, bir servisi kalıcı olarak devre dışı bırakmanın en güçlü yoludur. Bu, servis dosyasına /dev/null‘a işaret eden bir sembolik bağlantı oluşturur, böylece Systemd onu bulamaz ve çalıştırmayı reddeder:

sudo systemctl mask apache2.service

Maskelenmiş bir servisi tekrar etkinleştirmek için unmask komutunu kullanmanız gerekir:

sudo systemctl unmask apache2.service

Maskeleme, özellikle kritik sistem servislerinin yanlışlıkla başlatılmasını veya üçüncü taraf yazılımların istenmeyen servisleri etkinleştirmesini engellemek için kullanışlıdır.

Bu gelişmiş systemctl özellikleri, Linux sistemleriniz üzerinde tam kontrol sağlamanıza ve karmaşık senaryolarda bile servislerinizi güvenilir bir şekilde yönetmenize olanak tanır. Doğru bir şekilde kullanıldığında, bu araçlar sistem kararlılığını artırır ve yönetim yükünü azaltır.

Sistem Günlüklerini systemctl ve journalctl ile Nasıl İzlersiniz?

Sistem ve uygulama sorunlarını gidermenin, performans darboğazlarını tespit etmenin ve güvenlik olaylarını izlemenin en kritik yollarından biri, sistem günlüklerini (logs) doğru bir şekilde incelemektir. Systemd, günlük yönetimini journalctl aracıyla merkezi ve yapılandırılmış bir şekilde ele alır. Bu, geleneksel /var/log/ dizinindeki dağınık log dosyalarına kıyasla çok daha güçlü ve esnek bir günlükleme deneyimi sunar.

journalctl Komutunun Gücü

journalctl, Systemd’nin merkezi günlükleme sistemi olan Journal’dan günlükleri okumak için kullanılır. Journal, ikili formatta günlükleri saklar, bu da daha hızlı sorgulama ve daha iyi yapılandırılmış veriler sağlar. Temel olarak, tüm sistem günlüklerini görmek için tek yapmanız gereken:

journalctl

Bu komut, tüm mevcut günlükleri en yeniden en eskiye doğru sayfalayarak (less komutu gibi) gösterir. Ancak, genellikle belirli günlükleri aramak istersiniz.

Servise Özel Logları Filtreleme

Belirli bir servisin günlüklerini görmek, o servisle ilgili sorunları teşhis etmek için çok önemlidir. Örneğin, apache2.service‘in günlüklerini görmek için:

journalctl -u apache2.service

Eğer sadece son birkaç satırı görmek istiyorsanız, -n parametresini kullanabilirsiniz:

journalctl -u apache2.service -n 50

Zamana Göre Filtreleme

Günlükleri belirli bir zaman aralığına göre filtrelemek, belirli bir olay veya hata zamanında ne olduğunu anlamak için çok kullanışlıdır. --since ve --until parametrelerini kullanabilirsiniz:

journalctl --since "2023-10-26 10:00:00" --until "2023-10-26 11:00:00"

Veya daha doğal ifadeler kullanabilirsiniz:

journalctl --since "yesterday"

journalctl --since "1 hour ago"

Gerçek Zamanlı İzleme (-f)

Tıpkı tail -f gibi, journalctl -f komutu da günlükleri gerçek zamanlı olarak izlemenizi sağlar. Bu, bir servisi başlatırken veya bir yapılandırma değişikliği yaparken anlık geri bildirim almak için paha biçilmezdir:

journalctl -f

Belirli bir servisin gerçek zamanlı günlüklerini izlemek için:

journalctl -u apache2.service -f

Log Boyutu Yönetimi

Journal, varsayılan olarak günlükleri belirli bir boyuta kadar tutar ve eski günlükleri otomatik olarak siler. Ancak bu davranışı yapılandırabilirsiniz. Örneğin, günlükleri sadece son 7 gün için saklamak için:

sudo journalctl --vacuum-time=7d

Veya günlüklerin toplam boyutunu sınırlamak için:

sudo journalctl --vacuum-size=1G

Bu komutlar, günlüklerin diskinizi doldurmasını engellerken, sorun giderme için yeterli geçmiş veriyi tutmanıza yardımcı olur.

Mobil Uyumlu İzleme Paneli Fikri

Günlükleri ve sistem durumunu komut satırından izlemek harika olsa da, bazı durumlarda web tabanlı, mobil uyumlu bir panel tercih edilebilir. Böyle bir panel, journalctl çıktısını parse ederek veya Systemd API’leri ile etkileşime girerek verileri görselleştirebilir. Örneğin, bir Systemd servisi için basit bir durum göstergesi sunan bir web arayüzü, farklı ekran boyutlarına uyum sağlamak için CSS media query’lerini kullanabilir. İşte temel bir CSS media query örneği:

<style>
  .status-card {
    width: 100%;
    padding: 15px;
    margin-bottom: 10px;
    border: 1px solid #ccc;
    box-sizing: border-box;
  }

  /* Mobil cihazlar için stil */
  @media (max-width: 768px) {
    .status-card {
      background-color: #f0f8ff; /* Açık mavi arka plan */
      font-size: 0.9em;
    }
  }

  /* Geniş ekranlar için stil */
  @media (min-width: 769px) {
    .status-card {
      background-color: #e0ffe0; /* Açık yeşil arka plan */
      font-size: 1em;
    }
  }
</style>

<div class="status-card">
  <h3>Apache2 Servis Durumu</h3>
  <p>Durum: <span style="color: green;">Aktif</span></p>
  <p>Son Yeniden Başlatma: 2 dakika önce</p>
</div>
        

Bu örnek, bir durum kartının farklı ekran boyutlarında nasıl farklı görünebileceğini göstermektedir. Mobil cihazlarda arka plan rengi ve yazı tipi boyutu değişirken, daha geniş ekranlarda farklı bir stil uygulanır. Bu tür bir yaklaşım, sistem yöneticilerinin hareket halindeyken bile önemli günlükleri ve servis durumlarını kolayca izlemesine olanak tanır, böylece Systemd ve journalctl‘in sağladığı verilere erişimi daha erişilebilir hale getirir.

Sıkça Sorulan Sorular (SSS)

1. systemctl komutunu kullanırken sudo neden gereklidir?

Çoğu systemctl komutu, sistem genelindeki servisleri yönettiği için root yetkileri gerektirir. Bir servisi başlatma, durdurma, etkinleştirme veya devre dışı bırakma gibi işlemler, sistemin kritik bileşenlerini etkilediğinden, kötüye kullanımı veya yanlış yapılandırmayı önlemek için bu yetki kontrolü uygulanır. Bu nedenle, bu tür işlemleri gerçekleştirirken sudo (superuser do) kullanmanız gerekir.

2. Bir servisin .service dosyasını nasıl bulabilirim veya düzenleyebilirim?

Servis dosyaları genellikle /etc/systemd/system/ veya /usr/lib/systemd/system/ dizinlerinde bulunur. Bir servisin tam yolunu bulmak için systemctl status .service komutunu çalıştırabilirsiniz; çıktı genellikle “Loaded” satırında dosyanın yolunu gösterir. Servis dosyasını düzenlemek için doğrudan bir metin düzenleyici kullanabilir veya sudo systemctl edit .service komutunu kullanarak Systemd’nin önerdiği şekilde geçersiz kılma (override) dosyaları oluşturabilirsiniz. Bu yöntem, orijinal dosyayı değiştirmeden değişiklik yapmanızı sağlar ve güncelleme sırasında çakışmaları önler.

3. systemctl ile bir servisi maskelemek ile devre dışı bırakmak arasındaki fark nedir?

Bir servisi disable etmek, onun sistem başlangıcında otomatik olarak çalışmasını engeller, ancak manuel olarak başlatılabilir. mask etmek ise, servisi tamamen kullanılamaz hale getirir. Servis dosyasına /dev/null‘a işaret eden bir sembolik bağlantı oluşturur ve bu, servisin manuel olarak bile başlatılmasını veya etkinleştirilmesini engeller. Maskeleme, bir servisin kesinlikle çalışmamasını istediğiniz durumlarda (örneğin, güvenlik nedenleriyle veya bir çakışmayı önlemek için) kullanılır.

4. Systemd’de “target” birimi nedir ve runlevel’dan farkı nedir?

“Target” birimi, Systemd’de belirli bir sistem durumunu veya işlevselliğini temsil eden bir grup birimdir. Geleneksel SysVinit’teki “runlevel” kavramına benzer, ancak daha esnek ve modülerdir. Runlevel’lar genellikle 0’dan 6’ya kadar numaralandırılmış katı durumlar iken, target’lar isim tabanlıdır (örn. multi-user.target, graphical.target) ve aynı anda birden fazla target aktif olabilir. Target’lar, servisler ve diğer birimler arasındaki bağımlılıkları daha iyi yöneterek sistemin daha dinamik bir şekilde başlatılmasını ve çalışmasını sağlar.

5. journalctl ile logları temizlemek veya boyutunu sınırlamak mümkün mü?

Evet, journalctl ile günlüklerin boyutunu yönetmek mümkündür. sudo journalctl --vacuum-size= (örn. --vacuum-size=1G) komutuyla günlüklerin toplam boyutunu sınırlayabilir veya sudo journalctl --vacuum-time= (örn. --vacuum-time=30d) komutuyla belirli bir süreden daha eski günlükleri silebilirsiniz. Bu komutlar, diskinizi doldurmasını engellerken, sorun giderme için yeterli günlük geçmişini korumanıza yardımcı olur. Bu işlemler, genellikle sistem yöneticileri tarafından düzenli bakım görevleri olarak yapılır.