کدوم برنامه این پورت رو در لینوکس اشغال کرده؟

این چند خط رو روی همون میزبان اجرا کن تا توزیع و ابزار رو بشناسی. اگه ss نصب نبود، با مدیر میزبان هماهنگ کن تا بستهٔ همین توزیع رو از مخزن خودش بگیره.

اسم بسته در Ubuntu و Debian و خانوادهٔ Arch، iproute2 است؛ در RHEL و Rocky و AlmaLinux اسمش iproute است. بررسی پایین فقط نسخهٔ نصب‌شده رو می‌خونه.

cat /etc/os-release
dpkg-query -W iproute2
command -v ss
ss -V

دنبال پورت همین ماشینی، برای همین فیلتر رو روی پورت محلی می‌ذاریم. توی ستون Local Address:Port هم آدرس مهمه هم شماره. مثلاً آدرس loopback فقط از خود میزبان قابل دسترسیه؛ آدرس 0.0.0.0 همهٔ رابط‌های IPv4 رو پوشش می‌ده. برای سوکت IPv6، پذیرش IPv4 به تنظیم خود سوکت بستگی داره.

اگه ردیف پورت هست ولی اسم فرایند رو نمی‌بینی، فقط با مجوز مدیر همین بررسی رو با sudo تکرار کن. اگه ردیفی ندیدی، در همون لحظه هیچ شنوندهٔ TCP مطابقی در این فضای نام دیده نشده. برنامه‌ای که مرتب بالا میاد و می‌افته ممکنه بین دو بررسی پورت رو آزاد کنه.

ss -ltnp 'sport = :8080'

UDP مثل TCP اتصال رو با دست‌دادن شروع نمی‌کنه. همهٔ سوکت‌های UDP با این پورت محلی رو می‌گیریم. UNCONN معمولاً یعنی سوکت طرف مقابل ثابتی نداره؛ ممکنه سوکت دیگه‌ای هم طرف مقابل مشخصی داشته باشه. برای اینکه بفهمی سرویس جواب می‌ده، باید جداگانه درخواست واقعی بفرستی.

ss -uanp 'sport = :8080'

به‌جای PID نمونه، عددی رو بذار که همین الان از ss گرفتی. برای شناخت فرایند لازم نیست همهٔ آرگومان‌هاش رو ببینی؛ ممکنه چیزی مثل توکن بینشون باشه. روی میزبان systemd می‌تونی از روی PID به واحد مربوط برسی. اگه پورت دست PID 1 بود، فهرست سوکت‌ها رو هم ببین: ستون Listen آدرس رو می‌گه و Activates نشون می‌ده کدوم سرویس با رسیدن درخواست بیدار می‌شه.

اگه برنامه پرید و برگشت، دوباره سوکت رو نگاه کن؛ PID ممکنه به برنامهٔ دیگه‌ای رسیده باشه. چند worker هم می‌تونن از یک سوکت مشترک استفاده کنن. برای رفع تداخل، اول تنظیمات سرویس یا کانتینر رو با مسئولش بررسی کن.

pid=1234
ps -p "$pid" -o pid,ppid,user,comm
systemctl status "$pid" --no-pager -n 0
systemctl list-sockets --all --no-pager