Bir Linux Servisini Yeniden Başlatma veya Sistem Çökmesi Sonrasında Otomatik Başlayacak Şekilde Yapılandırma: Bölüm 2 (Teorik Açıklamalar)

İki bölümlük eğitimin, Linux servislerinin bir yeniden başlatma veya sistem çökmesinden sonra otomatik olarak başlaması için yapılandırılmasına ilişkin bu ikinci bölümünde, init sistemini ayrıntılı olarak ele alacağız. Şuraya başvurabilirsiniz: Serinin 1. Bölümü: Bir Linux Servisinin Yeniden Başlatma veya Sistem Çökmesinden Sonra Otomatik Başlayacak Şekilde Yapılandırılması: Pratik Örnekler.

Bu eğitim ağırlıklı olarak teori içerecektir. Bu nedenle, Linux'ta init sisteminin nasıl çalıştığını daha derinlemesine anlamak için bunu bir referans olarak kullanmalısınız. Bu eğitimin ilk bölümünde, init sisteminin başlangıçta okuduğu bazı kod parçacıklarını ve başlangıç betiklerini paylaşmıştık. Ayrıca, MySQL örneğini kullanarak bir Linux servisinin çökme veya yeniden başlatma sonrasında otomatik olarak başlamasını nasıl etkinleştireceğinizi ve devre dışı bırakacağınızı öğrendik. Bu iki bölümlük eğitimin ilk bölümünde öğrendiğiniz gibi, Linux'un farklı dağıtımlarında kullanılan üç init sistemi vardır: System V, Upstart ve Systemd. Şuraya başvurabilirsiniz: belirli bir init sistemini kullanacak şekilde yapılandırılmış dağıtımı ve sürümü anlamak için bu eğitimin ilk bölümüne.

Bu eğitimde, eğitimin ilk bölümünde kullandığımız kodları açıklayacağız. Init sisteminin kullandığı komutları ve yapılandırma dosyalarını ayrıntılı olarak ele alacağız. Başlayalım!

Gereksinimler

Bu iki bölümlük eğitimin ilk bölümünün sonucunda, üç test sunucusunu çalışır durumda tutmanız gerektiğini belirtmiştik. Eğer bunları sildiyseniz, geri dönüp yeniden oluşturabilirsiniz. Bu, eğitimi takip etmenize yardımcı olacaktır. Sahip olmanız gereken üç test sunucusu şunlardır:

• Ubuntu 9.04 ve öncesi veya Debian 6 x64 (bunu System V init sistemini göstermek için kullanacağız)
• Ubuntu 14.04 x64 (bunu Upstart'ı göstermek için kullanacağız). İşte Ubuntu sunucunuzu kolayca nasıl kuracağınıza dair bir eğitim.
• CentOS 7 x64 (bunu Systemd'yi göstermek için kullanacağız).

Komutları çalıştırmak için kullanacağınız sunucuların her birinde sudo yetkilerine sahip bir kullanıcınız olmalıdır. Bu Linux sudoers dosyasını yapılandırma konusundaki eğitim size yol gösterebilir.

Not: Eğitimdeki komutlar sistem servislerine müdahale edecektir. Bu nedenle, bunları canlı bir üretim (production) sunucusunda uygulamamalısınız.

Çalışma Seviyeleri (Runlevels)

Bir çalışma seviyesi (runlevel), hangi servislerin kullanılabilir olduğuyla ilişkili olarak bir Linux sisteminin mevcut durumunu tanımlayan işletimsel bir seviyedir. Bu kavram System V init'ten gelmektedir. Linux sistemi açıldığında çekirdeği başlatır, bir çalışma seviyesine girer ve bu çalışma seviyesiyle ilişkili başlangıç betiğini çalıştırır. Başlangıçta yalnızca bir çalışma seviyesi yürütebilirsiniz.

Çalışma seviyelerinin diğer örnekleri arasında kapatma durumu, yeniden başlatma modu, tek kullanıcı modu vb. yer alır. Her seviye, o durumda hangi servislerin çalıştırılacağını belirler. Bazı servisler birden fazla seviyede çalışabilirken, diğerleri çalışamaz.

Yedi çalışma seviyesi vardır: 0'dan 6'ya kadar. Aşağıda yedi çalışma seviyesinin tanımı verilmiştir:

• Çalışma Seviyesi 0: Sistem kapatma
• Çalışma Seviyesi 1: Tek kullanıcı ve kurtarma modu
• Çalışma Seviyeleri 2, 3, 4: Ağ iletişimi etkinleştirilmiş çok kullanıcılı ve metin modu
• Çalışma Seviyesi 5: Çok kullanıcılı, ağ etkinleştirilmiş ve grafiksel mod
• Çalışma Seviyesi 6: Sistemi yeniden başlatma

Çalışma seviyelerinin mutlaka sırayla yürütülmesi gerekmez. Çalışma seviyeleri 2, 3 ve 4, çalıştırdığınız Linux dağıtımına bağlı olarak değişiklik gösterir. Çalışma seviyesi 4'ü bazı dağıtımlarda uygulayabilir, bazılarında ise uygulayamayabilirsiniz. Birinci bölümde açıklandığı gibi bir servisi otomatik olarak başlayacak şekilde etkinleştirdiğinizde, aslında onu bir çalışma seviyesine eklemiş olursunuz. System V'te işletim sistemi belirli bir çalışma seviyesiyle başlar ve başlangıç sırasında bu çalışma seviyesiyle ilişkili tüm servisleri başlatmaya çalışır. Çalışma seviyeleri, Systemd bölümünde ele alacağımız Systemd'deki hedeflerdir (targets).

Init ve PID 1

Init sistemi, bir Linux Sistemi açıldığında ve Çekirdek belleğe yüklendiğinde çalışan ilk işlemdir. Bir kullanıcı işleminin veya sistem servisinin nasıl, hangi sırayla yükleneceğini ve otomatik olarak başlayıp başlamayacağını belirlemek de dahil olmak üzere çeşitli görevleri yerine getirir. Her Linux dağıtımında, her işlem bir işlem kimliği (PID) ile tanımlanır ve init'in PID'si 1'dir. Sistem açılırken art arda başlayan diğer tüm işlemlerin üst (parent) işlemidir.

init Tarihçesi

Son Linux dağıtımlarında bulunan init sistemi, orijinalinin bir geliştirmesidir. Linux dağıtımlarının en eski sürümleri, benzer şekilde kullanılan System V init'i kullanıyordu: Unix sistemleri. Linux geliştikçe, Upstart init daemon'ı uygulandı – bu daemon Ubuntu tarafından oluşturulmuştu. Şimdi, (bu kılavuzun yazıldığı sırada, 2021) ilk olarak Fedora tarafından uygulanan Systemd init daemon'ına sahibiz. Linux sistemleri gelişmeye devam ettikçe, daha yeni bir init sistemi ortaya çıkabilir. Bu kılavuz için şu üçünü ele alacağız: System V, Upstart ve Systemd.

Son Linux sürümleri varsayılan olarak Systemd init sistemiyle birlikte gelir. Ancak, geriye dönük uyumluluk için diğer eski init sistemlerini korumuşlardır. Linux'un diğer varyantlarında kullanabileceğiniz farklı System V uygulamaları vardır. Örneğin, bir UNIX varyantı olan FreeBSD, BSD init kullanır. Debian'ın eski sürümleri SysVinit kullanır. Her ikisi de System V'ten türetilmiştir.

Init daemon'ının her bir sürümünün servisleri yönetme şekli farklıdır. Her sürüme eklenen iyileştirmeler, bir Linux sisteminin servislerden, cihazlardan, portlardan ve diğer kaynaklardan ihtiyaç duyduğu her şeyi yönetecek sağlam bir servis yönetim aracına yönelikti. Kaynakları paralel olarak yükleyebilen ve bir sistem çökmesinden sorunsuz bir şekilde kurtulabilen güçlü bir sisteme ihtiyaç vardı.

System V Init Sıralaması

System V, başlatma talimatlarını tutmak için bir inittab dosyası kullanır. Upstart, geriye dönük uyumluluk için inittab dosyasını korur. İşte System V başlangıç akışı:

• Init sistemi şu ikili (binary) dosyadan gelir: /sbin/init.
• Init sistemi belleğe yüklendikten sonra ilk dosyasını şu konumda okur: /etc/inittab.
• Bu dosyadaki girdilerden biri, makinenin hangi çalışma seviyesinde (runlevel) önyükleme yapması gerektiğini belirler. Örneğin, çalışma seviyesi değeri 5 olarak belirtilirse, Linux ağ bağlantısı etkinleştirilmiş çok kullanıcılı, grafiksel modda önyükleme yapacaktır (masaüstü kullanımı için tasarlanmış dağıtımlarda yaygındır). Burada belirtilen çalışma seviyesi, her zaman kullanılacak olan seviye olduğu için varsayılan çalışma seviyesi (default runlevel) olarak bilinir.
• Ardından, init sistemi /etc/inittab dosyasına daha detaylı bakar ve o çalışma seviyesi için hangi init betiklerini (init scripts) çalıştırması gerektiğini okur.

Belirli bir çalışma seviyesi için hangi betiklerin çalıştırılacağını bularak, init sistemi hangi servisleri başlatması gerektiğini bulacaktır. Bu init betikleri, bu kılavuzun ilk bölümünde MySQL servisini yapılandırdığımız gibi, genellikle bireysel servisler için başlangıç davranışını yapılandırdığınız yerdir.

System V Init Betikleri Yapısı

Bu bölümde, init betiklerini ayrıntılı olarak inceleyeceğiz. System V yapılandırma dosyaları veya init betikleri, servisleri kontrol eden yapılardır. Init betikleri bir servisi başlatır (initialize eder), bu yüzden adı init betiğidir.

Her servisin kendi init betiği vardır. Örneğin, MySQL init betiği MySQL sunucusunu kontrol eder. Uygulama sağlayıcıları kendi özel uygulamaları için init betiklerini sağlarken, yerel Linux servisleri İşletim Sistemi kurulumuyla birlikte gelir. Özel bir uygulama oluşturduğunuzda, onun için kendi özel init betiklerinizi de oluşturabilirsiniz.

MySQL sunucusu gibi bir servisi başlatmak için, öncelikle onun ikili (binary) programı belleğe yüklenir. Yapılandırmasına bağlı olarak program, istemci bağlantılarını kabul etmeye devam etmek için arka planda çalışmaya devam edebilir. Servisin init betiği; ikili uygulamayı başlatma, durdurma veya yeniden yükleme işini üstlenir. System V'teki init betikleri kabuk betikleridir (shell scripts). Bunların bir diğer adı da rc (run command) betikleridir.

System V Dizin Yapısı

Init betiklerinin üst dizini /etc dizinidir. /etc/init.d dizini, init kabuk betiklerinin asıl dizinidir. Betikler, rc dizinlerine sembolik olarak bağlanmıştır (symlinked).

Şu dizinin içinde birkaç rc dizini bulunur: /etc dizini; her birinin adında bir sayı bulunur. Sayılar farklı çalışma seviyelerini temsil eder. Dizin içeriğini listelerseniz, şunun gibi isimler görürsünüz: /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, vb.

rc dizinlerinin her birinin içeriğini görüntülerseniz, şu harflerle başlayan dosyalar görürsünüz: K veya S dosya adlarında, ardından iki basamak gelir. Bu dosyalar, gerçek programın gerçek init kabuk betiklerine geri işaret eden sembolik bağlantılar içerir. Harfler K ve S kısaltmalardır: K, Kill (Durdur) veya Stop anlamına gelirken, S ise Start (Başlat) anlamına gelir. Dosya adlarındaki iki basamak, yürütme sırasını temsil eder. Eğer adında K05script_name olan bir dosya görürseniz, bu dosya adında K09script_name.

Başlangıç

Başlangıç dizisiyle devam ederken, init betiklerinin nasıl çağrıldığına bakalım.

S ve K betikleri doğrudan init sistemi tarafından çağrılmaz. Bunun yerine, başka bir betik tarafından çağrılırlar: /etc/init.d/rc betiği. /etc/inittab dosyası, init daemon'ına sistemin varsayılan olarak hangi çalışma seviyesinde (runlevel) önyükleme yapması gerektiğini bildirir. Belirtilen çalışma seviyesine bağlı olarak, /etc/inittab dosyasındaki bir satır, varsayılan çalışma seviyesini bir parametre olarak geçirerek /etc/init.d/rc betiğini çağırır. Bu parametreyi kullanan betik, ilgili /etc/rcN.d dizini altındaki dosyaları çağıracaktır; burada N çalışma seviyesini belirtir. Örneğin, sunucu çalışma seviyesi 5 ile başlarsa, /etc/rc5.d dizini altındaki ilgili dosyalar çağrılacaktır.

Şu dizinin içinde: rc dizininde, tüm K betikleri sayısal olarak şu argümanla çalıştırılır: stop, tüm S betikleri de benzer şekilde start argümanıyla çalıştırılır. /etc/rc altındaki dosyaların sembolik bağlarla işaret ettiği programın ilgili gerçek init kabuk betikleri sırasıyla N.d şu parametrelerle çağrılacaktır: stop ve start parametreleri.

Basit bir ifadeyle, bir Linux sistemi belirli bir çalışma seviyesine girdiğinde veya bu seviyeye geçiş yaptığında gerçekleşen şey, bazı hizmetleri durdurmak için belirli betiklerin çalıştırılması, diğer hizmetleri başlatmak için ise başka betiklerin çalıştırılmasıdır. Bu süreç, belirli bir Linux durumunda çalışmaması gereken herhangi bir işlemin durdurulmasını ve çalışması gereken herhangi bir işlemin otomatik olarak başlatılmasını sağlar.

System V Otomatik Başlatma

Bir hizmeti önyükleme sırasında otomatik olarak başlayacak şekilde etkinleştirdiğinizde, doğrudan init davranışını değiştirmiş olursunuz. Örneğin, bir hizmeti çalışma seviyesi 2'de otomatik başlayacak şekilde yapılandırırsanız, init işlemi şu dizinde uygun sembolik bağlantıları oluşturur: /etc/rc2.d dizini. Anlamanıza yardımcı olmak için bunu bir örnekle açıklayacağız.

System V Örneği

Size pratik bir örnek vermek için, 1. bölümdeki MySQL hizmet yapılandırmasını kullanacağız. Bu nedenle, ssh (veya Windows kullanıyorsanız putty) kullanarak sudo/root kullanıcınızla Debian 6 VPS'ye giriş yapın ve aşağıdaki adımlarla devam edin.

Adım 1: inittab dosyasını açın ve inceleyin

İlk olarak, terminalde inittab dosyasının içeriğini görüntülemek için aşağıdaki komutu girin:

Dosyanın içeriği şuna benzer olmalıdır:

2 sayısı, sistemin başladığı çalışma seviyesini (runlevel) belirtir. Bu durumda, çalışma seviyesi 2 varsayılandır, dolayısıyla bu Debian sistemi çalışma seviyesi 2'de çok kullanıcılı, metin modunda başlayacaktır. Onaylamak için aşağıdaki komutu çalıştırabilirsiniz:

Şuna benzer bir çıktı gösterecektir:

Adım 2: rc dizinlerini inceleme

Ardından, rc dizinlerini listelemek için aşağıdaki komutu çalıştırın:

İşte çıktının bir ekran görüntüsü:

Daha önce inittab dosyasında gördüğümüz gibi, sistem şu çalışma seviyesinde önyükleme yapacak şekilde yapılandırılmıştır: runlevel 2, dolayısıyla şu dizin altındaki betikler: /etc/rc2.d sistem başlangıcında yürütülecektir. Bu dizinin içeriğini şu komutu kullanarak listeleyebilirsiniz:

Çıktıdan da görebileceğiniz gibi, dosyalar sadece şu dizin altındaki gerçek betik dosyalarını işaret eden sembolik bağlantılardır: /etc/init.d. İşte çıktıdan bir kesit:

Bu dizinde K betiği yoktur, yalnızca S (başlatma) betikleri vardır. Betikler, burada bağlantılı olan hizmetleri başlatacaktır, örneğin: rsync. Bir sonraki alt başlıkta ele alacağımız listedeki mysql hizmetini de fark edebilirsiniz.

Adım 3: Init Betiğini İnceleme

System V ile uyumlu bir servis kurulduğunda, /etc/init.d dizini altında bir kabuk betiği (shell script) oluşturur. Aşağıdaki komutu girerek MySQL kabuk betiğinin kullanılabilirliğini kontrol edebilirsiniz:

Aşağıdaki çıktıyı gösterir:

Dosya oldukça büyüktür. İçeriğini görüntülemek için aşağıdaki komutu girebilirsiniz:

Adım 4: chkconfig veya sysv-rc-conf Kullanımı

Chkconfig, CentOS gibi RHEL tabanlı dağıtımlarda System V uyumlu servisleri etkinleştirmek veya devre dışı bırakmak için kullanabileceğiniz bir komuttur. Ayrıca kurulu servisleri ve bunların ilgili çalışma seviyelerini listelemek için de kullanabilirsiniz. Bunun için gereken komut şudur (CentOS üzerinde çalışır):

Debian dağıtımlarında, böyle bir araç yerel olarak mevcut değildir. Debian sistemlerindeki update-rc.d, servisleri yalnızca çalışma seviyelerinden yükler ve kaldırır. chkconfig işlevselliğini Debian sistemlerine getirmek için kullanabileceğiniz özel bir araç mevcuttur. Kurmak için aşağıdaki komutu girin:

Kurulduktan sonra, çeşitli servislerin çalışma seviyesi davranışlarını görüntülemek için aşağıdaki komutu çalıştırabilirsiniz:

Bu komutun çıktısı, solda servis adını ve servisin çalıştığı çalışma seviyesini gösteren bir tablo şeklinde biçimlendirilir:

X işareti, servisin hangi çalışma seviyesinde çalışacağını gösterir. Bu araç, yön tuşlarını ve boşluk tuşunu kullanarak bir servisi bir çalışma seviyesi için etkinleştirmenize veya devre dışı bırakmanıza olanak tanır. Araçtan çıkmak için Q tuşuna basın.

Adım 5: Sistem Önyüklemesi Sırasında MySQL Başlangıç Davranışını Test Etme

Yukarıdaki ekran görüntüsünden, mysql servisinin 2,3,4,5 çalışma seviyelerinde etkinleştirildiğini görebilirsiniz. Aşağıdaki komutu kullanarak MySQL'i devre dışı bırakabilirsiniz:

Çıktı şu şekildedir. Servisin tüm çalışma seviyeleri için durdurulduğuna dikkat edin:

Dizinin içeriğini görmek için aşağıdaki komutu çalıştırın:

Aşağıdaki çıktıdaki mysql satırına bakın:

Çıktı, sembolik bağın (symlink) K, yani Kill (durdur) olarak değiştiğini gösterir. Bu nedenle, MySQL varsayılan olarak çalışma seviyesi 2'de otomatik olarak başlamayacaktır. System V'te bir servisi ne zaman etkinleştirseniz veya devre dışı bıraksanız gerçekleşen şey budur. Bir servis için varsayılan çalışma seviyesi dizini altında bir S (start) betiği olduğu sürece, init arka plan programı (daemon) sistem önyüklemesi sırasında o servisi başlatacaktır.

Servisi tekrar etkinleştirmek için aşağıdaki komutu girin:

Adım 6: Sistem Çökmesinden Sonra MySQL Başlangıç Davranışını Test Etme

Bu bölümde, System V'in servis çökmelerini nasıl ele aldığını tartışacağız. Bu bilgiyi, özel servislerinizin bir çökmeden sonraki davranışını yapılandırmak için kullanabilirsiniz.

Bu kılavuzun ilk bölümünde, MySQL'in bir çökmeden sonra otomatik olarak başlamasını sağlamak için /etc/inittab dosyasında bir değişiklik yapmıştık. Bu davranışı etkinleştirmek için aşağıdaki satırı eklemiştik:

Birkaç test yaparak bu davranışı kontrol edebiliriz. İlk olarak, aşağıdaki komutu girerek VPS'inizi yeniden başlatın:

Yeniden başlatmanın ardından, mysql_safe ve mysqld'nin hangi işlem kimlikleri (PID) ile çalıştığını kontrol edin, işlem kimliklerini almak için aşağıdaki komutu girin:

Aldığımız çıktı şuydu:

Süreç kimliklerini (PID) not edin. Bizim durumumuzda bunlar 1836 ve 186338 idi. Şimdi, aşağıdaki komutu girerek süreci -9 anahtarıyla sonlandırıp bir çökme simülasyonu yapın. Kendi süreç kimliklerinizle değiştirmeyi unutmayın:

Birkaç dakika sonra, aşağıdaki komutu çalıştırarak MySQL'in durumunu kontrol edin:

Çıktı, MySQL'in çalıştığını gösterir; yani simüle edilen çökmeden sonra yeniden başlatılmıştır (respawn). Eğer ps -ef | grep mysql komutunu tekrar çalıştırırsanız, hem mysqld_safe hem de mysqld süreçlerinin, yeni kimliklerle de olsa çalıştığını göreceksiniz.

Süreçleri birden çok kez sonlandırmayı deneyebilirsiniz, birkaç dakika sonra yeniden başlayacaklardır. Bu davranış, /etc/inittab dosyasına eklediğimiz satır sayesinde mümkündür. System V'te servisleri bir çökmeden sonra otomatik olarak yeniden başlayacak şekilde bu şekilde yapılandırırsınız. Sözdizimini tekrar görmek için bu kılavuzun 1. Bölümüne göz atın.

Bazı özel servislerde hatalar olabilir ve birden fazla denemeden sonra yeniden başlatılamayabilir. Init arka plan programı (daemon) bir servisi yeniden başlatmayı deneyecektir, ancak iki dakika içinde ondan fazla kez başarısız olursa, Linux sistemi servisi 5 dakikaya kadar devre dışı bırakır. Bu, sistemin kararlı kalmasına yardımcı olur ve sistem kaynaklarının çöken servisler için boşa harcanmamasını sağlar. Düzeltilmesi gereken özel uygulamalarınızla ilgili sorunları belirlemek için sistem günlüklerinizi (logs) kontrol etmek iyi bir fikirdir.

Upstart'a Giriş

System V init sistemi uzun süredir Linux dağıtımları için kritik bir öneme sahipti. Ancak, teknolojide olduğu gibi, sürekli ilerleme kaydedilmektedir. Linux ekosistemi, açık kaynak topluluğunun desteği sayesinde muazzam bir büyüme gösterdi. System V, işleri ve servisleri sıralı (seri) bir şekilde yükler, bu da karmaşıklık getirir ve zaman tüketir. Ayrıca, System V'in tasarlanmadığı modern takılabilir depolama ortamlarının ortaya çıkması, farklı bir init sistemine olan ihtiyacı artırdı.

Ubuntu geliştiricileri başka bir başlatma sistemi üzerinde çalışmaya başladılar. Bu init sistemi, işletim sisteminin daha hızlı yüklenmesini sağlamak, çöken servislerin düzgün bir şekilde temizlenmesini garanti etmek, sistem servisleri arasındaki bağımlılığı öngörülebilir tutmak ve takılabilir depolama ortamlarını hesaba katmak üzere tasarlanmıştı. Böylece Upstart arka plan programı (daemon) doğdu.

Upstart init, System V init'e göre şu yönlerden çeşitli avantajlara sahiptir:

• Upstart, servisleri System V gibi sıralı olarak yüklemez, bu nedenle sistemin önyükleme (boot) süresini kısaltır.
• Çöken servisleri, düzgün temizleme ve servisi yeniden başlatma (respawn) özellikleri ile daha iyi yönetecek şekilde tasarlanmıştır.
• Upstart, servislerin çeşitli durumlardaki yönetimini özelleştirmek için esnek bir olay (event) sistemi kullanır.
• Bu init, System V'te olduğu gibi servisleri yüklemek ve yönetmek için kullanılan karmaşık kabuk betiklerinden (shell scripts) kaçınır. Upstart, anlaşılması ve değiştirilmesi kolay basit yapılandırma dosyaları kullanır.
• Upstart, geriye dönük uyumluluk göz önünde bulundurularak oluşturulmuştur. Yerel System V servislerini yönetmek için /etc/init.d/rc betiği hala çalışır.
• Hepsi aynı betiğe işaret eden gereksiz sembolik bağlantıların (symbolic links) tutulmasını önler.

Upstart Olayları

Upstart olay tabanlıdır ve birden fazla olayın aynı servisle ilişkilendirilmesine olanak tanır. Bu olay tabanlı mimari, esnek bir servis yönetimi sağlar. Her olay, o olaya özel bir kabuk betiğini (shell script) çağırabilir.

Upstart olayları şunları içerir:

• Starting
• Started
• Stopping
• Stopped

Bir olay arasında, bir servis bunlarla sınırlı olmamak üzere çeşitli durumlarda (states) olabilir:

• Waiting
• Pre-start
• Starting
• Post-start
• Running
• Pre-stop
• Stopping
• Post-stop

Upstart init, bu durumların her biri için eylemler gerçekleştirecek şekilde yapılandırılabilir, esnek tasarımı da buradan gelir.

Upstart Init Başlangıç Sıralaması

Upstart init, tıpkı System V gibi başlangıçta /etc/init.d/rc betiğini çalıştırır. Bu betik, geriye dönük uyumluluğu sağlamak için tüm System V init betiklerini normal şekilde çalıştırır.

Upstart yapılandırma dosyaları /etc/init dizininde bulunur, bu nedenle varsayılan olarak oraya bakar ve bu dizin altındaki yapılandırma dosyalarında bulunan kabuk komutlarını yürütür.

Upstart Yapılandırma Dosyaları

Upstart init, System V'te kullanılan bash betiklerinin aksine, hizmetleri kontrol etmek için hizmet yapılandırma dosyalarını kullanır. Bu hizmet yapılandırma dosyaları için adlandırma standardı şudur: service_name.conf.

Dosyalar, stanza adı verilen çeşitli bölümlere ayrılmış düz metin içeriği barındırır. Her stanza, bir hizmetin farklı bir durumunu ve davranışını tanımlar. Farklı stanzalar, bir hizmetin farklı olaylarını kontrol eder. Örneğin, bekleme (waiting), başlatma öncesi (pre-start), başlatma (start), durdurma öncesi (pre-stop), durdurma (stopping) vb.

Bir stanza, her hizmet için her olayda birkaç eylemin başlatılmasını mümkün kılan kabuk komutları içerir. Ek olarak, her hizmet yapılandırma dosyası şu iki şeyi belirtir:

• Hizmetin hangi çalışma seviyelerinde (runlevel) başlatılması ve durdurulması gerektiği.
• Hizmetin çökmesi durumunda otomatik olarak yeniden başlatılıp başlatılmayacağı (respawn).

Upstart Dizin Yapısı

Upstart hizmet yapılandırma dosyaları şu dizinin altında bulunur: /etc/init dizini. Bunu şununla karıştırmayın: /etc/init.d.

Upstart Örneği

Bu örnekte, Upstart'ın sistem önyüklemesi sırasında ve bir çökme durumunda bir hizmeti nasıl ele aldığını görececeğiz. Bu eğitimin ilk bölümünde gösterilen pratik örnekleri açıklayarak daha fazla ayrıntıya gireceğiz.

Adım 1: Ubuntu 14.0.4 sunucusuna giriş yapın

İlk olarak, Upstart'ı test etmek için Ubuntu 14.0.4 çalıştıran ikinci VPS'yi kullanacağız. Bunun nedeni, bu Linux dağıtımının Upstart'ı yerel olarak uygulamasıdır. Windows kullanıyorsanız ssh veya putty kullanın. root veya sudo yetkilerine sahip bir kullanıcıyla giriş yapmalısınız. hackins adında bir kullanıcım var, bu yüzden şu şekilde giriş yapardım:

Bunu root/sudo kullanıcınız ve sunucunuzun genel IP adresi ile değiştirin. Ardından, enter tuşuna basın ve bir şifre veya parola girin.

Adım 2: init ve rc dizinini inceleyin

Upstart yapılandırma dosyaları /etc/init dizininde saklanır. Yeni hizmet yapılandırma dosyaları oluştururken kullanacağınız dizin budur.

To list configuration file names in the /etc/init directory, execute the following command:

Yukarıdaki komutun çıktısından göreceğiniz gibi, birçok hizmet Upstart altında çalışmaktadır. less komutundan çıkmak için Q tuşuna basın.

rc dizinindeki System V hizmet yapılandırma dosyalarını listelemek için aşağıdakini çalıştırırsanız, yalnızca birkaç tane görürsünüz:

Adım 3: Bir Upstart dosyasını inceleyin

Bu eğitimin ilk bölümünde, sunucu yapılandırması hakkında bilgi edinmek için bir mysql.conf dosyası kullanmıştık. Bilgilerimizi pekiştirmek için farklı bir yapılandırma kullanalım. cron yapılandırma dosyası iyi bir adaydır. Dosyayı açmak için aşağıdaki komutu girin:

Aşağıdaki ekran görüntüsüne benzer bir çıktı almalısınız:

Betik oldukça basittir. Aşağıdaki önemli alanlara dikkat edin: start on, stop on, fork, ve respawn. Bu yönergelerin ne yaptığını tanımlayalım:

• start on yönergesi, sistem 2, 3, 4 veya 5 numaralı çalışma seviyelerine girdiğinde Ubuntu'ya cron arka plan programını (daemon) başlatmasını söyler. Burada belirtilmeyen diğer çalışma seviyelerinde, yani 0, 1 veya 6'da çalışmayacaktır.
• stop on yönergesi, Ubuntu'ya çalışan bir arka plan programını durdurmasını söyler. Ancak bu durumda bir ünlem işareti (!) vardır ve bu bir olumsuzlama işaretidir. Betik, ünlem işaretinden sonraki çalışma seviyelerinde durdurulmamalıdır: 2,3,4,5.
• fork yönergesi, Upstart'a işlemi konsoldan ayırmasını ve arka planda çalışmaya devam etmesini söyler.
• respawn yönergesi, sisteme herhangi bir nedenle çökmesi durumunda cron programını otomatik olarak başlatmasını söyler.

Hiçbir şey yazmadan editörden çıkmak için Ctrl X tuşlarına basın.

Diğer upstart yapılandırma dosyaları da start, stop ve respawn stanzaları ile aynı yapıyı takip eder. Bazı yapılandırma dosyalarında pre-start, pre-stop, post-start ve daha fazlası için ek betik blokları bulunabilir. Bu kod blokları, bir işlem tanımlanan durumlardan herhangi birindeyken sisteme neyi çalıştıracağını söyler.

Adım 4: Sistem Önyüklendikten Sonra MySQL Hizmeti Başlangıç Davranışını Test Edin

MySQL varsayılan olarak sistem açıldıktan sonra otomatik başlayacak şekilde ayarlanmıştır. Bunu devre dışı bırakmayı ve davranışını görmeyi deneyeceğiz. Upstart'ta bir servis, service_name.override dosyası /etc/init/ dizini altında oluşturularak devre dışı bırakılabilir. Dosyanın içeriği sadece tek bir kelimedir: manual.

MySQL servisini devre dışı bırakmak için bu komutu nasıl kullanabileceğimizi görelim. Dosyayı nano düzenleyici ile açmak için aşağıdaki komutu girin:

Açılan dosyaya aşağıdaki satırı ekleyin:

Ctrl + O tuşlarına basıp ardından enter tuşuna basarak değişiklikleri kaydedin. Ctrl + X tuşlarına basarak düzenleyiciden çıkın. Sunucuyu yeniden başlatmak için aşağıdaki komutu çalıştırın:

Birkaç dakika bekleyin ve ardından tekrar oturum açın. Tekrar oturum açtıktan sonra, aşağıdaki komutu girerek MySQL servisinin durumunu test edin:

Çıktı, servisin çalışmadığını belirtecektir:

Bu, MySQL'in sistem açılışından sonra otomatik olarak başlamadığını gösterir. Ardından, MySQL yapılandırma dosyasını açın ve start yönergesinin değişip değişmediğini kontrol edin:

Çıktı, hiçbir şeyin değişmediğini belirtecektir:

Bu, servisiniz otomatik başlamıyorsa ve yalnızca servisin yapılandırma dosyasını (service_name.conf) kontrol ediyorsanız, hatayı bulamayabileceğiniz anlamına gelir. Ayrıca dizindeki service_name.override dosyasının varlığını da kontrol etmelisiniz.

Geçersiz kılma (override) dosyasını silmek ve MySQL servisini yeniden etkinleştirmek için aşağıdaki komutu girin. Ardından, sunucuyu yeniden başlatın:

Sunucu açıldıktan sonra, MySQL servisinin durumunu tekrar test edin:

MySQL servisinin otomatik olarak başladığını göstermelidir.

Adım 5: Bir Sistem Çökmesinden Sonra MySQL Servisi Başlangıç Davranışını Test Etme

Varsayılan olarak, MySQL servisi çökerse otomatik olarak yeniden başlar. Bu davranışı durdurmak için mysql.conf dosyasını düzenleyeceğiz. Dosyayı nano düzenleyici ile açmak için aşağıdaki komutu girin:

Find the respawn yönerge satırlarını bulun ve aşağıda gösterildiği gibi yorum satırı haline getirin: #:

Servisi yeniden başlatmak için aşağıdaki komutları yürütün:

Servisi durdurmak ve başlatmak için yukarıdaki komutları kullandık çünkü initctl restart veya initctl reload komutlarını kullanmak burada çalışmayacaktır. MySQL servisini başlatmak için komutu çalıştırdığınızda, çıktı MySQL için şuna benzer bir PID gösterecektir:

Bizim PID'imiz 1439'du. Ardından, komutu çalıştırdığınızda ne aldığınızı not edin, bunu bir sonraki adımda kullanacağız. Bir çökmeyi simüle etmek için, aşağıdaki komutu kullanarak MySQL işlemini sonlandırın (kill), yukarıda açıklandığı gibi kendi PID'inizle değiştirmeyi unutmayın:

Çökmeden sonra MySQL'in yeniden başlayıp başlamadığını kontrol etmek için birkaç dakika bekleyin ve ardından aşağıdaki komutu girin:

Çıktı, MySQL'in durdurulduğunu belirtecektir:

Herhangi bir değişiklik olup olmadığını görmek için durumu birkaç kez daha kontrol etmeyi deneyin. MySQL'in durdurulmuş olarak kaldığını fark edeceksiniz. Bunun nedeni, servis yapılandırma dosyasının respawn yönergelerine (yorum satırı haline getirdiklerimiz) sahip olmamasıdır. Respawn yönergesi hakkında daha fazla açıklama için bu kılavuzun 1. bölümüne göz atın.

Sistem önyüklemesinden veya çökmesinden sonra servisler için otomatik yeniden başlatmayı nasıl devre dışı bırakacağınızı neden gösterdik? Bu esas olarak sorun giderme amaçlıdır. Örneğin, servisiniz açılıyor ve çökmeye devam ediyorsa, sorun giderebilmek ve ayrıca sisteminizi kararlı tutmak için bunu devre dışı bırakmak isteyebilirsiniz. Yerleşik olarak systemd ile gelen yeni bir Linux dağıtımına yükseltme yaparsanız, bazı eski servis yapılandırmalarının otomatik olarak yeniden başlatılmasını da durdurabilirsiniz; bu konu bir sonraki bölümde ele alınmaktadır.

Systemd Giriş

Systemd, en son Linux dağıtımlarında bulunan en yeni init sistemidir. Modern bir Linux sistemini oluşturan birçok bileşeni içerir.

Systemd, yalnızca servisleri değil, tüm Linux sistemini de yönetir. Bu bölümde, systemd'nin bir sistem önyüklemesi veya çökmesinden sonra servislerin davranışını nasıl kontrol ettiğine odaklanacağız.

Systemd, System V init betikleri ve komutlarıyla geriye dönük uyumludur. Bu nedenle, System V ile yapılandırılmış herhangi bir servisiniz varsa, bunlar Systemd altında da çalışacaktır. Çoğu Upstart ve System V yönetim komutu, Systemd ile çalışacak şekilde değiştirilmiştir. Systemd, önyükleme sırasında kendisini init olarak yeniden adlandırır. Bir /sbin/init dosyası mevcuttur ve şu dosyaya sembolik bağ oluşturur: /bin/systemd.

Systemd Yapılandırma Dosyaları: Birim Dosyaları

Systemd yapılandırması birim (unit) dosyalarından oluşur. Her birim dosyası bir sistem kaynağını temsil eder. Diğer iki init sistemi (yani System V ve Upstart) bir Linux sisteminin servislerini yönetmekten sorumluyken, Systemd yalnızca servis arka plan programlarını (daemon) değil, aynı zamanda cihaz işletim sistemi yolları, soketler, bağlama noktaları (mount points) vb. gibi diğer sistem kaynağı türlerini de yönetir. Birim dosyaları, kaynak hakkındaki bilgileri depolar.

Her birim dosyası, belirli bir sistem kaynağını şu adlandırma stiliyle temsil eder: service_name.unit_type. Bu, home.mount, dbus.service, sshd.socket vb. dosyalar bulacağınız anlamına gelir. Birim dosyaları, anlaşılması ve değiştirilmesi kolay, bildirimsel (declarative) bir sözdizimine sahip basit metin dosyalarıdır.

Dizin Yapısı

Yerel birim dosyalarının ana konumu /lib/systemd/system/ dizinidir. Sizin oluşturduğunuz veya sistem yöneticileri tarafından özel olarak oluşturulan birim dosyaları ve diğer değiştirilmiş yerel birim dosyaları /etc/systemd/system dizininde saklanır.

Hem /lib/systemd/system/ hem de /etc/systemd/system dizinlerinde aynı ada sahip bir birim dosyası varsa, systemd /etc dizini altındakini kullanacaktır.

Bir servisi önyükleme sırasında veya başka bir hedefte/çalışma seviyesinde (target/runlevel) başlayacak şekilde etkinleştirdiğinizde, /etc/systemd/system altındaki uygun dizinlerde o servis birim dosyası için sembolik bir bağ oluşturulur. /etc/systemd/system dizinindeki birim dosyaları, yalnızca /lib/systemd/system dizinindeki benzer ada sahip dosyaların sembolik bağlarıdır.

Systemd Init Sırası: Hedef Birimleri

Hedef birimleri, genellikle .target uzantısına sahip benzersiz birim dosyası türleridir. Hedef birimleri, belirli bir kaynağı temsil etmedikleri için diğer birim dosyası türlerinden farklıdır. Bunun yerine, sistemin belirli bir andaki genel durumunu temsil ederler.

Bunu başarmak için hedef birimleri, belirli bir durumun parçası olan birden fazla birim dosyasını gruplandırır ve başlatır. Systemd hedefleri ile System V çalışma seviyeleri (runlevels) kabaca karşılaştırılabilse de aynı şey değildir. Bir hedef birim dosyasının sayı yerine bir adı vardır. Örneğin, runlevel 3 yerine multi-user.target veya runlevel 6 yerine reboot.target gibi bir şey bulursunuz. Bir Linux sistemi multi-user.target ile önyüklenebilir. Bu durumda, temelde sunucuyu çalışma seviyesi 2, 3 veya 4'e getirir ve bu da sistemi ağ iletişimi etkinleştirilmiş çok kullanıcılı metin modunda başlatır.

Aradaki fark, sunucuyu bu seviyeye nasıl getirdiğinde yatmaktadır. System V servisleri sırayla başlatır. Diğer yandan, sistem önyüklenirken systemd diğer servislerin veya kaynakların mevcut olup olmadığını kontrol eder ve bunların yüklenme sırasını belirler.

systemd hedef birimleri ile System V çalışma seviyeleri arasındaki bir diğer fark, System V kullanan bir Linux dağıtımının yalnızca tek bir çalışma seviyesinde bulunabilmesidir. Çalışma seviyesini değiştirirseniz, sadece o yeni çalışma seviyesine geçiş yapacak ve orada bulunacaktır. Öte yandan, hedef birim dosyaları kapsayıcı olabilir. Ayrıca, bir hedef birimin etkinleştirilmesi, diğer hedef birimlerin de onun bir parçası olarak yüklenmesini sağlar. Örneğin, grafiksel kullanıcı arayüzüne sahip bir Linux sistemini başlatırsanız, graphical.target etkinleştirilmiş olacaktır. Bu da otomatik olarak multi-user.target biriminin de yüklenmesini ve etkinleştirilmesini sağlar.

İşte çalışma seviyelerini ve hedefleri karşılaştıran bir tablo.

Çalışma Seviyesi (System V)	Hedef Birimleri (systemd)
çalışma seviyesi 0	poweroff.target
çalışma seviyesi 1	rescue.target
çalışma seviyesi 2,3,4	multi-user.target
çalışma seviyesi 5	graphical.target
çalışma seviyesi 6	reboot.target

Systemd default.target

systemd'de, default.target System V'teki varsayılan çalışma seviyesinin karşılığıdır. System V'teki varsayılan çalışma seviyesinin inittab dosyasında tanımlandığını görmüştük. systemd'de ise default.target dosyası bulunur. Varsayılan hedef dosyası /etc/systemd/system dizininde saklanır. Bu dosya, /lib/systemd/system altındaki hedef birim dosyalarından birine sembolik bağ ile bağlanır. Varsayılan hedefi değiştirmek, sadece sembolik bağı yeniden oluşturmak ve sistemin çalışma seviyesini değiştirmek anlamına gelir.

System V'te inittab, Linux'un init betiklerini hangi dizinde bulacağını belirtirdi. Bu, daha önce açıklandığı gibi rc dizinlerinden herhangi biri olabilirdi. Öte yandan, systemd varsayılan hedefi, önyükleme sırasında yüklenecek kaynak birimlerini belirler. Tanımlanan tüm birimler yüklenir. Ancak hepsi paralel olarak yüklenmez ve hepsi sıralı olarak yüklenmez. Kaynak biriminin yüklenmesi, onun wants veya requires.

Systemd Bağımlılıkları: Wants ve Requires

Bu bölümde, Systemd'nin bağımlılıkları nasıl ele aldığını tartışacağız. Upstart ile yapılandırma dosyaları kullanıldığında servislerin paralel olarak yüklenmesinin mümkün olduğunu görmüştük. Ayrıca System V'in, hangi servisin otomatik olarak başlatılacağını veya başka bir servis ya da kaynak hazır olana kadar bekleneceğini belirlemek için çalışma seviyelerini nasıl kullandığını da tartışmıştık. Benzer şekilde, Systemd servisleri de bir veya daha fazla hedefte yüklenecek şekilde veya başka bir servis ya da kaynak hazır olana kadar bekleyecek şekilde yapılandırılabilir.

Systemd'de, başka bir birime requires bir birim dosyası, gerekli birim yüklenip etkinleşene kadar başlatılmaz. İlk birim etkinken gerekli birim yüklenemezse, ilk birim durdurulur.

Bu davranış sistem kararlılığını sağlar. Belirli bir kaynağın (örneğin bir portun) kullanılabilir ve etkin olmasına requires bir servis, bu sayede kaynak kullanılabilir olana kadar (yani port açılana kadar) bekletilebilir.

Buna karşılık, başka bir birimi wants bir birim bu tür kısıtlamalar getirmez. Çağıran birim hala etkinken istenen birim durursa durdurulmaz. Örneğin, graphical-target modundaki bazı zorunlu olmayan servisler.

Systemd Örneği

systemd altında bir servisin davranışını nasıl yapılandırabileceğimizi görelim.

Adım 1: VPS örneğinize giriş yapın

Gerçek hayattan bir servis olarak MySQL'i ve sunucu olarak CentOS 7'yi kullanacağız. Adımları pratik olarak uygulamak ve kavramları anlamak için CentOS 7 VPS'nize giriş yapın veya create one on CloudSigma. Hepsi systemd ile birlikte geldiğinden, CentOS 7, Debian 7 veya 8 ya da Ubuntu 15 veya daha yeni bir dağıtım çalıştıran bir VPS bu bölüm için uygundur. ssh komutunu kullanarak veya Windows kullanıyorsanız PuTTY kullanarak giriş yapın:

Adım 2: default.target Dosyasını ve Bağımlılıklarını İnceleyin

Systemd'nin başlangıç sırası, bu bölümde ayrıntılı olarak tartışacağımız uzun bir bağımlılık zincirini takip eder.

• default.target

default.target dosyası, normal bir önyükleme sırasında başlayan servisleri kontrol eder. Aşağıdaki komutu kullanarak varsayılan hedef birim dosyasını listeleyebilirsiniz:

Çıktı aşağıdaki ekran görüntüsüne benzer bir şey gösterecektir:

Ekran görüntüsü, varsayılan hedefin şu dizindeki multi-user.target dosyasına sembolik bağlandığını göstermektedir: /lib/systemd/system/ dizini. Bu, varsayılan olarak sistemin şu hedef altında önyükleneceği anlamına gelir: multi-user.target, şuna eşdeğerdir: runlevel 3.

• multi-user.target.wants

multi-user.target dosyasının istediği tüm servisleri görmek için aşağıdaki komutu girin:

Çıktı çok sayıda satır içeriyor, işte bir kesit:

Çıktının gösterdiği gibi, bunlar /lib/systemd/system/ dizinindeki gerçek birim dosyalarını gösteren sembolik bağlantılardır. mysqld.service servisinin de multi-user.target hedefinin bir parçası olduğunu belirtmek için onu vurguladık. Belirli bir servisin başlangıçta çalışacak şekilde yapılandırılıp yapılandırılmadığını doğrulamak isterseniz, o dosya için komutu değiştirebilirsiniz. Örneğin, aşağıdaki komutları kullanarak mysql veya cron arka plan programını bulmak için çıktıları filtreleyebiliriz:

Çıktı şunu gösterecektir:

Sonucu cron arka plan programı için filtrelemek üzere aşağıdaki komutu girin:

Çıktı şunu gösterecektir:

Apart from the multi-user.target dışında, system-update.target veya basic.target.

gibi başka farklı hedef türleri de mevcuttur. multi-user hedefinin hangi hedeflere bağlı olduğunu görmek için aşağıdaki komutu girin:

Çıktı şunu gösterir:

Bu, basic-target hedefinin, sistemin multi-user.target modunda başlaması için önce yüklenmesi gerektiği anlamına gelir.

• basic-target

basic.target'ın başka hangi hedefleri istediğini görmek için aşağıdaki komutu girin:

Çıktı şunu gösterecektir:

• sysinit.target

Şunun için gerekli herhangi bir hedef olup olmadığını görmek için aşağıdaki komutu çalıştırabilirsiniz: sysinit.target. Komutun sözdizimi aynıdır. İlerledikçe hangi hedef birimlerinin başka bir hedef birimi tarafından gerekli olduğunu görmek için komutu değiştirmeye devam edebilirsiniz. İşte komut:

Çıktı, şunun için gerekli hiçbir birim olmadığını gösterecektir: sysinit.target. Diğer servislerin ve hedeflerin istenip istenmediğini tarafından sysinit.target kontrol etmek için aşağıdaki komutu kullanabiliriz:

Çıktı, şunun tarafından istenen servislerin ve hedeflerin uzun bir listesini gösterir: sysinit.target. Çıktının bir kısmını aşağıda görebilirsiniz:

system4 ile sistem başlatma sırasında, sistem yalnızca tek bir hedefte kalmaz. Bunun yerine, bir hedeften diğerine geçerken servisleri bağımlı bir şekilde yükler.

Adım 3: Bir Birim Dosyasını İnceleme

Bir birim dosyasının nasıl göründüğüne bakalım. Bu kılavuzun ilk bölümünde MySQL servis birim dosyasını kullanmıştık ve bunu tekrar kullanacağız. Ancak başka bir servis birim dosyasına da bakabiliriz – sshd birim dosyası. Sshd yapılandırma dosyasını açmak için aşağıdaki komutu girin:

Aşağıda, dosyadaki satırları gösteren bir ekran görüntüsü bulunmaktadır:

Gördüğünüz gibi, dosyada ana hatları belirtilen kod blokları, gerektiğinde anlaşılmasını ve değiştirilmesini kolaylaştırır. Aşağıda anlaşılması gereken bazı önemli yönergeler verilmiştir:

• After – After ifadesi, sisteme servisi yalnızca belirtilen hedefler ve servisler yüklendikten sonra yüklemesini söyler. Bu durumda, SSHD servisi network hedefi ve keygen servisi yüklendikten sonra yüklenecektir.
• Wants – Wants ifadesi, hangi hedeflerin bu servisi istediğini gösterir. Bu durumda ssh-keygen.service servisi, sshd.service servisini ister. Ancak sshd başarısız olur veya çökerse, ssh-keygen.service.

Editörü kapatmak için Ctrl + X tuşlarına basın.

Adım 4: Sistem Önyüklemesinde MySQL Servisi Başlangıç Davranışını Test Etme

Bu bölümde, sistem önyükleme zamanında MySQL servisinin davranışını nasıl değiştirebileceğinizi ve test edebileceğinizi göstereceğiz. Önceki bölümde, mysqld.service servisinin multi-user.target tarafından istendiğini gördük. Bu nedenle, önyükleme sırasında otomatik olarak başlayacaktır.

Aşağıdaki komutu çalıştırarak servisi devre dışı bırakabilirsiniz:

Komutun çalıştırılması, mysql sembolik bağının (symlink) /etc/systemd/system/multi-user.target.wants/ dizininden kaldırıldığını gösterir. Bunu test etmek amacıyla, MySQL'in hala multi-user.target:

Komut hiçbir şey döndürmez. Sunucuyu yeniden başlatıp MySQL durumunu kontrol etmeye çalışırsanız, çalışmıyor olacaktır; bu da önyükleme sırasında otomatik olarak başlamadığı anlamına gelir.

Şimdi şu komutu kullanarak servisi tekrar etkinleştirin:

Çıktı bir sembolik bağ (symlink) gösterecektir. Sunucunuzu yeniden başlatırsanız, MySQL otomatik olarak başlamalıdır. Bir Systemd servisini etkinleştirmek, varsayılan hedefin (target) wants dizininde sembolik bir bağ oluşturur. Bir Systemd servisini devre dışı bırakmak ise sembolik bağı wants dizininden kaldırır.

Adım 5: Bir Servis Çökmesinden Sonra MySQL Servisi Başlangıç Davranışını Test Etme

Varsayılan olarak, MySQL servisi çökmesi durumunda otomatik olarak yeniden başlayacaktır. Bu davranışı MySQL için Systemd yapılandırma dosyasında devre dışı bırakabiliriz. İlk olarak dosyaya bir göz atalım. Dosyayı açmak için aşağıdaki komutu girin:

Aşağıdaki ekran görüntüsü çıktıyı göstermektedir:

Restart yönergesinin değeri on-failure olarak ayarlanmıştır. Bu, MySQL servisinin temiz olmayan çıkış kodları, zaman aşımı veya temiz olmayan sinyallerden sonra yeniden başlayacağı anlamına gelir. Aşağıda, man sayfasındaki.

Yeniden başlatma ayarları/Çıkış nedenleri	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
Temiz çıkış kodu veya sinyali		X	X
Temiz olmayan çıkış kodu		X		X
Temiz olmayan sinyal		X		X	X	X
Zaman Aşımı		X		X	X
Watchdog		X		X	X		X

Bir Systemd birim dosyasındaki iki önemli yönerge Restart ve RestartSec yönergeleridir. Bunlar servisin çökme davranışını kontrol eder. Restart servisin ne zaman yeniden başlatılması gerektiğini belirtirken, RestartSec bir çökmeden sonra yeniden başlatılmadan önce ne kadar beklemesi gerektiğini belirtir. Yeniden başlatma davranışını devre dışı bırakmak için, gösterildiği gibi satırın başına bir # ekleyerek Restart yönergesini yorum satırı yapın:

Şimdi, sistem daemon'ını yeniden yükleyin, ardından aşağıdaki komutları kullanarak mysqld servisini yeniden başlatın:

Ardından, MySQL servisinin Ana PID'sini (Main PID) bulmak için aşağıdaki komutu çalıştırın:

Testimiz için Ana PID 23809 idi. Bir sonraki komutta kullanmak üzere kendinizinkini not edin. kill -9 komutunu kullanarak, süreci sonlandırıp bir çökme simüle edin. Ayrıca, bunu kendi testinizde elde ettiğiniz süreç numarasıyla değiştirmeyi unutmayın:

MySQL durumunu kontrol eden komutu çalıştırırsanız, aktif olmadığını ve yeniden başlatılamadığını göreceksiniz:

Restart yönergesi mysqld.service yapılandırma dosyasında yorum satırı olarak kaldığı sürece başarısız (failed) durumda kalacaktır. Bu, bir servisin durduğu ve tekrar çalışmadığı bir çökmeyi simüle eder.

Servisi tekrar etkinleştirmek için mysqld.service yapılandırma dosyasını düzenleyebilir, Restart yönergesinin başındaki yorum işaretini kaldırabilir, ardından kaydedip kapatabilirsiniz. Daha önce yaptığınız gibi, daemon'ı yeniden yükleyin ve servisi yeniden başlatın. Bu, servisi ilk yapılandırmasına geri döndürür ve artık bir çökmeden sonra otomatik olarak başlayabilir. Son olarak, bir servisi çökmeden sonra otomatik başlayacak şekilde yapılandırmak için yapılması gerekenler bu kadar. Servisleri bir çökmeden sonra otomatik başlayacak şekilde yapılandırmak istiyorsanız, Restart yönergesini (ve isterseniz RestartSec yönergesini de), servis birim dosyasının [Service] bölümünün altına eklemeniz yeterlidir.

Sonuç

Bu eğitimde, Linux'un başlangıç sırasında veya bir çökmeden sonra servisleri nasıl yönettiğini ele aldık. Linux Sistem başlatma sürecini anlamak için Linux'un kullandığı üç init sistemini tartıştık: System V, Upstart ve Systemd. Bunların gelişimini ve her bir init sürecinin, bir sistem yeniden başlatıldıktan veya çöktükten sonra bir servisi otomatik olarak başlatma ile ilişkili olarak nasıl çalıştığını ele aldık.

Hem init daemon'ları hem de Linux dağıtımları zaman içinde geliştiğinden, sisteminizin yerel olarak hangi init daemon'ını desteklediğini öğrenmek için çalıştırdığınız Linux dağıtımının sürümünü kontrol etmeyi unutmayın.

Yerel Linux uygulamaları ve çoğu üçüncü taraf uygulama, sistem önyüklemesinden veya çökmesinden sonra zaten otomatik olarak başlar, bu nedenle hiçbir şey yapmanıza gerek kalmaz. Bu eğitimdeki bilgiler, kendi özel hizmetlerinizin başlangıç ve yeniden başlatılma (respawn) davranışını yapılandırırken veya sürekli çöken hizmetlerde sorun giderirken çok önemlidir.

Keyifli bilişimler!