Linux htop/top स्क्रीन पर दिखने वाले मानों की व्याख्या (2019)

 (peteris.rocks)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ubuntu Server 16.04 x64 की htop स्क्रीन को शुरुआती बिंदु बनाकर यह देखा गया है कि uptime, load average, Tasks, PID, process tree, state, CPU time, priority और memory indicators वास्तव में क्या मतलब रखते हैं, और इन्हें /proc व command output के जरिए ट्रेस किया गया है
  • स्क्रीन पर दिखने वाले कई मान procfs और /etc/passwd, /etc/group, /etc/shadow, /etc/nsswitch.conf जैसी system files से आते हैं, और strace से यह जांचा जा सकता है कि program कौन-सी files पढ़ रहा है
  • Load average CPU usage rate जैसा मान नहीं है, बल्कि running, run queue में प्रतीक्षा कर रहे processes और uninterruptible state वाले processes को शामिल करने वाला exponential decay moving average है
  • R, S, D, Z, T, t जैसे state codes signal, kill, fork/exec/wait व्यवहार से जुड़े होते हैं, इसलिए ये समझने में मदद करते हैं कि process क्यों रुका हुआ है या क्यों बना हुआ है
  • VIRT, RES, SHR, MEM% virtual memory, physical memory और shareable memory को अलग-अलग दृष्टिकोण से दिखाते हैं, इसलिए केवल एक संख्या देखकर वास्तविक memory usage तय करना कठिन है

htop के मान कहाँ से आते हैं

  • uptime दिखाता है कि system कितनी देर से चल रहा है, और यही जानकारी uptime command से भी देखी जा सकती है
  • uptime program /proc/uptime पढ़ता है
    • पहली संख्या system के चालू रहने का कुल समय सेकंड में बताती है
    • दूसरी संख्या system के idle state में रहने का समय सेकंड में बताती है
    • multi-core system में idle time हर core के लिए जोड़कर गिना जाता है, इसलिए यह कुल uptime से बड़ा हो सकता है
  • strace uptime 2>&1 | grep open या strace -e open uptime से देखा जा सकता है कि uptime कौन-सी files खोलता है
    • उदाहरण output में /proc/uptime, /var/run/utmp, /proc/loadavg शामिल होते हैं
  • /proc/uptime की संख्याएँ program या script में इस्तेमाल करने के लिए सुविधाजनक हैं, जबकि uptime output इंसानों के पढ़ने के लिए format किया गया होता है

Load average और CPU usage rate

  • /proc/loadavg के पहले तीन मान पिछले 1 मिनट, 5 मिनट, 15 मिनट के system load average को दिखाते हैं
  • चौथा मान वर्तमान में running processes की संख्या और कुल processes की संख्या को 1/120 जैसे रूप में दिखाता है, और आख़िरी मान आख़िरी बार इस्तेमाल किया गया PID है
  • जब कोई नया process चलाया जाता है, तो उसे PID दिया जाता है; PID आम तौर पर बढ़ता जाता है और खत्म होने पर दोबारा इस्तेमाल किया जाता है
    • PID 1 boot के समय शुरू होने वाले /sbin/init का होता है
  • अगर htop में केवल एक running process दिख रहा है, तो वह htop खुद भी हो सकता है
  • sleep 30 running नहीं बल्कि sleep state में होता है, इसलिए यह running process count नहीं बढ़ाता
  • cat /dev/urandom > /dev/null जैसा लगातार CPU इस्तेमाल करने वाला काम running process count और load average बढ़ाता है
  • Load number वह मान है जो running, run queue में प्रतीक्षा कर रहे और uninterruptible state वाले processes को गिनता है
  • load average साधारण average नहीं बल्कि exponential decay moving average है
    • 1-minute load average भी केवल पिछले 60 seconds को ही नहीं दर्शाता, बल्कि हाल के 1 minute को ज़्यादा weight देते हुए उससे पहले की activity का कुछ हिस्सा भी शामिल करता है
  • single CPU system में अगर एक CPU-bound process हो, तो load average 1.00 को सरल रूप में CPU 100% usage माना जा सकता है
    • 2-core system में वही स्थिति CPU usage 50% के बराबर मानी जा सकती है
    • 2-core system में CPU 100% usage के अनुरूप load average को सरल रूप में 2.00 माना जा सकता है
  • यह सरलीकरण हमेशा सही नहीं होता, क्योंकि load में uninterruptible state वाले processes भी शामिल होते हैं
    • ऐसा भी हो सकता है कि load average ऊँचा हो लेकिन CPU usage rate ऊँचा न हो
  • तात्कालिक CPU usage rate mpstat से देखा जा सकता है
    • sudo apt install sysstat -y
    • mpstat 1

Tasks, PID, process tree

  • htop के ऊपर दाईं ओर दिखने वाला Tasks कुल processes की संख्या और running processes की संख्या दिखाता है
  • Linux kernel अंदरूनी तौर पर process को task कहता है, और htop screen space बचाने के लिए Processes की जगह Tasks शब्द का उपयोग करता है
  • Shift+H से thread display को toggle किया जा सकता है
    • Tasks: 23, 10 thr जैसा दिखे तो इसका मतलब है कि thread display चालू है
  • Shift+K से kernel thread display को toggle किया जा सकता है
    • Tasks: 23, 40 kthr जैसा दिखे तो इसका मतलब है कि kernel thread display चालू है
  • हर नए process के शुरू होने पर PID दिया जाता है
    • sleep 1000 & की तरह background में चलाने पर job number और PID दिखता है
    • bash में $! आख़िरी background process ID में expand होता है
  • process से जुड़ी जानकारी /proc/<pid>/ के नीचे होती है
    • /proc/<pid>/cmdline execution command रखता है और arguments \0 byte से अलग किए जाते हैं
    • tr '\0' '\n' < /proc/<pid>/cmdline या strings /proc/<pid>/cmdline से इसे आसानी से पढ़ा जा सकता है
    • /proc/<pid>/cwd current working directory का link है, और /proc/<pid>/exe executed binary का link है
  • htop, top, ps जैसे diagnostic tools process details को /proc/<pid>/<file> से पढ़ते हैं
  • नया process बनाने वाले को parent process और नए बने हुए को child process कहा जाता है, और यही संबंध process tree बनाता है
  • htop में F5 दबाने पर process hierarchy देखी जा सकती है
    • ps f और pstree -a भी यही संबंध दिखाते हैं
  • bash में date चलाने पर bash fork से अपनी copy बनाता है, फिर exec से /bin/date को memory में लोड करता है, और parent bash child के खत्म होने का इंतज़ार करता है
  • /sbin/init boot के समय शुरू होता है और sshd को चलाता है; SSH connection होने पर sshd session process बनाता है और वह session bash shell चलाता है

प्रोसेस उपयोगकर्ता और permissions

  • हर प्रोसेस किसी उपयोगकर्ता के स्वामित्व में होता है, और उपयोगकर्ता को संख्यात्मक ID से दर्शाया जाता है
  • /proc/<pid>/status के Uid entry से प्रोसेस का user ID देखा जा सकता है
  • id 1000 जैसे कमांड उस संख्यात्मक ID से जुड़े user name और group दिखाते हैं
  • id /etc/nsswitch.conf सेटिंग के अनुसार name resolution source चुनता है
    • उदाहरण सिस्टम में यह /etc/passwd और /etc/group को पढ़ता है
    • compat Compatibility mode है, जो files जैसा है लेकिन special entries की अनुमति देता है
    • उपयोगकर्ता जानकारी LDAP जैसे अन्य database या service में भी संग्रहीत हो सकती है
  • /etc/passwd और /etc/group plain text फाइलें हैं जो संख्यात्मक ID को इंसानों के पढ़ने योग्य नामों से map करती हैं
  • वास्तविक password जानकारी /etc/shadow में होती है
    • $6$ का मतलब sha512 hashing algorithm है
    • इसके बाद rainbow table हमलों को रोकने के लिए random salt और password+salt का hash आता है
  • प्रोग्राम डिफ़ॉल्ट रूप से उसे चलाने वाले उपयोगकर्ता की permissions के साथ चलते हैं
    • executable file का मालिक कोई दूसरा उपयोगकर्ता हो, तब भी यही लागू होता है
  • किसी दूसरे उपयोगकर्ता या root के रूप में चलाने के लिए sudo का उपयोग किया जाता है
    • sudo id root के UID 0 के साथ चलता है
    • sudo -u daemon id की तरह किसी खास उपयोगकर्ता के रूप में चलाया जा सकता है
  • /etc/sudoers में direct redirect से लिखने पर सिर्फ echo ही root के रूप में चलता है और append मौजूदा उपयोगकर्ता के रूप में होता है, इसलिए यह विफल हो सकता है
    • 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 से ही संपादित करना चाहिए
    • यह save करने से पहले सामग्री validate करता है ताकि ऐसी गलती न हो जाए जिससे sudo का उपयोग ही बंद हो जाए
  • /usr/bin/passwd सामान्य उपयोगकर्ता द्वारा चलाए जाने पर भी /etc/shadow में लिख सकता है
    • file permissions में s होने के कारण यह setuid executable की तरह काम करता है
    • यह executable file के मालिक root की permissions के साथ चलता है
    • root स्वामित्व वाले setuid executables को find /bin -user root -perm -u+s से खोजा जा सकता है

प्रोसेस state code

  • htop का state column S नाम से दिखता है, और मुख्य मान इस प्रकार हैं
    • R: running या runnable, यानी चल रहा है या run queue में प्रतीक्षा कर रहा है
    • S: interruptible sleep, किसी event के पूरा होने की प्रतीक्षा
    • D: uninterruptible sleep, आमतौर पर I/O waiting
    • Z: defunct zombie, समाप्त हो चुका है लेकिन parent ने reap नहीं किया
    • T: job control signal से रोका गया
    • t: tracing के दौरान debugger द्वारा रोका गया
    • X: dead, यह state दिखनी नहीं चाहिए
  • ps Ss, R+, Ss+ जैसे substate भी दिखाता है

  • R: चल रहा है या चलने योग्य

    • R state का मतलब है कि प्रोसेस या तो अभी चल रहा है या execution queue में प्रतीक्षा कर रहा है
    • प्रोग्राम का source code compile होने के बाद CPU instructions बन जाता है, और execution के समय memory में load होकर CPU उन instructions को चलाता है
    • running होने का अर्थ है कि CPU वास्तव में उन instructions को भौतिक रूप से execute कर रहा है

  • S: interruptible sleep

    • S state में प्रोसेस की instructions CPU पर execute नहीं हो रहीं होतीं, बल्कि वह किसी event या condition की प्रतीक्षा कर रहा होता है
    • event होने पर kernel उसकी state को running में बदल देता है
    • sleep 1000 निश्चित समय तक प्रतीक्षा का एक उदाहरण है
    • इस state को signal से interrupt किया जा सकता है
    • htop में F9 दबाकर signal भेजा जा सकता है
    • kill signal भेजने वाली system call है, और /bin/kill userland में इसे call करने वाला प्रोग्राम है
    • default signal TERM है, जो प्रोसेस से समाप्त होने का अनुरोध करता है
    • signal संख्यात्मक होते हैं, और इनके नाम आमतौर पर uppercase में लिखे जाते हैं तथा उनके आगे SIG prefix हो सकता है
    • उदाहरण: INT, KILL, STOP, CONT, HUP
    • kill -INT 10089, kill -2 10089, /bin/kill -2 10089 एक ही काम करते हैं
    • CTRL+C दबाने पर bash foreground process को SIGINT भेजता है
    • SIGINT या SIGTERM भेजने से यह ज़रूरी नहीं कि प्रोसेस अवश्य समाप्त हो जाए
    • प्रोग्राम signal handler सेट करके cleanup के बाद समाप्त होने जैसी processing कर सकता है
    • SIGKILL या 9 में kernel प्रोसेस को प्रतिक्रिया का मौका दिए बिना उसे forcefully समाप्त कर देता है

  • D: uninterruptible sleep

    • D state को signal से जगाया नहीं जा सकता, और SIGKILL भी signal ही है, इसलिए ऐसे प्रोसेस को kill नहीं किया जा सकता
    • यह state तब उपयोगी होती है जब प्रोसेस को बिना interruption के प्रतीक्षा करनी हो, या जब event के जल्दी होने की उम्मीद हो
    • उदाहरण: disk read/write
    • uninterruptible process अक्सर page fault के बाद I/O की प्रतीक्षा में हो सकता है
    • NFS read/write latency के दौरान ऐसी state बन सकती है
    • उपलब्ध memory बहुत कम होने और प्रोसेस के अधिक swap करने की स्थिति में भी यह दिख सकती है
    • उदाहरण के लिए sudo mount 8.8.8.8:/tmp /tmp & चलाने पर /sbin/mount.nfs D state में चला जाता है
    • strace में देखने पर mount system call प्रोसेस को block करती दिखती है
    • mount में intr option देने पर इसे interruptible बनाया जा सकता है
    • sudo mount 8.8.8.8:/tmp /tmp -o intr

  • Z: zombie प्रोसेस

    • Z state का मतलब है कि प्रोसेस समाप्त हो चुका है लेकिन parent ने अभी तक उसे reap नहीं किया है
    • zombie प्रोसेस थोड़े समय के लिए मौजूद रहे तो यह सामान्य हो सकता है
    • लंबे समय तक बने रहने वाले zombie प्रोसेस किसी प्रोग्राम bug का संकेत हो सकते हैं
    • zombie प्रोसेस memory consume नहीं करते, सिर्फ PID घेरते हैं
    • zombie प्रोसेस को स्वयं kill नहीं किया जा सकता
    • parent process को SIGCHLD भेजकर zombie को reap करने के लिए कहा जा सकता है
    • parent process को kill करने पर parent और उसका zombie दोनों हट सकते हैं
    • fork के बाद child का exit(0) करना और parent का sleep(20) करना, ऐसे C प्रोग्राम से zombie state को दोहराया जा सकता है
    • parent के समाप्त होते ही zombie गायब हो जाता है
    • zombie के बने रहने का कारण यह है कि parent को wait system call के जरिए child का exit code देखना पड़ सकता है

  • T और t: रुके हुए प्रोसेस

    • T state job control signal से रोकी गई state है
    • cat /dev/urandom > /dev/null चलाते समय CTRL+Z दबाने पर यह T state में चला जाता है
    • fg से इसे फिर से चलाया जा सकता है
    • STOP signal से रोका और CONT signal से फिर शुरू किया जा सकता है
    • t state वह है जिसमें debugger tracing के दौरान प्रोसेस को रोक देता है
    • nc -l 1234 & से चलाए गए प्रोसेस पर sudo gdb -p <pid> से attach करने पर वह t state में चला जाता है

CPU समय, niceness, priority

  • Linux एक multitasking operating system है, इसलिए एक ही CPU पर भी कई process ऐसे दिखते हैं मानो वे एक साथ चल रहे हों
  • वास्तव में एक single CPU एक समय में केवल एक ही command चला सकता है, इसलिए time sharing का उपयोग किया जाता है
    • एक process थोड़ी देर चलता है और फिर रुक जाता है
    • execution का इंतज़ार कर रहे दूसरे process बारी-बारी से चलते हैं
    • जिस छोटे अंतराल में एक process चलता है, उसे time slice कहा जाता है
  • time slice आमतौर पर कुछ millisecond का होता है, इसलिए अगर system load ज़्यादा न हो तो यह आसानी से महसूस नहीं होता
  • single core पर load average 1.0 हो तो इसे CPU के 100% उपयोग के रूप में देखा जा सकता है
    • अगर यह 1.0 से अधिक हो, तो इसका मतलब है कि चलने की प्रतीक्षा कर रहे process की संख्या CPU की क्षमता से अधिक है, जिससे slowdown या delay हो सकता है
    • अगर यह 1.0 से कम हो, तो CPU कभी-कभी idle स्थिति में होता है
  • process का running time वास्तविक बीता हुआ समय से बिल्कुल समान न हो, इसका कारण भी time sharing से समझा जा सकता है
  • अगर उपलब्ध CPU core की संख्या से ज़्यादा task चलाने हों, तो यह तय करना पड़ता है कि पहले किस task को चलाया जाए
  • Linux kernel का scheduler run queue से अगला process चुनता है, और यह kernel के scheduler algorithm पर निर्भर करता है
  • आम तौर पर scheduler को सीधे नियंत्रित नहीं किया जा सकता, लेकिन यह बताया जा सकता है कि कौन-सा process अधिक महत्वपूर्ण है
  • NI के रूप में दिखने वाला niceness user-space priority है
    • इसकी range -20 से 19 तक होती है
    • -20 सबसे ऊँची priority है और 19 सबसे नीची priority है
    • अधिक nice process को कम nice process के लिए ज़्यादा जगह छोड़ने वाला माना जा सकता है
  • PRI वह kernel-space priority है जिसका उपयोग Linux kernel करता है
    • इसकी range 0 से 139 तक होती है
    • 0~99 real time के लिए है, और 100~139 user के लिए है
  • nice value और priority का संबंध PR = 20 + NI से समझाया जाता है
    • NI का -20~+19 PR के 0~39 में बदलता है, और यह 100~139 पर map होता है
  • execution से पहले niceness को nice -n niceness program से set किया जाता है
  • चल रहे process की niceness को renice -n niceness -p PID से बदला जाता है
  • CPU usage के रंग इस प्रकार हैं
    • Blue: low-priority thread, nice > 0
    • Green: सामान्य priority thread
    • Red: kernel thread

मेमोरी संकेतक: VIRT, RES, SHR, MEM%

  • process को ऐसा दिखाई देता है मानो वह मेमोरी में अकेला मौजूद हो, और यह virtual memory के ज़रिए लागू किया जाता है
  • process physical memory तक सीधे पहुँच नहीं करता, बल्कि उसका अपना virtual address space होता है
  • kernel virtual memory address को physical memory में बदल सकता है या उसके कुछ हिस्सों को disk पर map कर सकता है
  • इसी वजह से ऐसा लग सकता है कि कोई process कंप्यूटर में लगी वास्तविक मेमोरी से भी अधिक मेमोरी इस्तेमाल कर रहा है
  • process की memory usage इस बात पर निर्भर करती है कि उसमें नीचे दिए गए items शामिल हैं या नहीं
    • shared library
    • disk-mapped memory
    • swapped out memory
  • memory usage के रंग इस प्रकार हैं
    • Green: used memory
    • Blue: buffers
    • Orange: cache

  • VIRT/VSZ

    • VIRT task द्वारा उपयोग की जाने वाली कुल virtual memory की मात्रा है
    • इसमें code, data, shared library, swapped out page, और mapped लेकिन उपयोग न किए गए page शामिल होते हैं
    • यदि application 1GB request करे और केवल 1MB ही उपयोग करे, तब भी VIRT 1GB दिख सकता है
    • अगर 1GB file को mmap किया गया हो और वास्तव में उपयोग न किया गया हो, तब भी VIRT 1GB दिख सकता है
    • अधिकांश मामलों में VIRT कोई बहुत उपयोगी संख्या नहीं होती

  • RES/RSS

    • RES swapped out न हुई physical memory, यानी वर्तमान में physical memory में मौजूद resident memory usage है
    • RES, VIRT की तुलना में वास्तविक memory usage को बेहतर दिखा सकता है, लेकिन इसकी भी सीमाएँ हैं
    • इसमें swapped out memory शामिल नहीं होती
    • कुछ memory दूसरे process के साथ shared हो सकती है
    • अगर कोई process 1GB memory उपयोग करे और फिर fork() करे, तो दोनों process का RES अलग-अलग 1GB दिख सकता है, लेकिन Linux के copy-on-write के कारण वास्तव में केवल 1GB ही उपयोग हो सकता है

  • SHR

    • SHR task द्वारा उपयोग की जाने वाली shared memory की मात्रा है
    • यह उस memory को दर्शाता है जिसे संभावित रूप से दूसरे process के साथ share किया जा सकता है
    • उदाहरण C program यह दिखाता है कि malloc, कुछ memory उपयोग, fork, और अतिरिक्त memory write के बाद VIRT, RES, SHR values कैसे बदलती हैं
    • संबंधित memory example section अभी TODO के रूप में छोड़ा गया है

  • MEM%

    • MEM% task द्वारा वर्तमान में उपयोग की जा रही available physical memory का प्रतिशत है
    • यह RES को कुल RAM से भाग देने पर आधारित है
    • उदाहरण: अगर RES 400M है और RAM 8GB है, तो 400/8192*100 = 4.88%

Ubuntu Server 16.04 की डिफ़ॉल्ट प्रोसेसें

  • fresh Digital Ocean droplet के Ubuntu Server 16.04.1 LTS x64 पर शुरू होने वाली प्रोसेसों की जाँच की गई

  • /sbin/init

    • /sbin/init boot process के बाकी हिस्से को समन्वित करता है और user environment को कॉन्फ़िगर करता है
    • यह अपने-आप शुरू होने वाली प्रोसेसों का parent या grandparent बनता है
    • dpkg -S /sbin/init का परिणाम systemd-sysv: /sbin/init आता है, यानी इस सिस्टम पर यह systemd है
    • इसे kill करने पर भी कुछ नहीं होता

  • /lib/systemd/systemd-journald

    • systemd-journald logging data को इकट्ठा और स्टोर करने वाली system service है
    • यह कई source से मिली log जानकारी के आधार पर structured, indexed journal बनाती और बनाए रखती है
    • साधारण plain text log file की जगह log message के लिए optimized विशेष file format का उपयोग करती है
    • इसे journalctl से देखा जा सकता है
    • journalctl _COMM=sshd
    • journalctl _COMM=sshd -o json-pretty
    • journalctl --since yesterday
    • journalctl -b
    • journalctl -f
    • journalctl --disk-usage
    • journalctl --vacuum-size=1G
    • इसे हटाना या disable करना संभव नहीं लगता, केवल logging बंद की जा सकती है

  • /sbin/lvmetad -f

    • lvmetad LVM metadata को cache करता है ताकि LVM command disk scan के बिना metadata पढ़ सकें
    • disk scan में समय लगता है और यह सिस्टम व disk के सामान्य काम में बाधा डाल सकता है
    • LVM को ऐसे “dynamic partitions” की तरह देखा जा सकता है जिनमें Linux चलते समय logical volume बनाना, resize करना और हटाना संभव है
    • अगर आप LVM इस्तेमाल कर रहे हैं, तो इसे बनाए रखना चाहिए

  • /lib/systemd/udevd

    • systemd-udevd kernel uevent को सुनता है और हर event के लिए udev rules की matching instruction चलाता है
    • udev Linux kernel का device manager है और मुख्य रूप से /dev directory के device node को मैनेज करता है
    • virtual server में इसकी ज़रूरत है या नहीं, इस पर निश्चित नहीं है

  • /lib/systemd/timesyncd

    • systemd-timesyncd remote NTP server और local system clock को sync करने वाली system service है
    • यह ntpd का विकल्प है
    • उदाहरण सिस्टम में timedatectl status network time और NTP synchronized को yes दिखाता है
    • netstat output में केवल SSH port listening दिखता है, और Ubuntu 14.04 के ntpd की तरह कई UDP 123 port नहीं खुलते

  • /usr/sbin/atd -f

    • atd queue में डाले गए job को बाद में चलाता है
    • at और batch stdin या file से command पढ़कर बाद में चलाते हैं
    • cron के विपरीत, जो बार-बार चलने वाले task schedule करता है, at किसी निश्चित समय पर एक बार चलता है
    • उदाहरण में echo "touch /tmp/yolo.txt" | at now + 1 minute से 1 मिनट बाद file बनाई जाती है
    • अगर उपयोग नहीं करते, तो sudo apt remove at -y --purge से हटा सकते हैं

  • /usr/lib/snapd/snapd

    • Snappy Ubuntu Core को transactional update इस्तेमाल करने वाले Ubuntu rendition के रूप में बताया गया है
    • snap को universal Linux package format के रूप में समझाया गया है, जिसमें एक binary package Linux desktop, server, cloud और device पर चल सकता है
    • इसे simplified deb package की तरह समझा जा सकता है, जिसमें dependency को एक single snap में बाँधकर distribute किया जाता है
    • server पर snappy से application deploy या distribute करने का अनुभव न होने के कारण इसे sudo apt remove snapd -y --purge से हटा दिया गया

  • /usr/bin/dbus-daemon

    • D-Bus एक ही machine पर एक साथ चल रहे कई process के बीच IPC और RPC mechanism है
    • desktop environment में इसकी ज़रूरत होती है, लेकिन web app चलाने वाले server पर इसकी ज़रूरत है या नहीं, इस पर सवाल है
    • dbus हटाने पर timedatectl status Failed to create bus connection: No such file or directory के साथ fail हो गया
    • इसलिए इसे रखना बेहतर माना गया

  • /lib/systemd/systemd-logind

    • systemd-logind user login को मैनेज करने वाली system service है

  • /usr/sbin/cron -f

    • cron scheduled command चलाने वाला daemon है
    • -f का मतलब foreground mode है, यानी यह daemonize नहीं करता
    • समय-समय पर चलने वाले काम cron से schedule किए जा सकते हैं
    • crontab -e
    • Ubuntu में आम तौर पर /etc/cron.hourly, /etc/cron.daily आदि का उपयोग किया जाता है
    • log निम्न तरीके से देखे जा सकते हैं
    • grep cron /var/log/syslog
    • journalctl _COMM=cron
    • journalctl _COMM=cron --since="date" --until="date"
    • cron को बनाए रखने की संभावना अधिक है
    • अगर हटाना न हो, तो sudo systemctl stop cron, sudo systemctl disable cron से इसे रोक और disable कर सकते हैं
    • apt remove cron postfix आदि को install करने की कोशिश कर सकता है
    • क्योंकि cron mail transport agent को suggest करता है

  • /usr/sbin/rsyslogd -n

    • rsyslogd message logging को सपोर्ट करने वाली system utility है
    • यह /var/log/auth.log जैसे /var/log/ के log file भरने का काम करता है
    • configuration file /etc/rsyslog.d में होती हैं
    • remote server पर log भेजकर centralized logging बनाया जा सकता है
    • logger command से background script में /var/log/syslog में message छोड़ा जा सकता है
    • systemd-journald पहले से होने पर भी rsyslog और journal की विशेषताएँ अलग हैं, इसलिए दोनों को साथ इस्तेमाल करना उपयोगी हो सकता है
    • इसलिए फिलहाल इसे बनाए रखा गया

  • /usr/sbin/acpid

    • acpid एक ACPI event daemon है
    • इसे इस तरह डिज़ाइन किया गया है कि यह user-space program को ACPI event की जानकारी दे
    • ACPI का उपयोग hardware component discovery/configuration, power management, status monitoring आदि में होता है
    • virtual server में suspend/resume का इरादा न होने के कारण इसे हटाकर देखा गया
    • reboot सफल रहा, लेकिन halt के बाद भी Digital Ocean ने सिस्टम को चालू माना, इसलिए web interface से Power Off करना पड़ा
    • इसलिए इसे बनाए रखना बेहतर माना गया

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

    • lxcfs LXC container के लिए डिज़ाइन किया गया FUSE filesystem है
    • यह /proc की कुछ file का virtualized view और host cgroup filesystem तक filtered access देता है
    • इससे container के अंदर uptime, top आदि अधिक “correct” परिणाम दे सकते हैं
    • अगर LXC container इस्तेमाल नहीं करते, तो sudo apt remove lxcfs -y --purge से हटाया जा सकता है

  • /usr/lib/accountservice/accounts-daemon

    • AccountsService user account जानकारी को query और manipulate करने के लिए D-Bus interface और उसका implementation देता है
    • इसका implementation usermod(8), useradd(8), userdel(8) command पर आधारित है

  • हटाने के बाद क्या टूटेगा, यह “Time will tell” पर छोड़ दिया गया है

  • /sbin/mdadm

    • mdadm एक Linux utility है जो software RAID device को manage और monitor करती है
    • RAID कई hard drive को एक की तरह इस्तेमाल करने का तरीका है
    • RAID 0 drive capacity को बढ़ाता है
    • RAID 1, RAID 5, RAID 6, RAID 10 का उद्देश्य drive failure के समय data loss को रोकना है
    • इसे sudo apt remove mdadm -y --purge से हटाया जा सकता है

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

    • polkitd एक PolicyKit daemon है, और polkit एक Authorization Framework है
    • इसे fine-grained sudo की तरह समझा जा सकता है
    • यह non-privileged user को root के रूप में कुछ specific action करने की permission दे सकता है
    • उदाहरण: desktop Linux में reboot की अनुमति देना
    • server में इसे sudo apt remove policykit-1 -y --purge से हटाया जा सकता है, ऐसा बताया गया है
    • क्या टूटेगा, यह अब भी सवाल बना हुआ है

  • /usr/sbin/sshd -D

    • sshd OpenSSH Daemon है
    • -D option detach नहीं करता और daemon mode में नहीं जाने देता, जिससे monitoring आसान होती है

  • /sbin/iscsid

    • iscsid एक background daemon है जो iSCSI configuration के अनुसार काम करता है और connection को manage करता है
    • iSCSI एक IP-आधारित storage networking standard है, जो SCSI command को IP network के जरिए भेजता है ताकि remote storage को local disk की तरह इस्तेमाल किया जा सके
    • इसे sudo apt remove open-iscsi -y --purge से हटाया जा सकता है

  • /sbin/agetty --noclear tty1 linux

    • agetty Linux getty का एक alternative है
    • getty physical या virtual terminal को manage करता है, और connection detect होने पर username prompt दिखाने के बाद login program चलाता है
    • Digital Ocean में droplet details के Console के जरिए browser में इस terminal के साथ interact किया जा सकता है
    • getty@tty1.service से जुड़ी files हटाकर reboot करने पर SSH access तो संभव था, लेकिन Digital Ocean web console में login नहीं हो सका

  • SSH सेशन, bash, htop

    • sshd: root@pts/0 का मतलब है कि root user का SSH session pseudoterminal pts/0 पर सेट है
    • pseudoterminal वास्तविक text terminal को emulate करता है
    • bash इस्तेमाल में आ रहा shell है
    • -bash की तरह आगे dash लगा हो तो इसका मतलब है कि यह login shell के रूप में शुरू हुआ है
    • argument zero का पहला character - हो, या --login option के साथ शुरू हुआ shell, login shell होता है
    • इस स्थिति में यह configuration files के अलग set को पढ़ता है
    • htop screenshot में चल रहा interactive process viewer है

सेवा हटाने के प्रयोग

  • सामान्य हटाने की सूची इस प्रकार है
    • 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 में निम्न कार्य शामिल हैं
    • 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
  • unattended installation of WordPress on Ubuntu Server निर्देशों का पालन करने वाला nginx, PHP7, MySQL कॉन्फ़िगरेशन काम करता है

परिशिष्ट: जांच के टूल और shell का व्यवहार

  • source code ढूंढना

    • जब केवल strace पर्याप्त न हो, तब source code देखा जा सकता है
    • which uptime से binary का स्थान पता करें, और dpkg -S /usr/bin/uptime से Ubuntu package खोजें
    • उदाहरण में uptime, procps package का हिस्सा है
    • packages.ubuntu.com पर package खोजकर source repository link पाया जा सकता है

  • file descriptor और redirection

    • stderr को stdout पर redirect करते समय 2>&1 का उपयोग किया जाता है
    • echo something > file का मतलब stdout को file में लिखना है, और यह echo something 1> file के बराबर है
    • echo something 2> file stderr को file में लिखता है
    • echo something 2>1 का अर्थ stderr को 1 नाम की filename पर redirect करना है
    • & लगे हुए 2>&1 में 1 filename नहीं बल्कि stream ID है

  • PuTTY रंग समस्या

    • यदि PuTTY में htop के कुछ तत्व गायब दिखें, तो इसे Window → Colours सेटिंग में ठीक किया जा सकता है
    • title bar पर right-click करें
    • Change settings...
    • Window → Colours
    • Both radio button चुनें
    • Apply

  • C में बना सरल shell

    • C में लिखा गया एक सरल shell, fork, exec, wait system call के उपयोग को दिखाता है
    • यदि input exit हो, तो shell built-in के रूप में बंद हो जाता है
    • अन्य कमांड fork के बाद child में execlp से चलाए जाते हैं, और parent waitpid से exit status का इंतज़ार करता है
    • date, true, false चलाने के उदाहरण में child exit code क्रमशः प्रिंट होते हैं
    • sleep 1 & जैसे background process का समाप्ति संदेश Enter दबाने के बाद ही दिखने का कारण यह है कि shell input की प्रतीक्षा करते हुए, कमांड दर्ज होने पर background process की स्थिति जांचता है

बाकी जांच के विषय और संशोधन इतिहास

  • जिन विषयों के बारे में और जानना बाकी है, वे हैं process state substatus, kernel thread, /dev/pts, CODE·DATA·SWAP मेमोरी, time slice की लंबाई, Linux scheduler algorithm, core pinning, manual page, CPU/memory bar के रंग, process ID limit और fork bomb, lsof, ionice, schedtool आदि
  • मुख्य संशोधन और अपडेट में निम्न शामिल हैं
    • /proc/uptime का idle time सभी core का कुल योग है
    • zombie C उदाहरण में parent/child printf को ठीक किया गया
    • यह जोड़ा गया कि apt remove cron, MTA dependency के कारण postfix install करने की कोशिश करता है
    • id, /etc/nsswitch.conf के जरिए /etc/passwd के अलावा अन्य source से भी जानकारी लोड कर सकता है
    • /etc/shadow password hash format की व्याख्या जोड़ी गई
    • /etc/sudoers को सुरक्षित रूप से visudo से edit करना चाहिए
    • MEM% की व्याख्या जोड़ी गई
    • load average सेक्शन को फिर से लिखा गया
    • kill 1234 का default signal INT नहीं बल्कि TERM है, यह सुधार किया गया
    • CPU और memory color bar की व्याख्या जोड़ी गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • हाल में मैं btop पर आ गया हूँ; इसका इंटरफ़ेस जितना आधुनिक और उपयोगी चाहिए था, उतना है और जानकारी भी पर्याप्त देता है
    जैसा दूसरों ने कहा, यह बिजली की खपत (Watts) भी दिखाता लगता है, और साथ में network, GPU, disk की जानकारी भी दिखती है
    https://github.com/aristocratos/btop

    • btop अच्छा है, लेकिन कमियाँ भी हैं: zram/zswap statistics नहीं हैं (htop भी सिर्फ zram सपोर्ट करता है), ZFS statistics का विस्तृत breakdown नहीं है, और अभी Arc GPU सपोर्ट नहीं करता
      disk usage bar बंद नहीं किया जा सकता, इसलिए console window बहुत बड़ी न हो तो I/O speed graph बुरी तरह दबा हुआ दिखता है
    • मैं लंबे समय से btop इस्तेमाल कर रहा हूँ; जो चीज़ कमी लगती है, वह बस दूसरी columns के पास एक port column है
      CPU/GPU graphs बहुत ज्यादा बड़े रखे गए हैं, और कुल मिलाकर चाहता हूँ कि open files table ज़्यादा जगह ले
    • मैं अब भी कभी-कभी container base image के तौर पर Alpine इस्तेमाल करता हूँ, और लगता है btop musl सपोर्ट नहीं करता, इसलिए वह बाहर हो जाता है
    • मैं btop का इतना समर्थक हूँ कि नए MacBook पर मैंने iStatMenu तक को इससे replace कर दिया

  • htop इस्तेमाल करते समय मैं 2 settings हमेशा बदलता हूँ, और फर्क काफी बड़ा होता है
    पहली, user threads बंद करता हूँ। ज़्यादातर वे htop screen को ही उलझाते हैं और उपयोगी जानकारी बहुत कम देते हैं
    दूसरी, process tree view चालू करता हूँ। process कहाँ से शुरू हुआ, यह अक्सर बाकी जानकारी से ज़्यादा महत्वपूर्ण होता है, और बहुत सारी files process करते हुए CPU खाने वाले compiler process जैसी चीज़ों को track करना भी आसान हो जाता है
    निजी तौर पर मुझे लगता है कि ये दोनों htop का default behavior होना चाहिए

    • process tree view अच्छा है, लेकिन इसे चालू करने पर process list की dynamic refresh और reordering रुक जाती है, यह अफसोस की बात है

  • virtual memory पर भरोसा करना मुश्किल है, यह explanation देखकर अच्छा लगा। Windows Task Manager default में इसी तरह दिखाता है, इसलिए बहुत खराब है
    resident set size (RSS) सबसे भरोसेमंद metric है, और बाकी values memory-mapped files जैसी चीज़ों की वजह से गलत तरीके से फूल सकती हैं जो असल में समस्या पैदा नहीं करतीं
    उदाहरण के लिए, 2GB log file को memory map करने पर भी वह हिस्सा तभी pages में आता है जब उसे पढ़ा जाता है, इसलिए वह असली memory इस्तेमाल नहीं कर रहा होता; लेकिन user process देखकर कहता है, “यह app इतनी memory क्यों खा रहा है?”
    Chrome ने भी कुछ समय तक यह समस्या झेली और memory-mapped files का इस्तेमाल घटाया; इसलिए नहीं कि memory-mapped files खराब थीं, बल्कि इसलिए कि users actual physical memory usage नहीं, बल्कि एक अलग value देखकर overreact कर रहे थे
    web पर ऐसे guides भी हैं जो virtual memory allocation के आधार पर usage judge करने को कहते हैं; यह लेख कम से कम उस हिस्से को सही तरह से पकड़ता है

    • असल में proportional set size (PSS) RSS से ज़्यादा accurate है
      संदर्भ: https://en.wikipedia.org/wiki/Proportional_set_size
    • memory-mapped file इस्तेमाल करने पर cached pages उस process के resident set size में शामिल हो जाते हैं
      सामान्य file I/O इस्तेमाल करने पर शामिल नहीं होते। जिन HPC clusters में हर job की memory usage monitor करके request से ज़्यादा होने पर उसे मार दिया जाता है, वहाँ इससे काफी दिलचस्प नतीजे निकलते हैं
    • resident set size वह memory amount नहीं है जो process चाहता है, बल्कि operating system ने उस process को जितना देने का फैसला किया है वह है
      memory pressure शुरू होने पर यह अब representative नहीं रहता। इस गलतफहमी की वजह से मैंने कई गलत फैसले देखे हैं, और एक बार तो team member को उलटा निष्कर्ष निकालने से रोकने के लिए मैंने chart से यह value हटा ही दी थी
    • ठीक-ठीक कहें तो Windows Task Manager process memory usage के default के रूप में Private Working Set इस्तेमाल करता है, और libraries या memory-mapped files जैसे दूसरे processes के साथ shared pages को शामिल नहीं करता
      नाम के मुताबिक, यह सिर्फ process के लिए निजी तौर पर allocated physical memory में mapped हिस्सा दिखाता है, और Unix के Resident Set के ज्यादा करीब है
      शायद बात Performance tab की memory usage की हो रही है, लेकिन इसे सभी memory usage items समझने की गलतफहमी हो सकती है, इसलिए फर्क स्पष्ट कर रहा हूँ

  • top में > character इस्तेमाल करने पर memory usage के आधार पर sorting हो जाती है
    host धीमा क्यों हो रहा है, यह पता करने के लिए कभी-कभी इस्तेमाल करता हूँ, और swapd को CPU खाते हुए भी देख सकते हैं

    • memory के लिए uppercase M, CPU के लिए uppercase P इस्तेमाल करना मुझे पसंद है

  • ऐसे लेख पढ़कर एहसास होता है कि Linux को 20 साल से ज़्यादा रोज़ इस्तेमाल करने के बावजूद मैं अभी भी इसकी क्षमता का सिर्फ एक हिस्सा ही इस्तेमाल कर रहा हूँ। अच्छा लेख है

  • HN फिर से सुधरता हुआ लग रहा है
    उम्मीद है कि यह HN का walking ghost वाला दौर नहीं है

    • front page पर AI से जुड़े 3 लेख हैं, लेकिन उनमें से एक low-quality generated content की आलोचना करता है, इसलिए उम्मीद रखता हूँ
    • लगता है यह 7 साल पहले के slop से पहले वाले लेखों की तरफ लौटते हुए recover कर रहा है

  • जो लोग nmon नहीं जानते, वे इसे भी एक बार देख सकते हैं
    h दबाने पर available monitors की list आती है, फिर दबाने पर गायब हो जाती है, और q से exit होता है
    https://nmon.sourceforge.io/pmwiki.php
    खासकर d और D keys से दिखने वाला disk throughput और I/O काफी उपयोगी है

    • काम पर इस्तेमाल होने वाली AIX machines से इसके बारे में पता चला, और topas भी याद आता है
    • यह बहुत उपयोगी tool है, इसलिए जिन भी machines पर मेरा control है, उन सब पर install करता हूँ
      Wide CPU usage graph बड़ी core count को आसानी से handle करता है, यह अच्छा है

  • *top जैसी चीज़ों से अलग usage style के तौर पर, मुझे शांत ps-style differential reporting और vmstat जैसी system-wide reporting ज्यादा पसंद आने लगी है
    इस तरह सब कुछ terminal scrollback buffer में रह जाता है: https://github.com/c-blake/procs
    यह असामान्य रूप से efficient और expressive Nim language में लिखा गया है

  • मैंने इस लेख को 2016 से bookmark कर रखा है, और कई वर्षों में कई बार वापस reference के लिए देखा है