Örnek sorular
Linux Systemd Service ManagementZorluk 1
Bir servis için systemd unit dosyası tipik olarak hangi üç bölüme ayrılır ve her biri temel olarak neyi tutar?
- a[Unit], [Service], [Install] — sırasıyla genel metadata/bağımlılıklar, servise özgü çalıştırma ayarları ve kurulum (enable) bilgisi✓
- b[Meta], [Process], [Boot] — sırasıyla metadata, çalışma zamanı process ayarları ve boot sıralaması; Windows Service Manager'ın özellik kategorilerine benzetilerek bazı mühendislerin varsaydığı bir adlandırma şemasıdır
- c[Config], [Run], [Start] — sırasıyla konfigürasyon değerleri, çalıştırma komutu ve bir Makefile hedefine benzer ayrı bir start tetikleyicisi; ancak systemd unit dilbilgisinde böyle bölüm adları yoktur
- d[Header], [Body], [Footer] — HTTP'den ödünç alınmış, tamamen kozmetik bir adlandırma ve systemd'nin unit dosyası ayrıştırıcısı tarafından yükleme sırasında sessizce yok sayılır
Açıklama:Tipik bir .service unit'i [Unit] (genel metadata ve diğer unit'lerle ilişki, örn. Description=, After=), [Service] (process'in nasıl çalıştırılacağı, örn. ExecStart=, Restart=) ve [Install] (unit enable edildiğinde bir target'a nasıl bağlanacağı, örn. WantedBy=) bölümlerinden oluşur. Diğer bölüm adları systemd'de yoktur.
Linux Systemd Service ManagementZorluk 1
Bir .service unit dosyasında [Unit] bölümüne tipik olarak hangi tür direktifler girer?
- aServis process'ini başlatan tam komut satırı (ExecStart=), çünkü [Unit] bazen yanlışlıkla asıl çalıştırma direktifini tuttuğu varsayılır, oysa bu [Service]'e aittir
- bDescription=, After=, Requires= gibi, unit türünden bağımsız olarak geçerli genel metadata ve unit ilişkileri✓
- cSadece unit'i hangi target'ın enable ettiğini kontrol eden WantedBy= direktifi; [Unit]'in sıralama ipuçlarıyla [Install]'a ait enable bağlantısını birbirine karıştıran bir yanılgıdır
- dRestart=on-failure gibi restart policy direktifleri, hata yönetiminin servise özgü çalıştırma bloğu yerine genel unit metadata'sına ait olduğu yanlış varsayımıyla
Açıklama:[Unit], türden bağımsız genel metadata ve sıralama/bağımlılık direktiflerini tutar (Description=, After=, Requires=, Wants=). ExecStart= ve Restart= [Service]'e, WantedBy= ise [Install]'a aittir.
Linux Systemd Service ManagementZorluk 1
Bir systemd unit'inin [Unit] veya [Install] yerine [Service] bölümünde hangi direktifi bulmayı beklersiniz?
- aUnit'in okunabilir tek satırlık özetini veren Description=, bu değer ayrıca
systemctl status çıktısında ve journal girdilerinde de görünür - bDiğer unit'lere göre sıralama ipucu veren After=; birçok mühendis bunun Requires= gibi sert bir bağımlılık da ima ettiğini varsayar
- cServis başladığında çalıştırılan komutu tanımlayan ExecStart=✓
- dEnable edildiğinde bu unit'i çeken target'ı belirten WantedBy=, sıklıkla yanlışlıkla [Service] içinde bulunması beklenen bir direktiftir
Açıklama:ExecStart=, [Service] bölümüne ait bir direktiftir: systemd'nin bu belirli servis için çalıştıracağı asıl komutu tanımlar. Description= ve After= genel [Unit] direktifleridir; WantedBy= ise bir [Install] direktifidir.
Linux Systemd Service ManagementZorluk 1
Bir unit dosyasındaki [Install] bölümünün amacı nedir?
- aServis tarafından fiilen çalıştırılan process'i tanımlar; çünkü [Install], bazen [Service] ile birlikte ExecStart='ı tanımlamak için alternatif bir yer olarak yanlışlıkla düşünülür
- bSadece dosyayı okuyan insanlar için dokümantasyon metinleri tutar, systemd'nin çalışma zamanında hiç ayrıştırmadığı bir kod yorum bloğuna benzer şekilde
- cServis için CPU ve memory gibi kaynak limitlerini ayarlar; oysa bu sorumluluk aslında [Service] içindeki CPUQuota= gibi cgroup direktiflerine aittir
- dUnit'in hangi target'lara bağlandığını (örn. WantedBy=) tanımlar, böylece
systemctl enable boot zamanında hangi symlink'i oluşturacağını bilir✓
Açıklama:[Install] yalnızca systemctl enable/disable tarafından kullanılır: bu unit'e hangi target'ın .wants/ dizininde symlink oluşturulacağını söyler. Servisin fiilen nasıl çalıştığı üzerinde hiçbir etkisi yoktur.
Linux Systemd Service ManagementZorluk 2
Bir junior mühendis systemctl start myapp çalıştırıyor ve servis düzgün ayağa kalkıyor. Ancak bir sonraki reboot'tan sonra servis çalışmıyor. En olası açıklama nedir?
- a
systemctl start, servisi mevcut oturum için hemen başlatır ama systemctl enable'ın oluşturduğu boot-zamanı symlink'ini oluşturmaz✓ - bUnit dosyası ilk başlatmadan sonra otomatik olarak silinmiş olmalı; bu, systemd'nin unit dosyalarını çalışma zamanı durumundan bağımsız olarak diskte kalıcı tutmasıyla örtüşmez
- c
systemctl start yalnızca makine zaten tamamen boot olmuşken çalışır, bu yüzden gelecekteki hiçbir reboot'ta etkili olamaz — start'ın yönettiği geçici çalışma zamanı durumunu, yalnızca enable'ın oluşturduğu kalıcı boot-zamanı symlink'leriyle karıştıran bir iddiadır - dServisler her reboot'tan sonra mutlaka bir
systemctl daemon-reload gerektirir ve bu adım atlanmış; oysa daemon-reload sadece değişen unit tanımlarını yeniden ayrıştırır ve boot'ta otomatik başlatmayla hiçbir ilgisi yoktur
Açıklama:start ve enable birbirinden bağımsız eylemlerdir: start yalnızca mevcut çalışma zamanı durumunu etkiler; unit'in gelecekteki boot'larda otomatik ayağa kalkmasını sağlayan şey ise ilgili target'ın .wants/ dizini altında bir symlink oluşturan enable'dır.
Linux Systemd Service ManagementZorluk 1
systemctl status myapp.service bir bakışta hangi bilgiyi gösterir?
- aSadece ilgili ağ portunun açık olup olmadığını;
systemctl status'u bir unit-durumu özeti yerine ss gibi bir port-tarama aracıyla eşdeğer sayan bir yanılgıdır - bUnit'in active/inactive/failed durumunda olup olmadığını, ne zamandan beri o durumda olduğunu, main PID'i ve son log satırlarının kısa bir özetini✓
- cSadece unit dosyasının içeriğini, çalışma zamanı durumu olmadan; sanki diskteki dosyanın düz bir
cat'i gibi davranıyormuş gibi - dSadece son exit code'u, zaman bilgisi olmadan; komutun fiilen yazdırdığı active-durum ve main PID alanlarını göz ardı ederek
Açıklama:systemctl status, kompakt bir çalışma zamanı özeti verir: mevcut active durumu, o durumda ne kadar süredir olunduğu, main process PID'i (çalışıyorsa) ve o unit için en son journal satırları — ilk triaj adımı için kullanışlıdır.