Linux troubleshooting: server গোলমাল করলে যে কমান্ড চালাবেন
Server ধীর বা অ্যাপ বন্ধ হলে এই কমান্ডগুলো ক্রমে চালান: load, memory, disk, process, port, log, network।
Server গোলমাল করলে অনেকে ঘাবড়ে সব restart করে দেন। শান্ত পথ হলো আগে দেখা: কয়েকটি read-only কমান্ডের ক্রম বলে দেয় সমস্যা CPU, memory, disk, বন্ধ হওয়া process, বন্ধ port নাকি network-এর। নিচের সব কমান্ড শুধু তথ্য পড়ে, তাই চালু server-এ চালানো নিরাপদ। নমুনা আউটপুট উদাহরণমাত্র: আপনার সংখ্যা আলাদা হবে। কমান্ডগুলো নিজে প্রকাশের আগে একটি Linux server-এ যাচাই করা হয়েছে (lsof সব সিস্টেমে ডিফল্ট থাকে না)।
সময় বাঁচানো ক্রম
১. Server চালু ও চাপে আছে কি? (uptime)
২. Memory শেষ? (free -h)
৩. Disk ভরা? (df -h, du)
৪. কী resource খাচ্ছে? (top, ps)
৫. অ্যাপ port-এ শুনছে? (ss -ltnp)
৬. Log কী বলছে? (journalctl)
৭. Network-ই কি সমস্যা? (ping, curl, dig)
১. Load: uptime
$ uptime
03:08:23 up 30 days, 18:00, 4 users, load average: 0.72, 0.61, 0.42
তিনটি load average শেষ ১, ৫ ও ১৫ মিনিটের। এগুলো CPU core-এর সংখ্যার (nproc) সঙ্গে তুলনা করুন। ৪ core মেশিনে load ৪ মানে পুরো ব্যস্ত, ৪-এর অনেক ওপরে মানে process লাইনে দাঁড়িয়ে। ১ মিনিটের সংখ্যা ১৫ মিনিটের চেয়ে অনেক বেশি হলে সমস্যা নতুন। ধীর disk-এর জন্য অপেক্ষাতেও high load হতে পারে, শুধু CPU-তে নয়।
২. Memory: free -h
$ free -h
total used free shared buff/cache available
Mem: 5.8Gi 3.0Gi 493Mi 46Mi 2.6Gi 2.8Gi
free কম দেখে ঘাবড়াবেন না। Linux ফাঁকা memory cache হিসেবে ব্যবহার করে (buff/cache) এবং দরকারে ফেরত দেয়। available দেখুন: নতুন প্রোগ্রাম যা ব্যবহার করতে পারবে তার আনুমানিক পরিমাণ। available শূন্যের কাছে ও swap বেশি ব্যবহৃত হলে আসল memory সমস্যা। Kernel কিছু মেরে ফেলেছে কি না দেখুন: journalctl -k | grep -i "out of memory" (OOM killer)।
৩. Disk: df -h ও du
$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda2 79G 56G 19G 75% /
$ sudo du -xh /var --max-depth=1 | sort -h | tail -5
Disk ভরলে অদ্ভুত ব্যর্থতা হয়: database লেখা প্রত্যাখ্যান করে, log থেমে যায়, deploy ব্যর্থ হয়। df প্রতিটি filesystem দেখায়; du খোঁজে কোন folder বড় (-x এক filesystem-এ থাকে, sort -h মানুষের পড়ার আকার সাজায়)। সাধারণ দোষী: log, Docker image ও পুরোনো backup। df -i দিয়ে inode-ও দেখুন: জায়গা থাকতেও ফাইল-এন্ট্রি শেষ হতে পারে।
৪. Process: top ও ps
$ ps aux --sort=-%mem | head -5
$ ps aux --sort=-%cpu | head -5
$ top # M চাপলে memory, P চাপলে CPU অনুযায়ী সাজে, q দিয়ে বের হন
এগুলো সবচেয়ে বেশি memory ও CPU ব্যবহারকারী দেখায়। PID (process id) ও কমান্ড লিখে রাখুন। top-এর CPU লাইনে wa মানে disk-এর জন্য অপেক্ষার সময়। D অবস্থার process I/O-তে আটকে, Z অবস্থার process zombie। প্রথমেই kill -9 দেবেন না। সাধারণ kill PID (SIGTERM) চেষ্টা করুন যাতে প্রোগ্রাম পরিষ্কারভাবে বন্ধ হতে পারে; সাড়া না দিলে তবেই -9।
৫. Port: ss
$ sudo ss -ltnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=812))
LISTEN 0 4096 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=2056))
-l শোনা socket, -t TCP, -n সংখ্যায়, -p process। অ্যাপ 3000 port-এ থাকার কথা কিন্তু নেই মানে সেটি চলছে না বা crash করেছে। ঠিকানাও পড়ুন: 127.0.0.1:3000 শুধু এই মেশিন থেকে পৌঁছানো যায়, আর 0.0.0.0:3000 বাইরে থেকেও। 0.0.0.0-এ শোনা database firewall দিয়ে সুরক্ষিত বা localhost-এ বাঁধা থাকা উচিত। এই দ্রুত পরীক্ষা নিরাপত্তার অভ্যাসও: আপনার server-এ কী শুনছে জানুন।
৬. Log: journalctl
$ journalctl -u myapp -n 100 --no-pager # এক service-এর শেষ ১০০ লাইন
$ journalctl -u myapp -f # সরাসরি অনুসরণ
$ journalctl -p err --since "1 hour ago" # শেষ ১ ঘণ্টার শুধু error
$ systemctl status myapp # অবস্থা, exit code ও সাম্প্রতিক log লাইন
Log সাধারণত আসল কারণ বলে: অনুপস্থিত environment variable, প্রত্যাখ্যাত database connection, অনুমতির error। শুধু শেষ লাইন নয়, crash-এর পরের প্রথম error পড়ুন। systemd-র বাইরের ফাইলের জন্য tail -f /var/log/nginx/error.log।
৭. Network: ping, curl, dig
$ curl -I https://example.com # header ও status code
$ curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
$ dig +short example.com # DNS resolve হচ্ছে?
$ ip -brief addr # interface ও ঠিকানা
স্তর আলাদা করুন: dig ব্যর্থ হলে DNS; DNS চললে কিন্তু curl timeout হলে routing বা firewall; curl সংযুক্ত হয়ে 502 দিলে proxy-র পেছনের অ্যাপ বন্ধ। ping ইচ্ছা করে বন্ধ থাকতে পারে, তাই শুধু ping ব্যর্থ হলে বেশি কিছু প্রমাণ হয় না।
সহজ সিদ্ধান্ত নির্দেশিকা
| লক্ষণ | আগে দেখুন |
|---|---|
| পুরো server ধীর | uptime, top, free -h |
| সাইট 502 বা 503 দিচ্ছে | systemctl status, journalctl -u, ss -ltnp |
| ফাইল লেখা বা database ব্যর্থ | df -h, df -i |
| অ্যাপ হঠাৎ মারা যাচ্ছে | out of memory-র জন্য journalctl -k |
| স্থানীয়ভাবে চলে, বাইরে থেকে না | ss -ltnp-এর ঠিকানা, firewall, বাইরে থেকে curl |
| deploy-এর পর ধীর | log, তারপর আগের সংস্করণের সঙ্গে তুলনা |
সহায়ক অভ্যাস
- একবারে একটি জিনিস বদলান এবং লিখে রাখুন।
- প্রথম ধাপে restart করবেন না। restart memory-র অবস্থা ও process তালিকার মতো প্রমাণ মুছে দেয়। আগে log পড়ুন।
- ঠিক করার আগে দরকারি আউটপুট সংরক্ষণ করুন:
journalctl -u myapp --since "1 hour ago" > issue.log। - ব্যবহারকারীর আগে সমস্যা ধরতে monitoring ও alert বসান।
- প্রতিটি service-এর জন্য ছোট runbook লিখুন: কীভাবে দেখবেন, restart করবেন ও rollback করবেন।
মূল কথা: স্তরে স্তরে troubleshoot করুন, আগে read-only: load, memory, disk, process, port, log, network। উত্তর সাধারণত log-এ থাকে, আর শান্ত checklist ঘাবড়ানো restart-এর চেয়ে ভালো।
Linux ও DevOps সিরিজ, পর্ব ৩ (প্রতিদিনের পরিচালনা): 2 নম্বর (মোট 5)। আগের লেখা: Docker Compose: একটি ফাইলে multi-container অ্যাপ চালান.
