Linux `htop`/`top` ekranında görülen değerlerin açıklaması (2019)

 (peteris.rocks)
1 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Ubuntu Server 16.04 x64 üzerindeki htop ekranını çıkış noktası alarak uptime, load average, Tasks, PID, süreç ağacı, durum, CPU zamanı, öncelik ve bellek göstergelerinin gerçekte ne anlama geldiği /proc ve komut çıktıları üzerinden izleniyor
  • Ekrandaki birçok değer procfs ve /etc/passwd, /etc/group, /etc/shadow, /etc/nsswitch.conf gibi sistem dosyalarından gelir; strace ile programın hangi dosyaları okuduğu doğrulanabilir
  • Load average, CPU kullanım oranıyla aynı şey değildir; çalışan, çalışmayı bekleyen ve uninterruptible durumdaki süreçleri içeren üstel sönümlü hareketli ortalamadır
  • R, S, D, Z, T, t gibi durum kodları signal, kill, fork/exec/wait davranışlarıyla bağlantılıdır; bu yüzden bir sürecin neden durduğu ya da neden sistemde kaldığına dair ipucu verir
  • VIRT, RES, SHR, MEM%, sanal bellek, fiziksel bellek ve paylaşılabilir belleği farklı açılardan gösterir; bu nedenle tek bir sayıya bakarak gerçek bellek kullanımını kesin olarak söylemek zordur

htop değerleri nereden gelir?

  • uptime, sistemin ne kadar süredir çalıştığını gösterir; aynı bilgi uptime komutuyla da görülebilir
  • uptime programı /proc/uptime dosyasını okur
    • İlk sayı, sistemin açık kaldığı toplam süreyi saniye cinsinden gösterir
    • İkinci sayı, sistemin idle durumda kaldığı süreyi saniye cinsinden gösterir
    • Çok çekirdekli sistemlerde idle süresi çekirdek bazında toplandığı için toplam uptime'dan büyük olabilir
  • strace uptime 2>&1 | grep open veya strace -e open uptime ile uptime komutunun açtığı dosyalar görülebilir
    • Örnek çıktıda /proc/uptime, /var/run/utmp, /proc/loadavg yer alır
  • /proc/uptime içindeki sayılar programlar veya betikler için uygundur; uptime çıktısı ise insanlar için daha okunaklı biçimde formatlanır

Load average ve CPU kullanım oranı

  • /proc/loadavg içindeki ilk üç değer, son 1 dakika, 5 dakika, 15 dakika için sistem load average'ını gösterir
  • Dördüncü değer, o anda çalışan süreç sayısı ile toplam süreç sayısını 1/120 gibi gösterir; son değer ise en son kullanılan PID'dir
  • Yeni bir süreç çalıştırıldığında bir PID atanır; PID genelde artar, tükendiğinde ise yeniden kullanılabilir
    • PID 1, önyükleme sırasında başlatılan /sbin/init sürecine aittir
  • htop içinde yalnızca bir çalışan süreç görünüyorsa bu süreç htop'un kendisi olabilir
  • sleep 30, çalışan durumda değil uyku durumunda olduğu için running process sayısını artırmaz
  • cat /dev/urandom > /dev/null gibi sürekli CPU kullanan işler, çalışan süreç sayısını ve load average'ı artırır
  • Load number, çalışan, çalışmayı bekleyen ve uninterruptible durumdaki süreçleri sayan değerdir
  • Load average basit bir ortalama değil, üstel sönümlü hareketli ortalamadır
    • 1 dakikalık load average bile yalnızca son 60 saniyeyi yansıtmaz; son 1 dakikaya daha fazla ağırlık verirken önceki etkinliğin bir kısmını da içerir
  • Tek CPU'lu bir sistemde CPU-bound bir süreç varsa, load average 1.00 değeri kabaca CPU'nun %100 kullanımı olarak düşünülebilir
    • 2 çekirdekli bir sistemde aynı durum CPU kullanımının %50'si olarak görülebilir
    • 2 çekirdekli sistemde CPU'nun %100 kullanımına karşılık gelen load average değeri kabaca 2.00 sayılabilir
  • Bu basitleştirme her zaman doğru değildir; çünkü uninterruptible durumdaki süreçler de load'a dahildir
    • CPU kullanım oranı yüksek değilken load average'ın yüksek olduğu durumlar mümkündür
  • Anlık CPU kullanım oranı mpstat ile kontrol edilebilir
    • sudo apt install sysstat -y
    • mpstat 1

Tasks, PID, süreç ağacı

  • htop ekranının sağ üstündeki Tasks, toplam süreç sayısını ve çalışan süreç sayısını gösterir
  • Linux çekirdeği dahili olarak süreçlere task der; htop da ekranda yer kazanmak için Processes yerine Tasks kullanır
  • Shift+H ile thread gösterimi açılıp kapatılabilir
    • Tasks: 23, 10 thr şeklinde görünüyorsa thread'ler gösteriliyordur
  • Shift+K ile kernel thread gösterimi açılıp kapatılabilir
    • Tasks: 23, 40 kthr şeklinde görünüyorsa kernel thread'ler gösteriliyordur
  • Her yeni süreç başlatıldığında bir PID atanır
    • sleep 1000 & gibi arka planda çalıştırılırsa job numarası ve PID gösterilir
    • bash içindeki $!, son arka plan süreç kimliğine genişletilir
  • Süreçle ilgili bilgiler /proc/<pid>/ altında bulunur
    • /proc/<pid>/cmdline, çalıştırma komutunu içerir ve argümanlar \0 baytlarıyla ayrılır
    • tr '\0' '\n' < /proc/<pid>/cmdline veya strings /proc/<pid>/cmdline ile daha okunaklı biçimde görülebilir
    • /proc/<pid>/cwd, mevcut çalışma dizinine giden bağlantıdır; /proc/<pid>/exe ise çalıştırılan binary'ye giden bağlantıdır
  • htop, top, ps gibi tanılama araçları süreç ayrıntılarını /proc/<pid>/<file> içinden okur
  • Yeni süreci oluşturan taraf parent process, oluşturulan yeni taraf child process olarak adlandırılır; bu ilişki süreç ağacını oluşturur
  • htop içinde F5 tuşuna basıldığında süreç hiyerarşisi görülebilir
    • ps f ve pstree -a da aynı ilişkiyi gösterir
  • bash içinde date çalıştırıldığında bash, fork ile kendi kopyasını oluşturur; ardından exec ile /bin/date belleğe yüklenir ve parent olan bash, child sürecin bitmesini bekler
  • /sbin/init, önyükleme sırasında başlatılır ve sshd'yi ayağa kaldırır; SSH bağlantısı kurulduğunda sshd bir oturum süreci oluşturur ve bu oturum da bash shell'ini çalıştırır

Süreç kullanıcıları ve yetkiler

  • Her süreç bir kullanıcıya aittir ve kullanıcı sayısal bir ID ile ifade edilir
  • Sürecin kullanıcı ID’si /proc/<pid>/status içindeki Uid alanından görülebilir
  • id 1000 gibi komutlar, sayısal ID’ye karşılık gelen kullanıcı adını ve grubu gösterir
  • id, /etc/nsswitch.conf ayarına göre ad çözümleme kaynağını seçer
    • Örnek sistemde /etc/passwd ve /etc/group dosyalarını okur
    • compat, Compatibility mode’dur; files ile aynıdır ama özel girdilere izin verir
    • Kullanıcı bilgileri LDAP gibi başka veritabanlarında veya servislerde de tutulabilir
  • /etc/passwd ve /etc/group, sayısal ID’leri insanların okuyabileceği adlarla eşleyen düz metin dosyalarıdır
  • Gerçek parola bilgisi /etc/shadow içindedir
    • $6$, sha512 hash algoritmasını ifade eder
    • Ardından rainbow table saldırılarını önlemek için rastgele bir salt ile password+salt hash’i gelir
  • Programlar varsayılan olarak onları çalıştıran kullanıcının yetkileriyle çalışır
    • Çalıştırılabilir dosyanın sahibi başka bir kullanıcı olsa bile durum aynıdır
  • Başka bir kullanıcı veya root olarak çalıştırmak için sudo kullanılır
    • sudo id, rootun UID 0’ı ile çalışır
    • sudo -u daemon id gibi belirli bir kullanıcı olarak çalıştırılabilir
  • /etc/sudoers dosyasına doğrudan redirect ile yazmaya çalışırsanız yalnızca echo root olarak çalışır, append işlemi ise mevcut kullanıcıyla yapılacağı için başarısız olabilir
    • echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers
    • sudo bash -c "echo '$USER ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers"
  • /etc/sudoers, sudo visudo ile düzenlenmelidir
    • Kaydetmeden önce içeriği doğrulayarak sudo kullanılamaz hale gelme hatasını önler
  • /usr/bin/passwd, normal kullanıcı tarafından çalıştırılsa bile /etc/shadow dosyasına yazabilir
    • Dosya izinlerinde s bulunduğu için bir setuid çalıştırılabilir dosya olarak davranır
    • Çalıştırılabilir dosyanın sahibi olan root yetkileriyle çalışır
    • root sahibi setuid çalıştırılabilir dosyalar find /bin -user root -perm -u+s ile bulunabilir

Süreç durum kodları

  • htop içindeki durum sütunu S adıyla gösterilir ve başlıca değerler şunlardır
    • R: running veya runnable, çalışıyor ya da run queue’da bekliyor
    • S: interruptible sleep, bir olayın tamamlanmasını bekliyor
    • D: uninterruptible sleep, genellikle I/O bekliyor
    • Z: defunct zombie, sonlanmış ama parent tarafından reap edilmemiş
    • T: job control signal ile durdurulmuş
    • t: tracing sırasında debugger tarafından durdurulmuş
    • X: dead, görünmemesi gereken durum
  • ps, Ss, R+, Ss+ gibi alt durumları da gösterir

  • R: Çalışıyor veya çalıştırılabilir

    • R durumu, sürecin şu anda çalıştığı ya da çalıştırma kuyruğunda beklediği anlamına gelir
    • Program kaynak kodu derlendikten sonra CPU komutlarına dönüşür; çalıştırıldığında belleğe yüklenir ve CPU bu komutları yürütür
    • Çalışıyor olmak, CPU’nun fiziksel olarak komutları yürüttüğü anlamına gelir

  • S: Kesilebilir sleep

    • S durumunda süreç komutları CPU üzerinde çalışmaz, bir olay veya koşulu bekler
    • Olay gerçekleştiğinde kernel durumu running olarak değiştirir
    • sleep 1000, belirtilen süre boyunca beklemeye bir örnektir
    • Bu durum signal ile interrupt edilebilir
    • htop içinde F9 tuşuna basarak signal gönderebilirsiniz
    • kill, signal gönderen sistem çağrısıdır; /bin/kill ise userland’de bunu çağıran programdır
    • Varsayılan signal TERM’dür ve sürecin sonlanmasını ister
    • Signal’ler sayısaldır; adları genelde büyük harfle yazılır ve başına SIG öneki gelebilir
    • Örnek: INT, KILL, STOP, CONT, HUP
    • kill -INT 10089, kill -2 10089, /bin/kill -2 10089 aynı işlemi yapar
    • CTRL+C tuşlarına bastığınızda bash, foreground process’e SIGINT gönderir
    • SIGINT veya SIGTERM göndermek, sürecin mutlaka sonlanacağı anlamına gelmez
    • Program, signal handler tanımlayarak temizlik işlemlerinden sonra sonlanacak şekilde bunu ele alabilir
    • SIGKILL veya 9, kernelin süreci yanıt verme fırsatı tanımadan zorla sonlandırmasına neden olur

  • D: Kesilemeyen sleep

    • D durumu signal ile uyandırılamaz; SIGKILL de bir signal olduğu için bu tür süreçler kill edilemez
    • Bu durum, sürecin kesintisiz beklemesi gerektiğinde veya olayın hızlı gerçekleşmesinin beklendiği durumlarda kullanılır
    • Örnek: disk read/write
    • Uninterruptible süreç, çoğu zaman bir page fault sonrasında I/O bekliyor olabilir
    • NFS read/write gecikmeleri bu duruma yol açabilir
    • Kullanılabilir belleğin çok az olduğu ve sürecin yoğun swap yaptığı durumlarda da görülebilir
    • Örnek olarak sudo mount 8.8.8.8:/tmp /tmp & çalıştırılırsa /sbin/mount.nfs D durumuna geçer
    • strace ile bakıldığında mount sistem çağrısının süreci block ettiği görülür
    • mount komutuna intr seçeneği verilirse interruptible olarak çalıştırılabilir
    • sudo mount 8.8.8.8:/tmp /tmp -o intr

  • Z: Zombi süreç

    • Z durumu, süreç sonlanmış ama parent henüz onu reap etmemiş demektir
    • Zombi süreçler kısa süreli kalıyorsa bu normal olabilir
    • Uzun süre kalan zombi süreçler programdaki bir hataya işaret edebilir
    • Zombi süreç bellek tüketmez, yalnızca PID işgal eder
    • Zombi sürecin kendisi kill edilemez
    • Zombiyi reap etmesi için parent process’e SIGCHLD gönderilebilir
    • Parent process kill edilirse hem parent hem de zombisi kaldırılabilir
    • fork sonrasında child’ın exit(0) yaptığı ve parent’ın sleep(20) çağırdığı bir C programı ile zombi durumu yeniden üretilebilir
    • Parent sonlandığında zombi de kaybolur
    • Zombinin tutulmasının nedeni, parent’ın wait sistem çağrısı ile child’ın exit code’unu kontrol edebilmesidir

  • T ve t: Durdurulmuş süreçler

    • T durumu, job control signal ile durdurulmuş durumu ifade eder
    • cat /dev/urandom > /dev/null çalışırken CTRL+Z tuşlarına basılırsa T durumuna geçer
    • fg ile yeniden çalıştırılabilir
    • STOP signal ile durdurulup CONT signal ile devam ettirilebilir
    • t durumu, debugger tracing yaptığı sırada durdurulmuş durumu ifade eder
    • nc -l 1234 & ile başlatılan bir sürece sudo gdb -p <pid> ile attach edilirse t durumuna geçer

CPU süresi, niceness, priority

  • Linux bir multitasking işletim sistemi olduğu için tek bir CPU üzerinde bile birden fazla süreç aynı anda çalışıyormuş gibi görünür
  • Gerçekte tek bir CPU aynı anda yalnızca bir komut çalıştırabildiğinden time sharing kullanılır
    • Bir süreç kısa bir süre çalışır ve durdurulur
    • Çalıştırılmayı bekleyen diğer süreçler sırayla çalıştırılır
    • Bir sürecin çalıştığı bu kısa aralığa time slice denir
  • Time slice genellikle birkaç milisaniyedir; bu yüzden sistem load'u yüksek değilse fark edilmesi zordur
  • Tek çekirdekte load average 1.0 ise CPU'nun %100 kullanıldığı söylenebilir
    • 1.0'dan yüksekse çalışmak isteyen süreç sayısı CPU'nun işleyebileceği sayıdan fazladır; bu da slowdown veya delay yaratabilir
    • 1.0'dan düşükse CPU zaman zaman idle durumdadır
  • Süreç running time'ının gerçek geçen süreyle tam olarak aynı olmamasının nedeni de time sharing ile açıklanır
  • Çalıştırılacak task sayısı kullanılabilir CPU core sayısından fazlaysa hangi task'ın önce çalıştırılacağına karar vermek gerekir
  • Linux çekirdeğinin scheduler'ı run queue içinden bir sonraki süreci seçer ve bu, çekirdeğin scheduler algoritmasına bağlıdır
  • Genelde scheduler'ı doğrudan kontrol edemezsiniz, ancak hangi sürecin daha önemli olduğunu belirtebilirsiniz
  • NI ile gösterilen niceness, user-space priority'dir
    • Aralığı -20 ile 19 arasındadır
    • -20 en yüksek öncelik, 19 ise en düşük önceliktir
    • Daha nice olan bir süreç, daha az nice olan süreçlere daha fazla yol veriyor gibi düşünülebilir
  • PRI, Linux çekirdeğinin kullandığı kernel-space priority'dir
    • Aralığı 0 ile 139 arasındadır
    • 0~99 real time, 100~139 ise user alanı içindir
  • Nice değeri ile priority arasındaki ilişki PR = 20 + NI şeklinde açıklanır
    • NI için -20~+19 aralığı, PR için 0~39 olur ve bu da 100~139 aralığına eşlenir
  • Çalıştırmadan önce niceness, nice -n niceness program ile ayarlanır
  • Çalışan bir sürecin niceness değeri renice -n niceness -p PID ile değiştirilir
  • CPU kullanım oranı renkleri şöyledir
    • Mavi: düşük öncelikli thread, nice > 0
    • Yeşil: normal öncelikli thread
    • Kırmızı: kernel thread

Bellek metrikleri: VIRT, RES, SHR, MEM%

  • Bir süreç, bellekte tek başınaymış gibi görünür; bu, sanal bellek ile sağlanır
  • Süreç fiziksel belleğe doğrudan erişmez, onun yerine kendi virtual address space'ine sahiptir
  • Çekirdek, virtual memory address'lerini physical memory'ye dönüştürebilir veya bunların bir kısmını disk'e eşleyebilir
  • Bu nedenle bir sürecin, bilgisayarda takılı olandan daha fazla bellek kullanıyormuş gibi görünmesi mümkündür
  • Süreç bellek kullanımı, aşağıdaki kalemlerin dahil edilip edilmemesine göre değişir
    • shared library
    • disk-mapped memory
    • swapped out memory
  • Bellek kullanım renkleri şöyledir
    • Yeşil: kullanılan bellek
    • Mavi: buffers
    • Turuncu: cache

  • VIRT/VSZ

    • VIRT, task'ın kullandığı toplam virtual memory miktarıdır
    • code, data, shared library, swapped out page ve eşlenmiş ama kullanılmayan page'leri içerir
    • Uygulama 1GB isteyip yalnızca 1MB kullansa bile VIRT 1GB görünebilir
    • 1GB'lık bir dosya mmap ile eşlenip gerçekte hiç kullanılmasa da VIRT 1GB olarak görünebilir
    • Çoğu durumda VIRT faydalı bir sayı değildir

  • RES/RSS

    • RES, swapped out edilmemiş physical memory, yani şu anda fiziksel bellekte bulunan resident memory kullanım miktarıdır
    • RES, gerçek bellek kullanımını VIRT'ten daha iyi gösterebilir, ancak bunun da sınırları vardır
    • Swapped out edilmiş belleği içermez
    • Belleğin bir kısmı diğer süreçlerle paylaşılabilir
    • Bir süreç 1GB bellek kullandıktan sonra fork() ederse, iki sürecin RES değeri ayrı ayrı 1GB görünebilir; ancak Linux'un copy-on-write mekanizması nedeniyle gerçekte yalnızca 1GB kullanılıyor olabilir

  • SHR

    • SHR, task'ın kullandığı shared memory miktarıdır
    • Diğer süreçlerle potansiyel olarak paylaşılabilecek belleği yansıtır
    • Örnek C programı, malloc, belleğin bir kısmının kullanılması, fork ve ek bellek yazımı adımlarından geçerek VIRT, RES, SHR değerlerinin nasıl değiştiğini gösterir
    • İlgili bellek örneği bölümü TODO olarak bırakılmıştır

  • MEM%

    • MEM%, task'ın şu anda kullandığı available physical memory oranıdır
    • RES değerinin toplam RAM'e bölünmesiyle elde edilir
    • Örnek: RES 400M ve RAM 8GB ise 400/8192*100 = 4.88%

Ubuntu Server 16.04 varsayılan süreçleri

  • temiz bir Digital Ocean droplet’ındaki Ubuntu Server 16.04.1 LTS x64 üzerinde başlatılan süreçler incelenmiş

  • /sbin/init

    • /sbin/init, boot process’in geri kalanını koordine eder ve kullanıcı ortamını hazırlar
    • otomatik başlayan süreçlerin parent’ı veya grandparent’ı olur
    • dpkg -S /sbin/init sonucu systemd-sysv: /sbin/init çıktığı için, bu sistemde systemd kullanılır
    • kill edilse de hiçbir şey olmaz

  • /lib/systemd/systemd-journald

    • systemd-journald, logging data toplayıp saklayan bir system service’tir
    • çeşitli source’lardan gelen log bilgilerine dayanarak structured, indexed bir journal oluşturur ve sürdürür
    • basit düz metin log dosyaları yerine, log mesajları için optimize edilmiş özel bir dosya biçimi kullanır
    • journalctl ile görüntülenir
    • journalctl _COMM=sshd
    • journalctl _COMM=sshd -o json-pretty
    • journalctl --since yesterday
    • journalctl -b
    • journalctl -f
    • journalctl --disk-usage
    • journalctl --vacuum-size=1G
    • kaldırmak veya devre dışı bırakmak mümkün görünmüyor; yalnızca logging kapatılabiliyor

  • /sbin/lvmetad -f

    • lvmetad, LVM metadata’sını cache’leyerek LVM komutlarının disk scan yapmadan metadata okumasını sağlar
    • disk scan zaman alır ve sistemle diskin normal işlerini engelleyebilir
    • LVM, Linux çalışırken logical volume oluşturup yeniden boyutlandırabilen ve silebilen “dynamic partitions” olarak düşünülebilir
    • LVM kullanılıyorsa korunması gerektiği sonucuna varılmış

  • /lib/systemd/udevd

    • systemd-udevd, kernel uevent’lerini dinler ve her event için udev rules içindeki matching instruction’ları çalıştırır
    • udev, Linux kernel’in device manager’ıdır ve esas olarak /dev directory’sindeki device node’ları yönetir
    • virtual server’da gerekli olup olmadığı konusunda emin olunmamış

  • /lib/systemd/timesyncd

    • systemd-timesyncd, remote NTP server ile local system clock’u senkronize eden bir system service’tir
    • ntpd yerine geçer
    • örnek sistemde timedatectl status, network time ve NTP synchronized değerlerini yes olarak gösterir
    • netstat çıktısında yalnızca SSH portunun listening durumda olduğu görülür; Ubuntu 14.04’teki ntpd gibi birden fazla UDP 123 portu açmaz

  • /usr/sbin/atd -f

    • atd, daha sonra çalıştırılmak üzere queue’ya eklenen job’ları yürütür
    • at ve batch, komutları stdin’den veya dosyadan okuyup daha sonra çalıştırır
    • tekrar eden çalıştırmaları zamanlayan cron’un aksine, at belirli bir zamanda bir kez çalışır
    • örnekte echo "touch /tmp/yolo.txt" | at now + 1 minute ile 1 dakika sonra bir dosya oluşturulur
    • kullanılmıyorsa sudo apt remove at -y --purge ile kaldırılabilir

  • /usr/lib/snapd/snapd

    • Snappy Ubuntu Core, transactional update kullanan bir Ubuntu sürümü olarak tanıtılmış
    • snap, tek bir binary package’ın Linux desktop, server, cloud ve device ortamlarında çalışmasını sağlayan universal bir Linux package formatı olarak açıklanıyor
    • dependency’leri tek bir snap içinde toplayıp dağıtan sadeleştirilmiş bir deb paketi gibi düşünülebilir
    • sunucuda snappy ile uygulama deploy etme veya distribute etme deneyimi olmadığı için sudo apt remove snapd -y --purge ile kaldırılmış

  • /usr/bin/dbus-daemon

    • D-Bus, aynı machine üzerinde eşzamanlı çalışan birden çok process arasında IPC ve RPC sağlayan bir mechanism’dir
    • desktop environment için gereklidir ama web app çalıştıran bir server’da gerekip gerekmediği sorgulanmış
    • dbus kaldırılınca timedatectl status, Failed to create bus connection: No such file or directory hatasıyla başarısız olmuş
    • bu yüzden bırakmanın daha iyi olduğu sonucuna varılmış

  • /lib/systemd/systemd-logind

    • systemd-logind, user login’lerini yöneten bir system service’tir

  • /usr/sbin/cron -f

    • cron, scheduled command çalıştıran bir daemon’dur
    • -f, foreground mode anlamına gelir; daemonize etmez
    • periyodik çalıştırılacak işler cron ile zamanlanabilir
    • crontab -e
    • Ubuntu’da genellikle /etc/cron.hourly, /etc/cron.daily vb. kullanıldığı belirtilmiş
    • loglar şu şekilde görülebilir
    • grep cron /var/log/syslog
    • journalctl _COMM=cron
    • journalctl _COMM=cron --since="date" --until="date"
    • cron’un büyük olasılıkla tutulacağı belirtilmiş
    • kaldırılmayacaksa sudo systemctl stop cron, sudo systemctl disable cron ile durdurulup devre dışı bırakılabilir
    • apt remove cron, postfix vb. kurmaya çalışabilir
    • çünkü cron bir mail transport agent önerebilir

  • /usr/sbin/rsyslogd -n

    • rsyslogd, message logging desteği sağlayan bir system utility’dir
    • /var/log/auth.log gibi /var/log/ altındaki log dosyalarını doldurur
    • yapılandırma dosyaları /etc/rsyslog.d içindedir
    • loglar uzak bir sunucuya gönderilerek centralized logging kurulabilir
    • logger komutuyla arka plan script’lerinden /var/log/syslog içine mesaj yazılabilir
    • systemd-journald zaten bulunsa da rsyslog ile journal farklı özellikler sunduğundan birlikte kullanıldıkları senaryolar faydalı olabilir
    • bu yüzden şimdilik tutulmuş

  • /usr/sbin/acpid

    • acpid, bir ACPI event daemon’udur
    • user-space programlara ACPI event’lerini bildirmek için tasarlanmıştır
    • ACPI; hardware component discovery/configuration, power management ve status monitoring gibi işler için kullanılır
    • virtual server’da suspend/resume amaçlanmadığı için kaldırılmayı denenmiş
    • reboot başarılı olmuş ama halt sonrasında Digital Ocean sistemi hâlâ açık sanmış ve web arayüzünden Power Off yapmak gerekmiş
    • bu nedenle bırakmanın daha iyi olduğu sonucuna varılmış

  • /usr/bin/lxcfs /var/lib/lxcfs/

    • lxcfs, LXC container’ları için tasarlanmış bir FUSE filesystem’idir
    • /proc altındaki bazı dosyaların virtualized görünümünü ve host cgroup filesystem’ine filtrelenmiş erişim sağlar
    • container içinde uptime, top vb. daha “doğru” sonuçlar verir
    • LXC container kullanılmıyorsa sudo apt remove lxcfs -y --purge ile kaldırılabilir

  • /usr/lib/accountservice/accounts-daemon

    • AccountsService, user account bilgilerini query etmek ve değiştirmek için bir D-Bus interface’i ve bunun implementasyonunu sağlar
    • implementasyon, usermod(8), useradd(8), userdel(8) komutlarını temel alır

  • Kaldırıldıktan sonra neyin bozulacağı “Time will tell” olarak belirsiz bırakılmış

  • /sbin/mdadm

    • mdadm, software RAID aygıtlarını yöneten ve izleyen bir Linux aracıdır
    • RAID, birden çok hard drive’ı tek bir sürücü gibi kullanma yöntemidir
    • RAID 0, drive kapasitesini genişletir
    • RAID 1, RAID 5, RAID 6, RAID 10 ise drive arızası durumunda data loss’u önlemeyi amaçlar
    • sudo apt remove mdadm -y --purge ile kaldırılabilir

  • /usr/lib/policykit-1/polkitd --no-debug

    • polkitd, PolicyKit daemon’ıdır; polkit ise bir Authorization Framework’tür
    • fine-grained sudo gibi düşünülebilir
    • non-privileged user’a belirli action’ları root olarak yapma yetkisi verebilir
    • Örnek: desktop Linux’ta reboot izni vermek
    • server’da sudo apt remove policykit-1 -y --purge ile kaldırılabileceği belirtiliyor
    • Neyin bozulacağı ise hâlâ belirsiz

  • /usr/sbin/sshd -D

    • sshd, OpenSSH Daemon’ıdır
    • -D seçeneği, ayrılmadan çalışmasını ve daemon’a dönüşmemesini sağlar; bu da monitoring’i kolaylaştırır

  • /sbin/iscsid

    • iscsid, iSCSI configuration’a göre çalışan ve connection’ları yöneten bir background daemon’dır
    • iSCSI, IP tabanlı bir storage networking standard’ıdır; SCSI command’larını IP network üzerinden ileterek remote storage’ı local disk gibi kullanmayı sağlar
    • sudo apt remove open-iscsi -y --purge ile kaldırılabilir

  • /sbin/agetty --noclear tty1 linux

    • agetty, Linux için alternatif bir getty’dir
    • getty, physical veya virtual terminal’i yönetir; bağlantı algılandığında username prompt’unu gösterir ve ardından login programını çalıştırır
    • Digital Ocean’da droplet details içindeki Console üzerinden bu terminal ile tarayıcıda etkileşim kurulabilir
    • getty@tty1.service ile ilgili dosyalar kaldırılıp reboot edildiğinde SSH bağlantısı yapılabilmiş, ancak Digital Ocean web console üzerinden login olunamamış

  • SSH oturumu, bash, htop

    • sshd: root@pts/0, root kullanıcısının SSH session’ının pseudoterminal pts/0 üzerinde kurulduğu anlamına gelir
    • pseudoterminal, gerçek bir text terminal’i taklit eder
    • bash, kullanılan shell’dir
    • -bash gibi başında dash varsa bu, login shell olarak başlatıldığı anlamına gelir
    • argument zero’nun ilk karakteri - olan veya --login option’ı ile başlatılan shell, login shell’dir
    • Bu durumda farklı bir configuration file set’i okunur
    • htop, ekran görüntüsünde çalışmakta olan interactive process viewer’dır

Hizmet kaldırma deneyi

  • Genel kaldırma listesi şu şekildedir
    • sudo apt remove lvm2 -y --purge
    • sudo apt remove at -y --purge
    • sudo apt remove snapd -y --purge
    • sudo apt remove lxcfs -y --purge
    • sudo apt remove mdadm -y --purge
    • sudo apt remove open-iscsi -y --purge
    • sudo apt remove accountsservice -y --purge
    • sudo apt remove policykit-1 -y --purge
  • Extreme edition şu işlemleri içerir
    • sudo apt remove dbus -y --purge
    • sudo apt remove rsyslog -y --purge
    • sudo apt remove acpid -y --purge
    • sudo systemctl stop cron && sudo systemctl disable cron
    • sudo rm /etc/systemd/system/getty.target.wants/getty@tty1.service
    • sudo rm /lib/systemd/system/getty@.service
  • Ubuntu Server üzerinde WordPress'in gözetimsiz kurulumu yönergelerini izleyen nginx, PHP7 ve MySQL yapılandırması çalışır

Ek: inceleme araçları ve shell davranışı

  • Kaynak kodu bulma

    • strace tek başına yeterli olmadığında kaynak koda bakılabilir
    • which uptime ile binary konumu bulunur, dpkg -S /usr/bin/uptime ile de Ubuntu paketi bulunur
    • Örnekte uptime, procps paketine aittir
    • packages.ubuntu.com üzerinde paket aranabilir ve source repository linki bulunabilir

  • File descriptor ve redirection

    • stderr'i stdout'a yönlendirmek için 2>&1 kullanılır
    • echo something > file, stdout'u file dosyasına yazar ve echo something 1> file ile aynıdır
    • echo something 2> file, stderr'i file dosyasına yazar
    • echo something 2>1, stderr'i 1 adlı bir dosya adına yönlendirmek anlamına gelir
    • & içeren 2>&1 ifadesinde 1, bir dosya adı değil stream ID'dir

  • PuTTY renk sorunu

    • PuTTY'de htop öğeleri eksik görünüyorsa Window → Colours ayarlarından çözülebilir
    • başlık çubuğuna sağ tıklayın
    • Change settings...
    • Window → Colours
    • Both radio button seçin
    • Apply

  • C ile yazılmış basit shell

    • C ile yazılmış basit bir shell, fork, exec, wait sistem çağrılarının kullanımını gösterir
    • Girdi exit ise shell built-in olarak sonlanır
    • Diğer komutlar fork sonrasında child içinde execlp ile çalıştırılır, parent ise waitpid ile çıkış durumunu bekler
    • date, true, false çalıştırma örneklerinde child exit code ayrı ayrı çıktılanır
    • sleep 1 & gibi background process'lerin kapanış mesajının ancak Enter'a bastıktan sonra görünmesinin nedeni, shell'in girdi beklerken ancak komut girildiğinde background process durumunu kontrol etmesidir

Kalan inceleme başlıkları ve değişiklik geçmişi

  • Daha fazla araştırmak istenen başlıklar arasında process state substatus, kernel thread, /dev/pts, CODE·DATA·SWAP belleği, time slice uzunluğu, Linux scheduler algoritması, core pinning, manual page, CPU/memory bar renkleri, process ID limit ve fork bomb, lsof, ionice, schedtool vb. bulunur
  • Başlıca düzeltme ve güncellemeler şunları içerir
    • /proc/uptime idle time, tüm core'ların toplamıdır
    • zombie C örneğindeki parent/child printf düzeltilmiştir
    • apt remove cron komutunun MTA dependency nedeniyle postfix kurmaya çalıştığı bilgisi eklenmiştir
    • id, /etc/nsswitch.conf aracılığıyla /etc/passwd dışındaki başka source'lardan da bilgi yükleyebilir
    • /etc/shadow password hash formatı açıklaması eklenmiştir
    • /etc/sudoers dosyası güvenli şekilde visudo ile düzenlenmelidir
    • MEM% açıklaması eklenmiştir
    • load average bölümü yeniden yazılmıştır
    • kill 1234 için varsayılan signal'in INT değil TERM olduğu düzeltilmiştir
    • CPU ve memory color bar açıklaması eklenmiştir

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Hacker News görüşleri

  • Son zamanlarda btop'a geçtim; ihtiyaç duyduğum kadar modern ve kullanışlı, aynı zamanda yeterince bilgi sunan bir arayüzü var
    Başkalarının da söylediği gibi güç tüketimini (Watt) da gösteriyor gibi görünüyor; ayrıca ağ, GPU ve disk bilgileri de var
    https://github.com/aristocratos/btop

    • btop iyi ama eksileri de var: zram/zswap istatistikleri yok (htop da yalnızca zram destekliyor), ZFS istatistiklerinde ayrıntılı döküm yok ve henüz Arc GPU desteği de bulunmuyor
      Disk kullanım çubukları kapatılamıyor; bu yüzden konsol penceresi çok büyük değilse I/O hız grafiği fazla sıkışmış görünüyor
    • btop'u uzun zamandır kullanıyorum; eksik olan şey, diğer sütunların yanında bir port sütunu daha olması gibi geliyor
      CPU/GPU grafikleri fazla büyük ayrılmış ve genel olarak açık dosya tablosunun daha fazla yer kaplamasını isterdim
    • Hâlâ bazen konteyner temel imajı olarak Alpine kullanıyorum ama btop musl'u desteklemiyor gibi göründüğü için eleniyor
    • Sıkı bir btop taraftarıyım; yeni MacBook'umda iStatMenu'nün bile yerini aldı

  • htop kullanırken her seferinde değiştirdiğim 2 ayar var ve fark büyük
    Birincisi, kullanıcı thread'lerini kapatıyorum. Genelde sadece htop ekranını kalabalıklaştırıyorlar ve neredeyse hiç faydalı bilgi vermiyorlar
    İkincisi, process tree görünümünü açıyorum. Bir sürecin nereden başlatıldığı çoğu zaman diğer bilgilerden daha önemli oluyor; ayrıca çok sayıda dosya işleyip CPU tüketen derleyici süreçleri gibi şeyleri takip etmeyi kolaylaştırıyor
    Bana göre ikisi de htop'un varsayılan davranışı olmalı

    • Process tree görünümü güzel ama açılınca süreç listesinin dinamik güncellenmesi ve yeniden sıralanması duruyor, bu da üzücü

  • Sanal belleğe güvenmenin zor olduğuna dair açıklamayı görmek sevindirici. Windows Görev Yöneticisi bunu varsayılan olarak bu şekilde gösterdiği için oldukça kötü
    Yerleşik küme boyutu (RSS) en güvenilir gösterge; diğer değerler, gerçekte sorun yaratmayan memory-mapped dosyalar gibi şeyler yüzünden yanlış biçimde şişebilir
    Örneğin 2 GB'lık bir log dosyası memory-map edilse, ilgili kısım yalnızca okunduğunda sayfalar belleğe alınır; yani fiilen gerçek bellek kullanılıyor olmaz, ama kullanıcı sürece bakıp “bu uygulama neden bu kadar çok bellek kullanıyor?” der
    Chrome da bir süre bu sorunu yaşadı ve bu yüzden memory-mapped dosya kullanımını azalttı; bunun nedeni memory-mapped dosyaların kötü olması değil, kullanıcıların gerçek fiziksel bellek kullanımı yerine başka bir değeri görüp aşırı tepki vermesiydi
    İnternette kullanımın sanal bellek tahsisine göre değerlendirilmesi gerektiğini söyleyen rehberler de var, ama bu yazı en azından o noktayı doğru ele alıyor

    • Aslında orantılı küme boyutu (PSS) RSS'den daha doğrudur
      Bkz.: https://en.wikipedia.org/wiki/Proportional_set_size
    • Memory-mapped dosyalar kullanıldığında önbelleğe alınmış sayfalar o sürecin yerleşik küme boyutuna dahil edilir
      Normal dosya I/O kullanıldığında edilmez. Her işin bellek kullanımını izleyip istenen miktarı aşarsa öldüren HPC kümelerinde bu oldukça ilginç sonuçlar doğurur
    • Yerleşik küme boyutu, sürecin istediği bellek miktarı değil, işletim sisteminin o sürece vermeye karar verdiği miktardır
      Bellek baskısı başladığında artık temsil gücünü kaybeder. Bu yanlış anlama yüzünden birkaç kez hatalı karar verildiğini gördüm; hatta ekip arkadaşlarımın ters yönde karar vermesini engellemek için grafikten bu değeri kaldırdığım oldu
    • Tam olarak söylemek gerekirse Windows Görev Yöneticisi, varsayılan süreç bellek kullanımı olarak Private Working Set kullanır; kütüphaneler veya memory-mapped dosyalar gibi diğer süreçlerle paylaşılan sayfaları içermez
      Adından da anlaşılacağı gibi yalnızca süreç için özel olarak ayrılmış fiziksel belleğe eşlenen kısmı gösterir ve Unix'teki Resident Set'e daha yakındır
      Muhtemelen performans sekmesindeki bellek kullanımından söz ediliyordu ama tüm bellek kullanımı kalemleri için geçerliymiş gibi anlaşılabileceği için bunu ayırıyorum

  • top'ta > karakterini kullanırsanız bellek kullanımına göre sıralama yapılır
    Bunu bazen host'un neden yavaşladığını bulmak için kullanıyorum ve swapd'nin CPU'yu sömürdüğünü de görebiliyorsunuz

    • Ben bellek için büyük M, CPU için büyük P kullanmayı tercih ediyorum

  • Böyle yazılar okuyunca, Linux'u 20 yılı aşkın süredir her gün kullanıyor olmama rağmen hâlâ onun potansiyelinin yalnızca bir kısmını kullandığımı fark ediyorum. Güzel yazı

  • HN sanki yeniden toparlanıyormuş gibi hissettiriyor
    Umarım bu, HN'nin yürüyen hayalet dönemi değildir

    • Ana sayfada yapay zekayla ilgili 3 yazı var ama bunlardan biri düşük kaliteli üretimleri eleştiren bir yazı, o yüzden umutlanıyorum
    • Sanırım 7 yıl önceki slop öncesi yazılara dönerek toparlanıyor

  • nmon'u bilmeyenler buna da bir göz atabilir
    h tuşuna basınca kullanılabilir monitörlerin listesi çıkıyor, tekrar basınca kayboluyor ve q ile çıkılıyor
    https://nmon.sourceforge.io/pmwiki.php
    Özellikle d ve D tuşlarıyla görülen disk throughput ve I/O oldukça faydalı

    • İş yerinde kullandığım AIX makinelerinde tanımıştım; topas'ı da hatırlatıyor
    • Çok faydalı bir araç; kontrol edebildiğim tüm makinelere kuruyorum
      Geniş CPU kullanım grafiği yüksek çekirdek sayılarını kolayca göstermesi açısından güzel

  • *top ailesinden farklı bir kullanım tarzı olarak, sakin ps tarzı diferansiyel raporlamayı ve vmstat gibi sistem geneli raporları daha çok sevmeye başladım
    Böyle yapınca her şey terminal scrollback buffer'ında kalıyor: https://github.com/c-blake/procs
    Nadir görülen ölçüde verimli ve ifade gücü yüksek Nim diliyle yazılmış

  • Bu yazıyı 2016'dan beri yer imlerimde tutuyorum ve yıllar içinde birçok kez tekrar dönüp baktım