"Ubuntu Linux" Sisteminin Derin İçgörüleri - Bunu Görüyor Muyuz?


LINUX, bildiğimiz gibi bir işletim sistemi değil, bir çekirdektir ve aşağıdakiler gibi çeşitli dağıtımlarla birlikte gelir: Debian, Fedora, Ubuntu güçlü> vb. ve çok daha fazlası. Mark Shuttleworth tarafından geliştirilen Ubuntu işletim sistemi, birçok kişi tarafından popüler olarak bilinmekte ve yaygın olarak kullanılmaktadır. Ayrıca ücretsiz ve Açık Kaynak olması nedeniyle, geliştirilmesine katkıda bulunan binlerce geliştiricinin katkıda bulunduğu yeni sürümü her yıl yayınlanmaktadır. Peki nasıl çalışıyor? Hangi süreçler, olaylar listesi onu çalıştırıyor ve bu süreçlerin önemi nedir?

Bu makale sizi Ubuntu OS'nin çok ilginç iç kısımlarına biraz derinlemesine götürecek ve bir aceminin onun işleyişini tam olarak anlamasına yardımcı olacaktır.

Sistemin Yerleştirilmesi

Linux'un işleyişi için bir süreci vardır; güç yönetimi, önyükleme, sistem çökmesi yönetimi dahil her sistem hizmeti, "/etc/init" içinde hangi olayı açıklayan bir yapılandırma dosyasına sahip bir süreçtir. yürütülecek ve yürütülmesini durduracağı ilgili olay, ayrıca çalışma zamanı davranışını tanımlayan diğer yapılandırma dosyalarını sistemin “/etc/” dizininde tutar, böylece sistem olaya dayalı bir olay.

Ortaya çıkan olaylar varsa, bunları yakalayıp yürütecek birisinin orada olması gerekir mi? Açıkçası denetleyici, 1 işlem kimliğine (yani init) sahip tüm süreçlerin ebeveyni olarak var olan ana sürecimizdir. Bu, sistemin devreye girmesiyle başlayan ve asla durmayan bir süreçtir. Bu süreç ancak sistem kapatıldığında ölür, çünkü init'in ebeveyni olan bir süreç yoktur.

6.10'dan önceki Ubuntu sürümleri, “/etc/rcx.d dosyasındaki komut dosyalarını çalıştırmak için kullanılan eski stil sysvinit'i içeriyordu. b> ”dizini sistemin her açılışında ve kapanışında. Ancak bundan sonra upstart sistemi eski tarz sysvinit sisteminin yerini aldı, ancak yine de ona geriye dönük uyumluluk sağlıyor.

En son Ubuntu sürümleri bu başlangıç sistemine sahiptir, ancak Ubuntu 6.10'dan evrimleşmesinden bu yana birçok revizyona tabi tutulmuştur ve mevcut sürüm 4 Eylül 2014'teki 1.13.2 olmuştur. En yeni başlangıç sistemi 2 init işlemi vardır; biri sistem işlemleri için, diğeri ise mevcut oturum açmış kullanıcı oturumunu yönetir ve yalnızca kullanıcı oturum açana kadar var olur; ayrıca x-session init olarak da adlandırılır .

Tüm sistem, sistemin güçlenmesinden kapanmasına kadar ata-çocuk ilişkisinden oluşan hiyerarşik bir sistem olarak kurgulanmıştır.

Örneğin: Her iki başlatma işlemi arasındaki küçük hiyerarşik ilişki şöyledir: system init(1) -> görüntü yöneticisi(çekirdek alanı) -> görüntü yöneticisi(kullanıcı alanı) -> kullanıcı init(veya x-session init).

System init tarafından yönetilen işlemler için yapılandırma dosyaları "/etc/init " konumunda bulunur ve session init tarafından yönetilen işlemler için yapılandırma dosyaları "/usr/share/upstart " içinde bulunur (olduğu gibi) 1.12'nin üzerindeki mevcut başlangıç sürümlerine göre) ve bu yapılandırma dosyaları, bu makalede açıklanan işlemlerle ilgili ortaya çıkarılan birçok sırrın anahtarıdır.

Hiyerarşinin Daha Derinlerine İnmek

Ubuntu iki tür işlemi tanır:

  1. Kısa ömürlü işler (ya da çalış ve öl işleri).
  2. Uzun ömürlü işler (ya da kal ve çalış işleri).

Sistem üzerinde oluşturulan hiyerarşi, süreçlerin konfigürasyon dosyalarını inceleyerek anlayabileceğimiz, süreçler arasındaki bağımlılık ilişkisinden kaynaklanmaktadır. Öncelikle sistemin başlatılmasını sağlayan süreçler arasındaki basit hiyerarşik ilişkiden başlayalım ve her birinin önemini anlayalım.

Önyükleme Hiyerarşisi

Init, sistem açıldığında başlayan ilk süreçtir ve hiçbir zaman sonlandırılmadığından ve yalnızca init'in öldürüldüğü zaman açık olduğundan çalış ve kal işi altında sınıflandırılır. kapatma, yani init yalnızca ölür ve bu da oturum başına bir kez ve bu da gücün kapatılmasıyla olur. Başlatma sırasında init, sistemdeki ilk olayı, yani başlangıç olayını oluşturur. “/etc/init” dosyasındaki her konfigürasyon dosyasında, sürecin başlamasına ve durmasına neden olan olayı tanımlayan iki satır bulunur. Bu çizgiler aşağıdaki şekilde vurgulandığı gibidir:

Bu, failsafe-x işleminin bir yapılandırma dosyasıdır ve bu başlama ve durma koşulları, sürecin başlayacağı olayı tanımlar. Başlangıç olayının init işlemi tarafından oluşturulmasında, başlangıç koşulu olarak başlatmaya sahip olan işlemler paralel olarak yürütülür ve bu yalnızca hiyerarşiyi tanımlar ve başlangıçta yürütülen tüm işlemler init'in çocuklarıdır.

Başlangıçta başlayan süreçler aşağıdaki gibi listelenmiştir ve bunların hepsi çalış-öl işidir:

1. ana bilgisayar adı – Bu, sisteme yalnızca /etc/hostname dosyasında tanımlanan ana bilgisayar adını söyleyen bir işlemdir.

2. kmod – Çekirdek modüllerini, yani tüm sürücüleri /etc/modules dosyasından yükler.

3. mountall – Bu işlem çok sayıda olay üretir ve esas olarak yerel dosya sistemleri ve uzak dosya sistemleri de dahil olmak üzere tüm dosya sistemlerinin önyükleme sırasında bağlanmasından sorumludur.

/proc dosyası da bu işlemle bağlanır ve tüm montaj işlerinden sonra onun tarafından oluşturulan son olay, hiyerarşinin daha da ilerlemesini sağlayan dosya sistemleri olayıdır.

4. plymouth – Bu işlem mountall başlatıldığında yürütülür ve sistem başlangıcında görülen siyah ekranın aşağıdaki gibi gösterilmesinden sorumludur:

5. plymouth için hazır – Plymouth'un hazır olduğunu gösterir.

Aşağıda ana işlemler yer almaktadır ve başlangıçta yürütülen diğer işlemler arasında udev-fallback-graphics vb. yer alır. Önyükleme hiyerarşisine geri dönecek olursak, özetle aşağıdaki olaylar ve süreçler sırayla aşağıdaki gibidir:

1. init ve başlangıç olayının oluşturulması.

2. mountall dosya sistemlerini monte etme, plymouth (mountall'ı başlatmayla birlikte) açılış ekranını görüntüleme ve kmod çekirdek modüllerini yükleme.

3. Mountall tarafından oluşturulan ve dbus'un çalışmasına neden olan local-filesystem olayı. (Dbus, diğer süreçlerin bu sokete mesaj göndererek birbirleriyle iletişim kurmasını sağlayan bir soket oluşturan sistem çapındaki mesaj veriyoludur ve alıcı bu soketteki mesajları dinler ve kendisine yönelik olanları filtreler).

4. yerel dosya sistemi ile birlikte, yerel dosya sistemi olayı üzerinde çalışan işlem ağının neden olduğu başlatılan dbus ve statik ağ bağlantısı olayı, ağ yöneticisinin çalışmasına neden olur.

5. mountall tarafından oluşturulan virtual-filesystem olayı udev'in çalışmasına neden olur. (udev, aygıtların çalışırken takılmasını yöneten linux için aygıt yöneticisidir ve /dev dizininde dosyalar oluşturmaktan ve bunları yönetmekten de sorumludur.) udev, mountall'ın sanal kurulumunu bitirdiği /dev dizininde ram, rom vb. için dosyalar oluşturur. -filesystems ve /dev dizininin bağlanmasını gösteren sanal dosya sistemi olayını oluşturdu.

6. udev, yerel ağın çalışır durumda olduğunu belirten upstart-udev-bridge'in çalışmasına neden olur. Daha sonra mountall son dosya sisteminin montajını tamamladıktan ve dosya sistemi olayını oluşturduktan sonra.

7. filesystem olayı ve static-network-up olayı rc-sysinit işinin çalıştırılmasına neden olur. İşte eski sysvinit ile yeni başlayan arasındaki geriye dönük uyumluluk geliyor…

9. rc-sysinit, sistemin çalışma seviyesini bildiren telinit komutunu çalıştırır.

10. Çalışma seviyesini aldıktan sonra init, 'S' veya 'K' ile başlayan komut dosyalarını çalıştırır (içinde 'S' bulunan işleri başlatır). /etc/rcX.d dizininde (burada 'X' geçerli çalışma düzeyidir) adlarının başlangıcı ve adının başında 'K' olanlar öldürülür) .

Bu küçük olaylar dizisi, sistemi her açtığınızda sistemin başlatılmasına neden olur. Ve süreçlerin bu olay tetiklemesi hiyerarşinin yaratılmasından sorumlu olan tek şeydir.

Şimdi yukarıdakilere bir eklenti daha olayın nedenidir. Hangi işlemin hangi olaya neden olduğu, aşağıda bu satırlarda gösterildiği gibi işlemin aynı yapılandırma dosyasında da belirtilir:

Yukarıda süreç mountall'un yapılandırma dosyasının bir bölümü bulunmaktadır. Bu, yaydığı olayları gösterir. Etkinliğin adı 'etkinlik' kelimesinin ardından gelen addır. Olay, yukarıdaki gibi yapılandırma dosyasında tanımlanan olay olabilir veya 'başlıyor', 'başladı', 'durduruldu' veya 'durduruldu' önekiyle birlikte sürecin adı olabilir.

Yani burada iki terimi tanımlıyoruz:

  1. Olay Oluşturucu: Yapılandırma dosyasında 'xxx yayar' satırı bulunan, burada xxx, sahip olduğu veya oluşturduğu olayın adıdır.
  2. Olay Yakalayıcı: xxx olarak başlama veya durma koşuluna sahip olan veya Olay oluşturuculardan birini oluşturan olay üzerinde başlayan veya duran.

Böylece hiyerarşi ve dolayısıyla süreçler arasındaki bağımlılık şöyle olur:

Event generator (parent) -> Event catcher (child)

Hiyerarşiye Karmaşıklık Ekleme

Şimdiye kadar, işlemler arasındaki ebeveyn-çocuk bağımlılığı hiyerarşisinin, basit bir başlatma mekanizması aracılığıyla olay tetikleme mekanizması tarafından nasıl oluşturulduğunu anlamış olmalısınız.

Bu hiyerarşi hiçbir zaman bir çocuğun yalnızca bir ebeveyne sahip olduğu birebir bir ilişki değildir. Bu hiyerarşide bir çocuk için bir veya daha fazla ebeveynimiz olabilir veya bir süreç birden fazla çocuğun ebeveyni olabilir. Bu nasıl başarılır? Cevap konfigürasyon dosyalarının kendisinde yatıyor.

Bu satırlar süreçten alınmıştır - ağ oluşturma ve burada başlatma koşulu, pek çok olaydan oluşan biraz fazla karmaşık görünüyor: yerel dosya sistemleri, udevtrigger, konteyner, çalışma düzeyi, ağ iletişimi.

Local-filesystems mountall tarafından yayınlanır, udevtrigger işin adıdır, konteyner olayı konteyner-detect tarafından yayılır, çalışma seviyesi olayı rc-sysinit tarafından yayılır ve ağ oluşturma yine bir iştir.

Bu nedenle, bir hiyerarşide süreç ağı, işleyişini sürdüremediği için mountall, udevtrigger ve Container-detect'in alt öğesidir (sürecin işleyişi, sürecin yapılandırma dosyasındaki script veya exec bölümleri altında tanımlanan tüm satırlardır) yukarıdaki işlemler kendi etkinliklerini oluşturana kadar.
Benzer şekilde, bir süreç tarafından oluşturulan olay birçok kişi tarafından önbelleğe alınırsa, bir sürecin birçok sürecin ebeveyni olmasını sağlayabiliriz.

İş Türlerini Ayırt Etmek

Daha önce tanımlandığı gibi, ya kısa ömürlü (ya da çalış ve öl işler) ya da uzun ömürlü (ya da kal ve çalış) işlere sahip olabiliriz, ancak bunları nasıl ayırt edebiliriz? onlara??

Yapılandırma dosyalarında hem 'başlangıç' hem de 'durma' koşulları belirtilen ve 'görev' sözcüğünü içeren işler yapılandırma dosyası, oluşturulan olayda başlayan, kendi komut dosyasını veya exec bölümünü yürüten (yürütülürken, onlara neden olan olayları engeller) ve daha sonra engelledikleri olayları serbest bırakarak ölen çalış ve öl işleridir .

Yapılandırma dosyasında "dur ve çalış" koşulu bulunmayan işler uzun ömürlü veya kal ve çalış işleridir ve asla ölmezler. Artık kal ve çalış işleri şu şekilde daha ayrıntılı olarak sınıflandırılabilir:

  1. Yeniden doğma durumu olmayan ve root kullanıcı tarafından öldürülebilenler.
  2. Yapılandırma dosyasında yeniden doğma koşulu bulunanlar ve bu nedenle işleri tamamlanmadıkça öldürüldükten sonra yeniden başlarlar.

Çözüm

Dolayısıyla, LINUX'taki her süreç bazılarına bağımlıdır ve ona bağlı bazı süreçlere sahiptir ve bu ilişki çok sayıdadır ve sürecin diğer ayrıntılarıyla birlikte yeni başlayan sistemle belirlenir.