Linux'ta Process, Service ve Daemon Arasındaki Fark

Terminalde node server.js çalıştırdığınızda API cevap verebilir. Terminali kapatınca uygulamanın durması veya sunucu yeniden başladığında açılmaması ise başka bir konudur. Programın çalışması ile programın işletilmesi farklı sorumluluklardır. Process, service ve daemon kavramları bu farkı açıklamak için kullanılır.

Process: programın çalışan örneği

Process, işletim sisteminin yürüttüğü bir program örneğidir. PID, kullanıcı kimliği, bellek alanı, açık dosyaları ve yürütme durumu vardır. Aynı programı iki kez başlatırsanız iki ayrı process oluşabilir. Bir süreç kendi içinde birden fazla thread de kullanabilir.

ps -eo pid,ppid,user,stat,etime,args --sort=pid
pgrep -a node
pstree -p

PPID, üst sürecin kimliğidir. Bir shell'den başlattığınız programın nasıl bir süreç ağacına dahil olduğunu bu bilgiyle görebilirsiniz. Ancak PID'yi kalıcı uygulama kimliği olarak kullanmayın: süreç yeniden başladığında değişir ve eski PID başka bir programa verilebilir.

Çalışan her süreç CPU kullanıyor değildir. Ağ verisi bekleyen bir sunucu uzun süre uyuyabilir. Yüksek CPU, çok sayıda thread ve çok sayıda process birbirinden farklı gözlemlerdir.

Daemon: arka planda hizmet veren program

Daemon, kullanıcıyla etkileşimli terminal üzerinden çalışmak yerine arka planda hizmet sunan programlar için kullanılan bir terimdir. SSH sunucusu veya zamanlanmış işleri yürüten bir program buna örnek olabilir.

Tarihsel Unix yaklaşımında daemon süreçleri terminalden ayrılmak için fork ve oturum yönetimi işlemleri yapardı. Modern servis yöneticileri altında programın ön planda çalışması ve yaşam döngüsünü yöneticinin kontrol etmesi genellikle daha basittir. Bu tarihsel ayrım daemon(7) kılavuzunda anlatılır.

Bir komutun sonuna & eklemek tek başına servis yönetimi sağlamaz. Yeniden başlatma politikası, kullanıcı kimliği, açılış sırası ve kontrollü kapanma hâlâ çözülmemiş olabilir.

Service: bir yaşam döngüsü tanımı

Service, systemd gibi bir yöneticinin başlatabildiği, durdurabildiği ve izleyebildiği bir çalışma birimidir. Bir servis birden fazla süreç içerebilir. Tek seferlik bir iş de servis olabilir; her servis sonsuza kadar çalışan bir daemon olmak zorunda değildir.

Systemd'nin .service dosyası, çalıştırılacak komut ve sürecin nasıl yönetileceğini tanımlar. Aşağıdaki örnek systemd kullanan bir Linux makinesi içindir. taskapi hesabının, uygulama dizininin ve environment dosyasının önceden oluşturulduğu varsayılır:

[Unit]
Description=Task API
After=network.target

[Service]
Type=exec
User=taskapi
Group=taskapi
WorkingDirectory=/opt/task-api
EnvironmentFile=/etc/task-api/config.env
ExecStart=/usr/bin/node /opt/task-api/server.js
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

/usr/bin/node yolunu kendi kurulumunuzla doğrulayın. Kullanıcı shell'inde çalışan bir sürüm yöneticisinin binary'si, servis ortamında otomatik bulunmayabilir.

Type=exec, programın çalıştırılabildiğini denetler; HTTP endpoint'inin hazır olduğunu kanıtlamaz. After=network.target da uzaktaki veritabanının ulaşılabilir olduğu anlamına gelmez. Uygulama bağlantı hatalarını kendi sınırları içinde yönetmelidir. Başlatma türlerinin anlamı systemd.service belgesinde ayrıntılıdır.

Start, enable, reload ve restart

Unit dosyasını /etc/systemd/system/task-api.service olarak kaydettikten sonra yönetim adımları şöyledir:

sudo systemctl daemon-reload
sudo systemctl enable --now task-api
systemctl status task-api --no-pager
journalctl -u task-api -n 50 --no-pager

daemon-reload, systemd'nin unit tanımlarını yeniden okumasını sağlar; uygulamayı otomatik yeniden başlatmaz. enable, açılışta başlatma ilişkilerini kurar. --now mevcut oturumda da başlatır. Yalnızca start kullanmak ise sonraki açılış için kalıcılık sağlamaz.

Uygulama ayarlarını yeniden okuma desteği yoksa reload ile restart aynı şeymiş gibi davranmayın. Kontrollü yeniden yükleme, uygulamanın ve servis tanımının desteğine bağlıdır.

Sinyaller ve düzgün kapanma

Servis durdurulurken uygulamaya çoğunlukla SIGTERM gönderilir. Programın yeni istek almayı bırakması, devam eden işleri sınırlı sürede bitirmesi ve kaynaklarını kapatması gerekir. Süre dolarsa yönetici daha güçlü sonlandırma uygulayabilir.

SIGKILL yakalanamaz. İlk müdahale olarak zorla öldürmek, yarım kalan işlemler ve kaybolan teşhis bilgisi yaratabilir. Öte yandan kapanmayı sonsuza kadar beklemek de dağıtımı kilitler. Uygulamanın kapanma bütçesi ile servis yöneticisinin süresi birlikte tasarlanmalıdır.

Çalışıyor görünmek, sağlıklı olmak değildir

Bir API'nin process'i mevcutken tüm istekleri veritabanı bağlantı hatasıyla sonuçlanabilir. Bu nedenle üç ayrı kontrol düşünün: process yaşıyor mu, uygulama istek kabul etmeye hazır mı ve kullanıcı işlemi gerçekten başarıyla tamamlanıyor mu?

Örnek olayda servis sürekli yeniden başlıyorsa restart sayısını, exit kodunu ve son logları birlikte inceleyin. Yanlış environment dosyasını daha sık yeniden başlatmak düzeltmez. journalctl ile yalnızca ilgili servis ve zaman aralığını seçmek teşhisi hızlandırır.

İşletilebilir bir servis, “arkada açık duran program”dan fazlasıdır: nasıl başlayacağı, neden durduğu ve ne zaman gerçekten hazır olduğu anlaşılır olmalıdır.