لینوکس برای برنامه‌نویس بک‌اندLinux for the Backend Engineer

یک روز صبح تلفن زنگ می‌زند: «سرویس بالا نمی‌آید.» IDE کمکت نمی‌کند، debugger هم نه. تنها چیزی که داری یک ترمینال سیاه است و یک prompt که منتظر است — و در آن لحظه فاصلهٔ بین یک برنامه‌نویس مید‌لول و یک سنیور دقیقاً همین است: سنیور می‌داند در سی ثانیهٔ اول چه تایپ کند.

این فصل لینوکس را نه به‌عنوان «سیستم‌عامل» بلکه به‌عنوان ابزار کار روزانهٔ یک بک‌اند آموزش می‌دهد؛ از صفر تا جایی که بتوانی روی سروری که JVM رویش در حال خفه شدن است بدون ترس کار کنی.

۱. مدل ذهنی: همه‌چیز فایل است

در ویندوز چند درخت داری (C:\، D:\)؛ در لینوکس فقط یک درخت با ریشهٔ / و دیسک دوم یا اشتراک شبکه «mount» می‌شود، یعنی به شاخه‌ای از همین درخت وصل می‌شود.

«everything is a file» یعنی کرنل تقریباً همهٔ منابع را پشت یک واسط یکسان (باز کن، بخوان، بنویس، ببند) عرضه می‌کند. به همین دلیل grep ناگهان ابزار مانیتورینگ می‌شود: grep VmRSS /proc/1234/status یعنی «مصرف حافظهٔ فیزیکی پروسهٔ ۱۲۳۴»، بدون هیچ agent و داشبوردی.

استاندارد FHS تعیین می‌کند چه چیزی کجا برود؛ دانستنش یعنی روی هر توزیعی گم نشوی.

مسیر مطلق با / شروع می‌شود و همیشه یک معنی دارد؛ مسیر نسبی از پوشهٔ فعلی حساب می‌شود. . پوشهٔ فعلی، .. یکی بالاتر، ~ خانهٔ کاربر، cd - پوشهٔ قبلی.

در اسکریپت همیشه مسیر مطلق بنویس. اگر در cd logs && rm -rf * دستور cd شکست بخورد، حذف در پوشهٔ فعلی — که ممکن است / باشد — اجرا می‌شود. یا مسیر مطلق بنویس یا cd logs || exit 1.

۲. پیمایش و نگاه کردن

pwd ; cd /var/log ; cd .. ; cd -    # کجا هستم / رفت و برگشت
ls -lah               # بلند + مخفی‌ها + اندازهٔ خوانا   |  ls -lt  جدیدترین اول
stat application.yml  # inode، دسترسی octal، زمان‌ها     |  file app.jar  نوع واقعی فایل
readlink -f $(which java)   # مسیر واقعی بعد از باز کردن symlink ها

خروجی ls -l را باید ستون‌به‌ستون بخوانی:

-rw-r--r--  1 appuser appgroup  20480 Jul 30 11:02 application.yml

کاراکتر اول نوع است (- فایل، d دایرکتوری، l symlink، s سوکت)، نه کاراکتر بعد بیت‌های دسترسی، 1 تعداد hard link، سپس مالک، گروه، اندازه و زمان آخرین تغییر.

هیچ‌کس همهٔ فلگ‌ها را حفظ نیست؛ man و --help بخشی از مهارت‌اند. در مصاحبه هم «فلگ دقیقش را با man چک می‌کنم ولی منطقش این است» بهتر از حدس زدن است.

۳. خواندن و جابه‌جا کردن فایل‌ها

less app.log            # مرورگر صفحه‌ای: q خروج، / جستجو، G انتها
head -n 50 app.log ; tail -n 200 app.log ; tail -F app.log   # F: بعد از rotate هم ادامه بده
cp -a conf/ backup/     # archive: حفظ دسترسی، مالک و زمان‌ها
mkdir -p /opt/myapp/logs/2026

روی production cat نزن: روی لاگ چندگیگابایتی کل فایل را به ترمینال می‌ریزد و I/O سرور را تحت فشار می‌گذارد. و برای لاگی که rotate می‌شود tail -F بنویس نه tail -f؛ با -f کوچک بعد از rotate به فایلِ حذف‌شده چسبیده می‌مانی و فکر می‌کنی سرویس ساکت شده است.

لینک سخت و لینک نمادین

ln  /opt/app/v2.1.0/app.jar /opt/app/hard.jar   # hard link: نام دوم برای همان inode
ln -s /opt/app/v2.1.0 /opt/app/current           # symlink: فایلی که یک مسیر را نگه می‌دارد

۴. دسترسی‌ها و مالکیت — عمیق

flowchart TD
  A["Process opens a file"] --> B{"UID == file owner?"}
  B -- yes --> C["Use OWNER bits only"]
  B -- no --> D{"File GID in process groups?"}
  D -- yes --> E["Use GROUP bits only"]
  D -- no --> F["Use OTHER bits only"]
  C --> G{"Access allowed?"}
  E --> G
  F --> G
  G -- yes --> H["open() succeeds"]
  G -- no --> I["EACCES: Permission denied"]

نتیجهٔ ظریف آن توقف: اگر مالک فایل باشی و بیت owner اجازهٔ خواندن ندهد، عضو بودن در گروه نجاتت نمی‌دهد. chmod 077 file یعنی مالک هیچ دسترسی ندارد ولی بقیه همه‌چیز دارند.

هر دسته سه بیت دارد: r (۴)، w (۲)، x (۱) — پس 7 = rwx، 6 = rw-، 5 = r-x، 4 = r--. یعنی chmod 640 secrets.properties = مالک بخواند و بنویسد، گروه فقط بخواند، بقیه هیچ.

chmod 750 start.sh ; chmod u+x start.sh ; chmod g-w,o-rwx config.yml
chmod -R u=rwX,g=rX,o= /opt/myapp     # X بزرگ: بیت اجرا فقط به دایرکتوری‌ها
chown -R appuser:appgroup /opt/myapp
namei -l /opt/myapp/conf/app.yml      # کدام سطح از مسیر دسترسی را قطع کرده؟

umask و بیت‌های ویژه

فایل‌های جدید با پایهٔ 666 و دایرکتوری‌ها با 777 ساخته می‌شوند و بیت‌های umask از آن کم می‌شود؛ با umask 022 یعنی فایل 644 و دایرکتوری 755.

ls -ld /tmp                    # drwxrwxrwt  <- t یعنی sticky
chmod 2775 /srv/shared         # setgid روی پوشهٔ اشتراکی تیم
find / -perm -4000 -type f 2>/dev/null   # ممیزی: چه چیزهایی setuid هستند؟
setfacl -m u:reportuser:r-x /srv/data    # وقتی سه دسته کافی نیست

/tmp بهترین مثال sticky bit است: همه می‌نویسند، ولی t نمی‌گذارد کاربر A فایل کاربر B را پاک کند.

تلهٔ umask: اگر umask را در ~/.bashrc بگذاری سرویس systemd آن را نمی‌بیند. در unit بنویس UMask=0027، وگرنه لاگ‌های اپ ممکن است با 644 ساخته شوند و هر کاربری روی سرور محتوایشان را بخواند.

۵. کاربر، گروه و sudo

id ; id appuser ; groups appuser
getent passwd appuser            # از passwd + LDAP و ... می‌خواند

/etc/passwd نام و UID و شل را دارد (خواندنی برای همه؛ رمز اینجا نیست)، /etc/shadow هش رمزها را (فقط root) و /etc/group گروه‌ها را.

sudo groupadd --system appgroup
sudo useradd --system --gid appgroup --home-dir /opt/myapp \
     --no-create-home --shell /usr/sbin/nologin appuser
sudo usermod -aG docker deployer     # -a حیاتی است
sudo -u appuser ls -l /opt           # اجرای یک دستور به‌نام کاربر دیگر
sudo -l ; sudo visudo                # مجوزهای من / ویرایش امن sudoers

usermod -G بدون -a خطرناک است: کاربر را از همهٔ گروه‌های ثانویهٔ دیگر — از جمله sudo یا wheel — بیرون می‌اندازد. همیشه -aG. ضمناً عضویت جدید در نشست‌های باز اعمال نمی‌شود؛ باید دوباره وارد شوی.

کمترین دسترسی، عملی: به‌جای ALL=(ALL) NOPASSWD:ALL به deployer، در /etc/sudoers.d/deployer فقط همان چند دستور را مجاز کن:

deployer ALL=(root) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

فایل‌های /etc/sudoers.d/ باید 440 باشند و با visudo -c -f <file> اعتبارسنجی شوند؛ یک خطای نحوی می‌تواند sudo را برای همه از کار بیندازد.

۶. پروسه‌ها و سیگنال‌ها

ps -ef --forest                  # درخت والد-فرزند
ps -eo pid,ppid,user,%cpu,%mem,rss,etime,cmd --sort=-%cpu | head -15
pgrep -af java                   # PID + خط فرمان کامل
top -p $(pgrep -d, -f myapp.jar)

خواندن top برای یک پروسهٔ جاوا:

• %CPU می‌تواند از ۱۰۰ بیشتر باشد؛ ۱۰۰ یعنی یک هستهٔ کامل، پس 760 روی ماشین ۸ هسته‌ای یعنی تقریباً اشباع.
• RES = حافظهٔ فیزیکی واقعی و از -Xmx بزرگ‌تر است و باید باشد: heap + metaspace + code cache + پشتهٔ نخ‌ها + direct buffer + خود JVM. VIRT برای JVM تقریباً بی‌معنی است.
• کلید 1 در top هستهٔ به هسته را نشان می‌دهد و H به‌جای پروسه، نخ‌ها را.

stateDiagram-v2
  [*] --> R: fork + exec
  R: R (running / runnable)
  S: S (interruptible sleep)
  D: D (uninterruptible sleep, disk I/O)
  Z: Z (zombie, exited, not reaped)
  R --> S: waits for I/O or lock
  S --> R: event arrives
  R --> D: blocking disk or NFS I/O
  D --> R: I/O completes
  R --> Z: exit()
  Z --> [*]: parent calls wait()

D و zombie: پروسه‌ای در وضعیت D با kill -9 هم نمی‌میرد چون منتظر I/O است (دیسک کند یا NFS قطع‌شده)؛ راه‌حل رفع I/O است نه kill. پروسهٔ Z (<defunct>) مرده و فقط منتظر است والد کد خروجش را بخواند؛ حافظه مصرف نمی‌کند ولی انبوه شدنشان یعنی والد باگ دارد. در کانتینر اگر JVM را PID 1 اجرا کنی و فرزند بسازد zombie جمع می‌شود — به همین دلیل --init یا tini (فصل containers-jvm).

kill -TERM 1234 ; kill -9 1234 ; kill -3 1234 ; pkill -f 'myapp.jar'
./long-task.sh &  ; jobs ; fg %1 ; disown -h %1   # job control
nohup ./run.sh > out.log 2>&1 &                   # مقاوم به SIGHUP

۷. systemd

systemd سیستم init مدرن است — PID 1 که بقیه را راه‌اندازی و بر آن‌ها نظارت می‌کند؛ واحد کارش «unit» است.

# /etc/systemd/system/myapp.service
[Unit]
Description=My Backend Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=appuser
Group=appgroup
WorkingDirectory=/opt/myapp
EnvironmentFile=-/etc/myapp/env
ExecStart=/usr/bin/java -XX:MaxRAMPercentage=70 \
  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/myapp \
  -Xlog:gc*:file=/var/log/myapp/gc.log:time,uptime,level,tags:filecount=5,filesize=20M \
  -jar /opt/myapp/app.jar
SuccessExitStatus=143
Restart=on-failure
TimeoutStopSec=60
LimitNOFILE=65535
UMask=0027
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

چهار نکتهٔ حرفه‌ای در همین فایل: SuccessExitStatus=143 چون JVM بعد از SIGTERM با کد 128+15=143 خارج می‌شود و بدون آن systemd هر توقف عادی را «شکست» گزارش می‌کند؛ TimeoutStopSec مهلت graceful shutdown قبل از SIGKILL؛ LimitNOFILE سقف file descriptor؛ و NoNewPrivileges سخت‌سازی رایگان.

sequenceDiagram
  participant Admin
  participant systemd
  participant JVM
  Admin->>systemd: systemctl start myapp
  systemd->>JVM: fork + exec ExecStart
  Note over systemd,JVM: stdout/stderr piped to journald
  Admin->>systemd: systemctl stop myapp
  systemd->>JVM: SIGTERM
  JVM->>JVM: run shutdown hooks
  JVM-->>systemd: exit 143
  Note over systemd: after TimeoutStopSec -> SIGKILL

sudo systemctl daemon-reload            # بعد از هر تغییر unit — فراموشش نکن
sudo systemctl enable --now myapp
systemctl cat myapp                     # محتوای واقعی unit + drop-in ها
systemctl show myapp -p LimitNOFILE -p MemoryMax
systemctl list-units --type=service --state=failed
sudo systemctl edit myapp               # drop-in override بساز (ترجیح بده)

journalctl -u myapp -f
journalctl -u myapp --since "10 min ago" -p err --no-pager
journalctl -k --since "1 hour ago"      # لاگ کرنل — اینجا OOM killer را می‌بینی

drop-in به‌جای ویرایش unit اصلی: systemctl edit myapp فایلی در /etc/systemd/system/myapp.service.d/override.conf می‌سازد؛ تغییرات با به‌روزرسانی بسته پاک نمی‌شوند و در systemctl cat دیده می‌شوند. برای بازنویسی یک لیست مثل ExecStart اول باید خالی‌اش کنی (ExecStart=) و بعد مقدار جدید بدهی.

ماندگاری لاگ: روی بعضی توزیع‌ها journald به‌طور پیش‌فرض فقط در حافظه (/run/log/journal) می‌نویسد و با ریبوت همه‌چیز می‌رود. اگر بعد از یک کرش لاگ لازم داری، Storage=persistent را در /etc/systemd/journald.conf تنظیم کن.

۸. Pipe، redirection و exit code

هر پروسه با سه جریان استاندارد شروع می‌شود: 0 = stdin، 1 = stdout، 2 = stderr.

cmd > out.txt          # stdout به فایل (بازنویسی)   |  cmd >> out.txt  افزودن
cmd 2> err.txt         # فقط stderr
cmd > all.txt 2>&1     # هر دو به یک فایل
cmd | tee out.txt      # هم روی صفحه هم در فایل      |  cmd 2>/dev/null  دور ریختن خطاها

هر دستور یک exit code برمی‌گرداند: 0 موفق، هر چیز دیگر خطا. cmd1 && cmd2 یعنی دومی فقط در صورت موفقیت اولی و || برعکس. قراردادها: 126 قابل اجرا نبود، 127 دستور پیدا نشد، 130 با Ctrl+C کشته شد، و 128+N یعنی با سیگنال N کشته شده — پس 137 یعنی SIGKILL، عددی که بعداً داستان OOM killer را لو می‌دهد.

تلهٔ exit code در pipeline: set -e جلوی ادامهٔ اسکریپت را می‌گیرد، اما در pipeline فقط کد آخرین دستور مهم است؛ false | true موفق حساب می‌شود. چاره set -o pipefail است.

۹. ابزارهای متنی: شکار واقعی در لاگ

grep -rn 'jdbc:postgresql' /opt/myapp        # بازگشتی + شمارهٔ خط
grep -c ERROR app.log ; grep -v DEBUG app.log     # شمارش / نفی
grep -A5 -B5 'NullPointerException' app.log  # ۵ خط قبل و بعد
grep -E 'ERROR|FATAL|Exception' app.log      # regex توسعه‌یافته
grep -o 'traceId=[a-f0-9]*' app.log          # فقط بخش تطبیق‌یافته
grep -rl 'password' /etc --include='*.conf'  # فقط نام فایل‌ها
zgrep -h -F 'traceId=8f3ac91b' /var/log/myapp/app.log*   # شامل فایل‌های gz

برای یک رشتهٔ ثابت (UUID، IP، traceId) از grep -F استفاده کن: هم سریع‌تر است، هم کاراکترهایی مثل . و [ دیگر به‌عنوان regex تفسیر نمی‌شوند — grep '10.0.0.1' عملاً 10x0y0z1 را هم می‌گیرد.

awk '{print $1, $7}' access.log            # ستون‌های دلخواه
awk -F: '{print $1}' /etc/passwd           # جداکنندهٔ دلخواه
awk '$9 >= 500' access.log                 # فیلتر شرطی روی ستون
sed -n '100,200p' app.log                  # فقط خطوط ۱۰۰ تا ۲۰۰
sed 's/password=[^ ]*/password=***/g' app.log     # ماسک کردن
sed -i.bak 's/8080/9090/g' application.properties # ویرایش درجا با پشتیبان
sort -k3 -n -r data.txt ; sort -u list.txt ; uniq -c ; wc -l app.log

دو مثال واقعی

# ۱) پرتکرارترین استثناها در یک ساعت گذشته
journalctl -u myapp --since "1 hour ago" -o cat \
  | grep -oE '[A-Za-z.]+(Exception|Error)' | sort | uniq -c | sort -rn | head -10

# ۲) ده IP پرترافیک
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

find /var/log -name '*.log' -mtime +7 -size +100M         # قدیمی و بزرگ
find /var/log -name '*.gz' -mtime +30 -exec rm -f {} +    # کارآمدتر از \;
find /opt -type f -name '*.jar' -print0 | xargs -0 ls -lh
find / -xdev -type f -size +500M 2>/dev/null | head       # -xdev: از مرز فایل‌سیستم رد نشو

\; در برابر +: حالت \; برای هر فایل یک پروسهٔ جدید می‌سازد و روی صد هزار فایل فاجعه است؛ + همهٔ نام‌ها را یک‌جا پاس می‌دهد. و اگر نام فایلی فاصله داشته باشد xargs معمولی خط را می‌شکند؛ همیشه -print0 | xargs -0. قبل از هر -delete اول همان دستور را با -print اجرا کن.

۱۰. آرشیو و انتقال

tar -czf logs.tar.gz /var/log/myapp/      # ساخت (c) gzip (z) file (f)
tar -xzf logs.tar.gz -C /tmp/restore      # استخراج  |  tar -tzf ...  فهرست بدون استخراج
zcat huge.log.gz | head                   # بدون باز کردن   |  zstd -19 huge.log
scp app.jar deployer@server:/opt/myapp/
rsync -avzP --delete --exclude '*.tmp' build/ deployer@server:/opt/myapp/

چرا rsync بهتر از scp است: فقط تفاوت‌ها را می‌فرستد، فشرده می‌کند، در قطعی ادامه می‌دهد، دسترسی‌ها را حفظ می‌کند و --dry-run دارد. تلهٔ کلاسیکش اسلش پایانی مبدأ است: rsync -a src/ dst/ محتویات src را داخل dst می‌ریزد ولی rsync -a src dst/ خودِ پوشه را می‌سازد. و --delete بدون --dry-run روی مسیر اشتباه یک ابزار حذف انبوه است.

۱۱. دیسک و حافظه

df -h ; df -i                             # فضا و inode — دومی را فراموش نکن
du -h --max-depth=1 /var | sort -h | tail -20
lsof +L1 ; lsof -nP | grep '(deleted)'    # فایل‌های حذف‌شدهٔ هنوز باز
free -h ; vmstat 1 5 ; iostat -xz 1
lsof -p 1234 ; lsof -i :8080 ; fuser -v /var/log/app.log

خواندن درست free -h: used مصرف واقعی برنامه‌هاست، buff/cache کش صفحات کرنل است که به محض نیاز آزاد می‌شود، و available تنها عددی است که باید نگاه کنی. کم بودن free مشکل نیست؛ لینوکس عمداً RAM بلااستفاده را کش می‌کند.

۱۲. شبکه

ip -br a ; ip r ; ip neigh
ss -ltnp                    # سوکت‌های listen، TCP، عددی، با پروسه
ss -tanp                    # همهٔ اتصالات TCP    |   ss -s   خلاصهٔ آماری
ss -tn state established '( dport = :5432 )'   # اتصالات باز به دیتابیس

curl -I https://api.example.com/health   # فقط هدرها  |  -v کل مکالمه شامل TLS
curl -X POST https://api.example.com/orders \
     -H 'Content-Type: application/json' -H 'Authorization: Bearer TOKEN' \
     -d '{"sku":"A-1","qty":2}'
curl --resolve api.example.com:443:10.0.0.7 https://api.example.com/health   # دور زدن DNS
curl -f -sS --max-time 5 --retry 3 https://api.example.com/health

curl -s -o /dev/null -w 'code=%{http_code} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://api.example.com/health

dig api.example.com +short ; dig @8.8.8.8 api.example.com
getent hosts api.example.com     # همان مسیری که اپ می‌رود (nsswitch)
nc -zv -w 3 db.internal 5432     # آیا پورت باز است؟
mtr -rwc 20 api.example.com      # traceroute + ping پیوسته
tcpdump -i any -nn port 5432 -c 20   # ۲۰ بستهٔ اول روی پورت دیتابیس

dig و اپ تو یک مسیر نمی‌روند: dig مستقیم با DNS حرف می‌زند و /etc/hosts را نادیده می‌گیرد، ولی اپ جاوا از resolver سیستم می‌رود که طبق /etc/nsswitch.conf اول hosts را می‌بیند؛ برای مسیر واقعی اپ از getent hosts استفاده کن. نکتهٔ JVM: networkaddress.cache.ttl در java.security تعیین می‌کند DNS چقدر داخل JVM کش شود — در محیط ابری مقدار طولانی یعنی اپ ساعت‌ها به یک IP مرده وصل می‌ماند.

یک درخواست HTTP از اپ تا سرویس بالادستی چهار مرحلهٔ شکست‌پذیر دارد — DNS، TCP، TLS و خودِ HTTP — و جدول زیر می‌گوید هر خطا کدام مرحله را متهم می‌کند.

برای وقتی که باید از سمت دیتابیس هم نگاه کنی، اتصالات فعال را مستقیم از موتور بپرس:

SELECT state, count(*) AS conns, max(now() - state_change) AS oldest
FROM pg_stat_activity
WHERE datname = current_database()
GROUP BY state
ORDER BY conns DESC;

-- معادل اوراکل: نشست‌ها از v$session
SELECT status, COUNT(*) AS conns, MAX(SYSDATE - logon_time) * 86400 AS oldest_sec
FROM v$session
WHERE type = 'USER'
GROUP BY status
ORDER BY conns DESC;

sudo ufw status numbered ; sudo ufw allow 22/tcp                 # Ubuntu/Debian
sudo ufw allow from 10.0.0.0/8 to any port 8080 proto tcp
sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload   # RHEL

قبل از ufw enable حتماً ufw allow 22/tcp بزن، وگرنه همان لحظه از سرور راه‌دور بیرون می‌افتی و راه برگشتی جز کنسول فیزیکی/ابری نداری. در کارهای پرریسک یک sleep 300 && ufw disable در پس‌زمینه به‌عنوان طناب نجات بگذار.

۱۳. SSH

ssh-keygen -t ed25519 -C "deploy@laptop" -f ~/.ssh/id_ed25519_deploy
ssh-copy-id -i ~/.ssh/id_ed25519_deploy.pub deployer@server
ssh deployer@server 'systemctl status myapp --no-pager'

چرا ed25519: کوتاه‌تر، سریع‌تر و رمزنگاری‌اش مدرن‌تر است. اگر مجبور به RSA بودی حداقل -b 4096 بده؛ DSA منسوخ و در OpenSSH جدید حذف شده است.

# ~/.ssh/config — بزرگ‌ترین صرفه‌جویی روزانه
Host bastion
    HostName bastion.example.com
    User deployer
    IdentityFile ~/.ssh/id_ed25519_deploy
    IdentitiesOnly yes

Host prod-*
    User appuser
    IdentityFile ~/.ssh/id_ed25519_prod
    ProxyJump bastion
    ServerAliveInterval 30

Host prod-db
    HostName 10.0.3.11
    LocalForward 15432 127.0.0.1:5432

حالا ssh prod-db هم از bastion رد می‌شود، هم کلید درست را می‌فرستد، هم پورت دیتابیس را روی localhost:15432 باز می‌کند.

flowchart LR
  L["Laptop 127.0.0.1:15432"] -->|encrypted SSH| B["Bastion host"]
  B -->|ProxyJump| P["prod-db host"]
  P -->|localhost:5432| D[("PostgreSQL")]

ssh -L 15432:127.0.0.1:5432 deployer@server    # local: پورت من -> سرویس آن‌طرف
ssh -R 9000:127.0.0.1:8080 deployer@server     # remote: پورت سرور -> سرویس من
ssh -N -f -L 15432:db.internal:5432 deployer@bastion   # بدون شل، در پس‌زمینه

سه اشتباه امنیتی رایج: اول، StrictHostKeyChecking=no همان محافظی است که جلوی man-in-the-middle را می‌گیرد؛ به‌جایش fingerprint سرورها را با ssh-keyscan از قبل در known_hosts بگذار. دوم، agent forwarding (-A) به سروری که مطمئن نیستی: هر کسی که آنجا root باشد از agent تو استفاده می‌کند — ProxyJump بهتر است چون کلید هرگز به سرور میانی نمی‌رود. سوم، ~/.ssh باید 700 و کلید خصوصی و authorized_keys باید 600 باشند؛ OpenSSH عمداً کلیدهای بازتر را رد می‌کند.

سخت‌سازی سمت سرور (بهتر است در فایلی داخل /etc/ssh/sshd_config.d/):

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups sshusers
MaxAuthTries 3

قبل از reload کردن sshd یک نشست دوم باز نگه دار. اول sudo sshd -t برای اعتبارسنجی بزن، بعد systemctl reload sshd، و ورود را از یک ترمینال دیگر تست کن؛ تنها بعد از موفقیت نشست اول را ببند.

۱۴. متغیرهای محیطی و profile

export APP_ENV=production      # برای این شل و فرزندانش
env | sort ; printenv JAVA_HOME ; which -a java
APP_ENV=staging ./run.sh       # فقط برای همین یک اجرا

نه cron و نه systemd، .bashrc را نمی‌خوانند — cron با PATH بسیار کوتاهی اجرا می‌شود و JAVA_HOME هم ندارد. در کارهای زمان‌بندی‌شده مسیر مطلق بنویس، متغیرها را صریح تعریف کن، یا در unit از EnvironmentFile= استفاده کن.

secret در متغیر محیطی امن نیست: مقدار متغیرهای یک پروسه در /proc/<pid>/environ خواندنی است، در systemctl show می‌آید، و اگر به‌صورت آرگومان خط فرمان پاس داده شود در ps برای هر کاربری دیده می‌شود. هرگز رمز را آرگومان نده؛ EnvironmentFile باید 600 و متعلق به root باشد؛ و برای production از secret manager استفاده کن.

۱۵. زمان‌بندی: cron و systemd timer

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

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=""

*/5 * * * * /usr/bin/flock -n /tmp/health.lock /opt/myapp/bin/healthcheck.sh >> /var/log/myapp/health.log 2>&1
30 2 * * *  /usr/bin/find /var/log/myapp -name '*.log' -mtime +14 -delete

سه تلهٔ همیشگی cron: اول، % به newline تبدیل می‌شود پس date +%Y-%m-%d می‌شکند و باید \% بنویسی. دوم، بدون redirect خروجی به ایمیل می‌رود و روی سرور بدون MTA ناپدید می‌شود — همیشه >> logfile 2>&1. سوم، کاری که هر ۵ دقیقه اجرا می‌شود و گاهی ۷ دقیقه طول می‌کشد روی خودش سوار می‌شود؛ با flock -n قفل بگذار.

# /etc/systemd/system/myapp-cleanup.timer
[Unit]
Description=Run log cleanup daily

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=300
Persistent=true
Unit=myapp-cleanup.service

[Install]
WantedBy=timers.target

sudo systemctl enable --now myapp-cleanup.timer ; systemctl list-timers --all
systemd-analyze calendar '*-*-* 02:30:00'     # اعتبارسنجی عبارت زمانی
sudo systemctl start myapp-cleanup.service    # اجرای دستی برای تست

۱۶. مدیریت بسته

sudo update-alternatives --config java     # Debian/Ubuntu — انتخاب JDK فعال
sudo alternatives --config java            # RHEL
readlink -f $(which java)                  # کدام JDK واقعاً اجرا می‌شود

apt upgrade را در ساعت کاری نزن: می‌تواند نسخهٔ JDK، کتابخانهٔ TLS یا کرنل را عوض کند و سرویس‌ها را restart کند. نسخه‌ها را قفل کن، فقط وصلهٔ امنیتی را خودکار کن، و ارتقای بزرگ را در پنجرهٔ تعمیرات انجام بده؛ needrestart روی Ubuntu می‌گوید کدام سرویس به restart نیاز دارد.

۱۷. اسکریپت‌نویسی bash

سه خط استاندارد شروع هر اسکریپت جدی:

#!/usr/bin/env bash
set -Eeuo pipefail

-E یعنی trap ERR در توابع هم ارث می‌رسد، -e یعنی با اولین خطا خارج شو، -u یعنی متغیر تعریف‌نشده خطاست (جلوی rm -rf $UNSET/ را می‌گیرد)، و pipefail یعنی شکست در هر جای pipeline، شکست کل است.

#!/usr/bin/env bash
set -Eeuo pipefail

readonly APP_NAME="myapp"
readonly APP_DIR="/opt/${APP_NAME}"
readonly HEALTH_URL="http://127.0.0.1:8080/actuator/health"
readonly TIMEOUT_SECONDS=90

log() { printf '%s [%s] %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$1" "${*:2}"; }
die() { log ERROR "$*"; exit 1; }
usage() { echo "Usage: deploy.sh -v <version>" >&2; exit 64; }
trap 'die "failed at line $LINENO"' ERR

wait_for_health() {
  local deadline=$(( SECONDS + TIMEOUT_SECONDS )) code
  while (( SECONDS < deadline )); do
    code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 3 "$HEALTH_URL" || echo 000)
    [[ "$code" == "200" ]] && { log INFO "healthy after ${SECONDS}s"; return 0; }
    log INFO "waiting, got HTTP $code"
    sleep 3
  done
  return 1
}

main() {
  local version=""
  while getopts ":v:h" opt; do
    case "$opt" in
      v) version="$OPTARG" ;;
      h) usage ;;
      \?) die "unknown option -$OPTARG" ;;
      :)  die "option -$OPTARG requires an argument" ;;
    esac
  done
  [[ -n "$version" ]] || usage
  [[ -d "$APP_DIR/releases/$version" ]] || die "release $version not found"

  ln -sfn "$APP_DIR/releases/$version" "$APP_DIR/current"
  systemctl restart "$APP_NAME"

  if wait_for_health; then
    log INFO "deploy of $version succeeded"
  else
    log WARN "health check failed, rolling back"
    ln -sfn "$APP_DIR/releases/previous" "$APP_DIR/current"
    systemctl restart "$APP_NAME"
    die "rolled back"
  fi
}

main "$@"

نکته‌های زبانی که باید بشناسی:

"$var"              # همیشه در کوتیشن — جلوی word splitting را می‌گیرد
"${var:-default}"   # مقدار پیش‌فرض   |  "${var:?msg}"  خروج با خطا اگر تعریف نشده
"$@"                # همهٔ آرگومان‌ها، هرکدام یک کلمهٔ جدا (تقریباً همیشه درست)
$? $# $$            # exit code آخرین دستور · تعداد آرگومان‌ها · PID اسکریپت
$(command)          # جایگزینی فرمان    $(( 3 + 4 ))  محاسبهٔ عددی
[[ -f "$f" ]] ; [[ -z "$s" ]] ; [[ "$a" =~ ^[0-9]+$ ]]

نقل‌قول نگذاشتن، پرتکرارترین باگ bash است:

FILE="my report.log"
rm $FILE      # ❌ تلاش برای حذف دو فایل: 'my' و 'report.log'
rm "$FILE"    # ✅

اگر متغیر خالی باشد بدتر می‌شود: rm -rf $DIR/* وقتی DIR خالی است یعنی rm -rf /*. ترکیب set -u و همیشه‌کوتیشن‌گذاشتن این کلاس کامل از فاجعه را حذف می‌کند، و shellcheck در CI تقریباً همهٔ این موارد را خودکار می‌گیرد.

trap دو کار حیاتی می‌کند: trap cleanup EXIT تضمین می‌کند فایل موقت و lock حتی در صورت خطا پاک شوند؛ و اگر اسکریپت تو داخل کانتینر PID 1 است، trap 'kill -TERM $child' TERM INT باعث می‌شود سیگنال توقف واقعاً به پروسهٔ جاوا برسد — بدون آن هر docker stop بعد از timeout به kill -9 ختم می‌شود و graceful shutdown از دست می‌رود.

۱۸. عیب‌یابی JVM روی لینوکس

اینجا قلب فصل است — جایی که دانش لینوکس و جاوا به هم می‌رسند. (مبانی heap، GC و مدل حافظهٔ JVM در فصل jvm-internals آمده؛ اینجا فقط عملیات روی سرور.)

ابزارها

همهٔ اینها با خود JDK می‌آیند؛ اگر روی سرور فقط JRE داری هیچ‌کدام نیستند.

jps -lvm                                 # پروسه‌های جاوا + کلاس اصلی + آرگومان‌ها
jcmd <pid> help                          # فهرست کامل دستورهای در دسترس همان JVM
jcmd <pid> VM.command_line               # اپ واقعاً با چه فلگ‌هایی بالا آمده؟
jcmd <pid> VM.flags -all | grep -i heap  # مقادیر مؤثر واقعی  |  VM.uptime

پیدا کردن نخِ داغ

top -H -b -n 1 -p 12345 | head -20                       # نخ‌های پرمصرف
ps -L -o tid,pcpu,comm -p 12345 --sort=-pcpu | head -10  # جایگزین
printf '%x\n' 12401                                      # TID به هگز -> 3071
jcmd 12345 Thread.print -l > /tmp/td.txt ; grep -A 30 'nid=0x3071' /tmp/td.txt

flowchart TD
  A["Alert: high CPU"] --> B["top -H -p PID"]
  B --> C{"Hot threads named GC Thread#n?"}
  C -- yes --> D["Memory problem: jstat -gcutil + GC log"]
  C -- no --> E["printf '%x' TID -> hex nid"]
  E --> F["jcmd PID Thread.print -l"]
  F --> G["grep nid=0xHEX in three dumps"]
  G --> H{"Same stack every time?"}
  H -- yes --> I["Hot loop in application code"]
  H -- no --> J["Just busy: profile with JFR"]

یک thread dump کافی نیست. یک عکس لحظه‌ای نمی‌گوید چه چیزی «گیر» است و چه چیزی فقط مشغول کار عادی؛ سه تا بگیر با فاصلهٔ ۵ تا ۱۰ ثانیه. نخی که در هر سه در همان خط است واقعاً بلاک شده. و حتماً -l بزن، وگرنه قفل‌های java.util.concurrent را نمی‌بینی و deadlock های مبتنی بر ReentrantLock پنهان می‌مانند (فصل sync-locks-jmm).

jcmd 12345 Thread.print -l > /tmp/td-$(date +%s).txt      # روش ارجح
jcmd 12345 Thread.dump_to_file -format=json /tmp/td.json  # شامل virtual thread ها
jstack -l 12345 > /tmp/td.txt                             # ابزار قدیمی‌تر
kill -3 12345                                             # SIGQUIT: dump روی stdout پروسه

kill -3 خروجی را کجا می‌نویسد؟ روی stdout خود پروسه، نه ترمینال تو. با systemd یعنی journalctl -u myapp؛ و اگر stdout به /dev/null رفته باشد dump کاملاً گم می‌شود. jcmd امن‌تر است چون خودش خروجی را به تو می‌دهد، ولی مزیت kill -3 این است که به هیچ ابزاری نیاز ندارد و در کانتینر بدون JDK هم کار می‌کند.

heap dump و GC log

jcmd 12345 GC.heap_dump -gz=1 /var/tmp/heap-$(date +%s).hprof.gz
jcmd 12345 GC.class_histogram | head -30      # سبک‌تر: فقط شمارش اشیا
jcmd 12345 GC.heap_info

از JDK 9 لاگ‌گیری یکپارچه (-Xlog) جایگزین فلگ‌های قدیمی مثل PrintGCDetails شده:

-Xlog:gc*:file=/var/log/myapp/gc.log:time,uptime,level,tags:filecount=5,filesize=20M

jstat -gcutil 12345 1000 ; jstat -gccause 12345 1000   # آمار زندهٔ GC هر ثانیه
jcmd 12345 VM.log output=/var/log/myapp/gc-live.log what=gc*   # روشن کردن در حین اجرا

ستون‌های jstat -gcutil: S0/S1 survivor، E eden، O old، M metaspace، YGC/YGCT تعداد و زمان GC جوان، FGC/FGCT همان برای full GC، و GCT زمان کل.

نشانهٔ واقعی «heap دارد تمام می‌شود» فقط بالا بودن O نیست؛ old generation قرار است پر شود. الگوی خطرناک این است که بعد از هر full GC هم O بالا می‌ماند، کفش هر بار بالاتر می‌رود و FGC سریع زیاد می‌شود — یعنی GC چیزی برای آزاد کردن پیدا نمی‌کند (نشتی حافظه یا کش بی‌سقف). حالت بی‌صداتر «GC thrashing» است: اپ زنده است و OOM نمی‌دهد ولی بیشتر وقتش را در GC می‌گذراند و از بیرون فقط شبیه «سرویس کند شده» است.

OutOfMemoryError جاوا در برابر OOM killer لینوکس

dmesg -T | grep -i -E 'out of memory|oom-kill|killed process'
journalctl -k --since "1 hour ago" | grep -i oom ; cat /proc/12345/oom_score_adj

یک خط نمونهٔ واقعی در dmesg:

Out of memory: Killed process 12345 (java) total-vm:9812344kB, anon-rss:4102300kB, UID:1001 oom_score_adj:0

anon-rss می‌گوید پروسه در لحظهٔ مرگ چقدر حافظهٔ فیزیکی خصوصی داشت — همان عددی که باید با -Xmx و بقیهٔ نواحی مقایسه کنی.

File descriptor ها

cat /proc/12345/limits | grep 'open files'   # تنها منبع حقیقت برای این پروسه
ls /proc/12345/fd | wc -l                    # تعداد fd باز همین حالا
lsof -p 12345 | awk '{print $5}' | sort | uniq -c   # تفکیک نوع

تلهٔ ulimit: ulimit -n در شل تو ربطی به سرویس ندارد — سرویس systemd سقفش را از LimitNOFILE= می‌گیرد نه از /etc/security/limits.conf که فقط برای نشست‌های PAM است؛ مقدار واقعی را از /proc/<pid>/limits بخوان. و fd فقط فایل نیست: هر سوکت TCP، هر اتصال دیتابیس و هر epoll یک fd است.

حافظه در کانتینر

JVM های مدرن محدودیت cgroup را می‌فهمند و -XX:+UseContainerSupport پیش‌فرض روشن است. ولی مقدار پیش‌فرض MaxRAMPercentage برابر ۲۵ درصد است — یعنی در کانتینر یک گیگی، heap فقط ۲۵۶ مگابایت می‌شود.

java -XX:+PrintFlagsFinal -version | grep -E 'MaxHeapSize|MaxRAMPercentage|UseContainerSupport'
nproc                                # چند CPU برای این پروسه در دسترس است
cat /sys/fs/cgroup/memory.max        # 'max' یعنی بدون محدودیت (cgroup v2)
cat /sys/fs/cgroup/memory.current    # و memory.peak برای اوج مصرف
cat /sys/fs/cgroup/memory.events     # شمارندهٔ oom و oom_kill
cat /sys/fs/cgroup/cpu.max

java -XX:MaxRAMPercentage=70 -XX:MaxMetaspaceSize=256m \
     -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/myapp \
     -XX:+ExitOnOutOfMemoryError -jar app.jar

Native Memory Tracking و JFR

وقتی RES رشد می‌کند ولی heap ثابت است:

java -XX:NativeMemoryTracking=summary -jar app.jar   # هزینه حدود ۵ تا ۱۰ درصد
jcmd 12345 VM.native_memory baseline
# ... چند ساعت صبر ...
jcmd 12345 VM.native_memory summary.diff scale=MB

خروجی حافظه را به دسته‌های Java Heap، Class، Thread، Code، GC و Internal تفکیک می‌کند: رشد در Thread یعنی نشتی نخ، در Class یعنی نشتی classloader، و در Internal/Other معمولاً direct buffer یا JNI.

jcmd 12345 JFR.start name=diag settings=profile duration=120s filename=/var/tmp/rec.jfr

JFR سربار بسیار کمی دارد و برای مشکلات متناوبی که در لحظهٔ حضور تو رخ نمی‌دهند ایده‌آل است.

۱۹. Cheat-sheet بقا

وقتی پیجر زنگ می‌زند ترتیب ثابت این است: سلامت ماشین (uptime, free -h, df -h, df -i) ← پرمصرف‌ترین پروسه ← لاگ سرویس ← لاگ کرنل برای OOM ← شبکه ← وضعیت JVM.