۱۰ دستور ضروری لینوکس که هر برنامه‌نویس باید بداند

ورود به ترمینال برای بسیاری از توسعه‌دهندگان لحظه‌ای است که سرعت کارشان چند برابر می‌شود. خبر خوب این است که برای کار روزمره روی سرور، به حفظ کردن صدها دستور نیازی ندارید؛ حدود ده دستور، نود درصد کارهای واقعی را انجام می‌دهند. در این نوشته همان ده دستور را با دلیل استفاده، حالت‌های رایج و هشدارهای ایمنی می‌بینید.

۱. پیدا کردن فایل‌ها با find

وقتی نمی‌دانید فایل کجاست، find سریع‌ترین راه است. برای پیدا کردن فایل‌های لاگ که در ۲۴ ساعت گذشته تغییر کرده‌اند:

find . -type f -name "*.log" -mtime -1

چند حالت پرکاربرد دیگر:

find /var/www -type f -size +50M            # فایل‌های بزرگ‌تر از ۵۰ مگابایت
find . -name "*.tmp" -delete                # حذف فایل‌های موقت (احتیاط کنید)
find . -type f -newermt "2026-01-01"        # فایل‌های تغییرکرده بعد از یک تاریخ

قبل از اضافه کردن -delete یا -exec، همان دستور را بدون آن‌ها اجرا کنید تا ببینید روی چه فایل‌هایی اثر می‌گذارد.

۲. دیدن انتهای فایل در حال رشد با tail

برای عیب‌یابی زنده، tail -f بهترین ابزار است؛ فایل را باز نگه می‌دارد و خطوط تازه را نشان می‌دهد:

tail -f /var/log/nginx/error.log
tail -n 100 -f /var/log/app.log | grep -i "error"

اگر خروجی بیش از حد شلوغ شد، آن را با grep محدود کنید. برای خروج از حالت -f ترکیب Ctrl+C کافی است.

۳. جست‌وجوی متن در فایل‌ها با grep

grep پاسخ سؤال «این متن کجای پروژه استفاده شده» است:

grep -rn "TODO" ./src                    # بازگشتی با شماره خط
grep -rl "DATABASE_URL" .                # فقط نام فایل‌ها
grep -rn --exclude-dir=node_modules "apiKey" .

در پروژه‌های بزرگ، همیشه پوشه‌های سنگین مثل node_modules و .git را کنار بگذارید تا جست‌وجو سریع بماند.

۴. بررسی فضا و پیدا کردن پوشه‌های سنگین

پر شدن دیسک یکی از دلایل رایج از کار افتادن سرویس‌هاست. اول وضعیت کلی، بعد مقصر اصلی:

df -h                       # فضای هر پارتیشن
du -sh * | sort -h | tail   # سنگین‌ترین پوشه‌های همین مسیر
du -sh /var/log/* | sort -h | tail

اگر فایل‌های لاگ مقصر بودند، اول با logrotate تنظیمشان کنید و بعد حذف؛ حذف بدون تنظیم، مشکل را چند هفته بعد برمی‌گرداند.

۵. دیدن پروسه‌های مصرف‌کننده منابع

سرور کند شده و می‌خواهید بدانید چه چیزی منابع را می‌خورد:

ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head
top -o %MEM

برای پیدا کردن اینکه چه چیزی روی یک پورت نشسته است:

ss -tulpn | grep :3000

۶. مدیریت دسترسی با chmod و chown

خطای «Permission denied» تقریباً همیشه یکی از این دو دستور را می‌خواهد:

chown -R www-data:www-data /var/www/app
chmod 640 .env
chmod -R u+rwX,go-rwx ./secrets

قاعده ساده: برای فایل حساس دسترسی 600 یا 640، برای پوشه 755، و هیچ‌وقت 777 — این عدد یعنی هر کاربری می‌تواند بنویسد. همچنین کلید SSH باید 600 باشد وگرنه ارتباط رد می‌شود.

۷. کنترل سرویس‌ها با systemctl

systemctl status nginx
systemctl restart app
systemctl enable app        # اجرا بعد از ری‌استارت سرور
systemctl list-units --failed

list-units --failed معمولاً اولین دستوری است که پس از ری‌استارت سرور باید بزنید؛ فهرست سرویس‌های خراب را یک‌جا نشان می‌دهد.

۸. خواندن لاگ سرویس‌ها با journalctl

journalctl -u app --since "1 hour ago"
journalctl -u app -f
journalctl -p err -b          # فقط خطاها، از آخرین بوت

این دستور به شما می‌گوید سرویس با چه خطایی بالا نیامده؛ چیزی که در systemctl status فقط خلاصه‌اش را می‌بینید.

۹. اتصال امن با ssh

ssh -i ~/.ssh/id_ed25519 user@server
ssh -L 5432:localhost:5432 user@server     # تونل به پایگاه داده

برای کار طولانی، tmux یا screen را داخل سرور اجرا کنید؛ اگر اتصال قطع شود، پردازش شما از بین نمی‌رود.

۱۰. بررسی سریع سرور با curl

curl -I https://example.com          # فقط هدرها و کد وضعیت
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com
curl -X POST -H "Content-Type: application/json" -d '{"a":1}' https://api.example.com

این دستور هم برای بررسی سلامت سرویس بعد از انتشار و هم برای تست API بدون واسطه مرورگر کاربرد دارد.

پنج دستور تکمیلی که زیاد به کار می‌آیند

• rsync -avz ./dist/ user@server:/var/www/app/ برای انتشار فایل‌ها با انتقال تفاضلی
• tar -czf backup.tar.gz ./data برای بسته‌بندی و پشتیبان‌گیری سریع
• scp file user@server:/tmp/ برای انتقال یک فایل
• watch -n 2 'systemctl status app' برای پایش مداوم یک وضعیت
• history | grep ssh برای پیدا کردن دستوری که قبلاً زده‌اید

یک سناریوی واقعی: سرویس بالا نمی‌آید

۱. systemctl status app را بزنید تا وضعیت و آخرین خط لاگ را ببینید. ۲. اگر دلیل روشن نبود، journalctl -u app -n 100 را بخوانید. ۳. با df -h بررسی کنید دیسک پر نشده باشد. ۴. با ss -tulpn | grep :3000 ببینید پورت توسط پروسه دیگری اشغال نشده باشد. ۵. اگر خطای دسترسی بود، مالکیت فایل‌ها را با chown درست کنید. ۶. پس از رفع، systemctl restart app و سپس curl -I برای تأیید سلامت.

قاعده طلایی کار با سرور

هیچ‌وقت دستوری را بدون فهمیدن روی سرور production اجرا نکنید. سه عادت ساده جلوی فاجعه را می‌گیرد: قبل از دستورهای مخرب یک پشتیبان بگیرید، مسیرها را با pwd و ls بررسی کنید، و دستورهایی مثل rm -rf را با مسیر مطلق و دقت زیاد بنویسید. برای تمرین، همه‌ی این دستورات را روی یک سرور آزمایشی یا ماشین مجازی تکرار کنید.

جمع‌بندی

به جای حفظ کردن صدها گزینه، با همین ده دستور راحت شوید؛ بقیه را هنگام نیاز با man ببینید. اگر می‌خواهید این کارها را با تمرین و روی سناریوهای واقعی یاد بگیرید، یک سرور آزمایشی بگیرید و همین دستورها را تمرین کنید؛ هر دستور را با man و یک مثال واقعی بسنجید. برای مرور سریع هم یک چیت‌شیت از پرکاربردترین دستورها برای خودتان بسازید.