‏المنفذ ليس معطوبًا. شيء آخر يستخدمه.‏

‏فشل ⁦bind⁩() برمز 98: العنوان قيد الاستخدام بالفعل. خدمتك سليمة. شيء آخر وصل إلى المنفذ قبلك.‏

‏شخّص‏

ss -tlnp | grep ':80 '

‏كل مقبس ⁦TCP⁩ يستمع، مع اسم العملية ومعرّفها. شغّله بـ ⁦sudo⁩، وإلا بقي عمود العملية فارغًا.‏

lsof -i :80

‏الإجابة نفسها من أداة أخرى، مع المستخدم الذي يملك العملية.‏

ps -fp 2231

‏سطر الأمر الكامل، والعملية الأب، ووقت البداية لذلك المعرّف. الآن تعرف ما هو ومن أين جاء.‏

‏أصلِح‏

systemctl stop apache2

‏إن كان المنفذ ملكًا لخدمة أخرى، فأوقفها بشكل صحيح بدلًا من قتلها.‏

systemctl disable apache2

‏وإلا فإنها ستأخذ المنفذ مجددًا عند إعادة الإقلاع التالية، وتعود إلى هنا في الثالثة فجرًا.‏

kill 2231

‏إن كانت عملية شاردة، مثل نسخة قديمة من تطبيقك، فاطلب منها التوقف. استخدم -9 فقط إن تجاهلتك.‏

‏امنع‏

‏منفذ واحد، مالك واحد — احتفظ بقائمة قصيرة بأي خدمة تملك 80 و443 و3306 و5432 على كل خادم.‏

‏⁦ss⁩ ⁦-tlnp⁩ بعد كل تثبيت — بعض الحزم تبدأ خدمتها الخاصة لحظة تثبيتها. خادم ويب جاء كتبعية حالة كلاسيكية.‏

‏اربط الخدمات الداخلية بـ 127.0.0.1 — قاعدة بيانات أو ذاكرة مؤقتة تستخدمها التطبيقات المحلية فقط لا سبب لها للاستماع على 0.0.0.0. تعارضات أقل، وتعريض أقل للشبكة.‏

‏الفكرة الأساسية‏

‏رسالة الخطأ تخبرك بالمنفذ أصلًا. أمر ⁦ss⁩ واحد يخبرك بالباقي.‏

‏المنفذ ليس معطوبًا. شيء آخر يستخدمه.‏

‏ما كان المالك المفاجئ لمنفذك؟‏

The port is not broken. Something else is using it.

bind() failed (98: Address already in use). Your service is fine. Something else got to the port first.

Diagnose

ss -tlnp | grep ':80 '

Every listening TCP socket, with the process name and PID. Run it with sudo, or the process column stays empty.

lsof -i :80

The same answer from a different tool, including the user that owns the process.

ps -fp 2231

The full command line, parent process and start time of that PID. Now you know what it is and where it came from.

Fix

systemctl stop apache2

If the port belongs to another service, stop it properly instead of killing it.

systemctl disable apache2

Otherwise it takes the port again on the next reboot and you are back here at 3 AM.

kill 2231

If it is a stray process, like an old copy of your app, ask it to stop. Use -9 only if it ignores you.

Prevent

One port, one owner — keep a short list of which service owns 80, 443, 3306 and 5432 on each server.

ss -tlnp after every install — some packages start their own service the moment they are installed. A web server pulled in as a dependency is a classic.

Bind internal services to 127.0.0.1 — a database or cache that only local apps use has no reason to listen on 0.0.0.0. Fewer clashes, and less exposed to the network.

The key insight

The error message already tells you the port. One ss command tells you the rest.

The port is not broken. Something else is using it.

What was the surprise owner of your port?

‏اقرأ السجلات قبل أن تعيد التشغيل.‏

‏في كل خادم لينكس حديث تقريبًا، تُدار الخدمات بواسطة ⁦systemd⁩. تسعة أوامر تغطي معظم ما ستحتاجه.‏

‏التحكّم‏

systemctl restart nginx

‏إيقاف كامل ثم تشغيل. بسيط، لكن الاتصالات المفتوحة تنقطع للحظة.‏

systemctl reload nginx

‏يعيد قراءة الإعدادات دون إيقاف العملية. لا تدعمه كل الخدمات، لكن حين تدعمه لا يلاحظ المستخدمون شيئًا.‏

systemctl enable --now nginx

‏تشغيل الآن وعند كل إقلاع. مهمّتان بأمر واحد.‏

‏الفحص‏

systemctl status nginx

‏يعمل أو لا، ومعرّف العملية الرئيسية، واستخدام الذاكرة، وآخر أسطر السجل. دائمًا الأمر الأول.‏

systemctl --failed

‏كل وحدة في حالة فشل. أول ما تشغّله بعد إعادة الإقلاع.‏

systemctl cat nginx

‏ملف الوحدة مع كل التجاوزات، تمامًا كما تراها ⁦systemd⁩. هذا ينهي كثيرًا من الحيرة: لكنني غيّرت ذلك الإعداد.‏

‏السجلات‏

journalctl -u nginx -f

‏متابعة سجلات خدمة واحدة مباشرةً، مثل ⁦tail⁩ ⁦-f⁩.‏

journalctl -u nginx --since "1 hour ago"

‏نافذة زمنية فقط. يفهم أيضًا “⁦today⁩” و”⁦yesterday⁩” والتواريخ المحددة.‏

journalctl -p err -b

‏الأخطاء وما هو أسوأ فقط، منذ آخر إقلاع. فحص صحة للجهاز كله في ثلاثين ثانية.‏

‏العادة التي تستحقّ البناء‏

‏حين يفشل شيء، شغّل ⁦systemctl⁩ ⁦status⁩ وjournalctl ⁦-xeu⁩ قبل أن تعيد التشغيل. إعادة التشغيل غالبًا تُخفي العَرَض وتأخذ التفسير معه.‏

‏اقرأ السجلات قبل أن تعيد التشغيل.‏

‏أي أمر من أوامر ⁦systemd⁩ تستخدمه أكثر؟‏

Read the logs before you restart.

On almost every modern Linux server, services are managed by systemd. Nine commands cover most of what you will ever need.

Control

systemctl restart nginx

A full stop and start. Simple, but open connections drop for a moment.

systemctl reload nginx

Re-read the configuration without stopping the process. Not every service supports it, but when it does, users notice nothing.

systemctl enable --now nginx

Start it right now and on every boot. Two jobs, one command.

Inspect

systemctl status nginx

Running or not, the main PID, memory use, and the last log lines. Always the first command.

systemctl --failed

Every unit that is in a failed state. The first thing to run after a reboot.

systemctl cat nginx

The unit file plus every override, exactly as systemd sees it. This ends a lot of “but I changed that setting” confusion.

Logs

journalctl -u nginx -f

Follow the logs of one service live, like tail -f.

journalctl -u nginx --since "1 hour ago"

Only a time window. It also understands “today”, “yesterday” and exact dates.

journalctl -p err -b

Only errors and worse, since the last boot. A thirty-second health check for the whole machine.

The habit worth building

When something fails, run systemctl status and journalctl -xeu before you restart. A restart often makes the symptom disappear and takes the explanation with it.

Read the logs before you restart.

Which systemd command do you use most?

‏الإشارة 15 تطلب، والإشارة 9 تأخذ.‏

‏⁦kill⁩ -9 هو أمر لينكس الذي يلجأ إليه الناس مبكّرًا جدًا.‏

‏الأمر ⁦kill⁩ ⁦PID⁩ يرسل ⁦SIGTERM⁩، أي الإشارة رقم 15. إنه طلب: توقّف من فضلك. تستطيع العملية التقاطه، وإنهاء الطلب الذي تعالجه، وتفريغ البيانات إلى القرص، وحذف ملف القفل، ثم الخروج بنظافة. هذا ما يرسله ⁦systemctl⁩ ⁦stop⁩ أولًا.‏

‏الأمر ⁦kill⁩ -9 ⁦PID⁩ يرسل ⁦SIGKILL⁩، أي الإشارة رقم 9. إنه ليس طلبًا. تزيل النواة العملية فورًا. لا ترى العملية الإشارة أبدًا، ولا تستطيع التنظيف ولا الرفض.‏

‏أين يخطئ -9‏

‏قاعدة بيانات قُتلت بـ -9 قد تحتاج إلى استعادة بعد الانهيار عند التشغيل التالي، وكل ما لم تُكتبه بعد يكون قد ضاع.‏

‏تطبيق قُتل بـ -9 قد يترك ملف ⁦PID⁩ أو ملف قفل قديمًا، ثم يرفض العمل لأنه يظن أنه ما زال يعمل.‏

‏قد تُترك العمليات الفرعية خلفها وهي ما زالت تحتجز منافذ أو ملفات.‏

‏الترتيب الصحيح‏

kill PID

‏انتظر خمس إلى عشر ثوانٍ.‏

ps -p PID

‏تحقّق من أنه ما زال موجودًا. عندها فقط استخدم ⁦kill⁩ -9.‏

‏تحفّظان صادقان‏

‏العملية الزومبي (الحالة ⁦Z⁩) ميتة أصلًا، ولن تزيلها أي إشارة؛ الحل هو العملية الأم.‏

‏العملية العالقة في الحالة ⁦D⁩، التي تنتظر إدخالًا أو إخراجًا على القرص أو الشبكة، لن تموت حتى يعود ذلك الإدخال، ولا حتى بـ -9.‏

‏الإشارة 15 تطلب، والإشارة 9 تأخذ. اطلب أولًا.‏

‏أيّهما ردّ فعلك التلقائي؟‏

SIGTERM asks. SIGKILL takes.

kill -9 is the Linux command people reach for too early.

kill PID sends SIGTERM, signal 15. It is a request: please stop. The process can catch it, finish the request it is handling, flush data to disk, remove its lock file and exit cleanly. This is what systemctl stop sends first.

kill -9 PID sends SIGKILL, signal 9. It is not a request. The kernel removes the process immediately. The process never sees the signal, cannot clean up and cannot refuse.

Where -9 goes wrong

A database killed with -9 may need crash recovery on the next start, and anything it had not written yet is gone.

An app killed with -9 can leave a stale PID or lock file behind, and then refuses to start because it thinks it is still running.

Child processes can be left behind, still holding ports or files.

The right order

kill PID

Wait five to ten seconds.

ps -p PID

Check it is still there. Only if it is, use kill -9.

Two honest caveats

A zombie process (state Z) is already dead, so no signal will remove it; the fix is its parent.

A process stuck in state D, waiting on disk or network I/O, will not die until that I/O returns, not even with -9.

SIGTERM asks. SIGKILL takes. Ask first.

Which one is your reflex?

‏الأقراص الممتلئة لا تحدث فجأة. إنها فقط بلا مراقبة.‏

‏لا توجد مساحة متبقية على الجهاز. الخطأ الذي يوقف قواعد البيانات وعمليات النشر والنسخ الاحتياطي في اللحظة نفسها.‏

‏شخّص‏

df -h

‏أي نظام ملفات ممتلئ. يُظهر عمود ⁦Use⁩% أين يجب أن تبحث.‏

df -i

‏تحقّق من الـ ⁦inodes⁩ أيضًا. قد ينفد القرص من الـ ⁦inodes⁩ بسبب ملايين الملفات الصغيرة بينما ما يزال ⁦df⁩ ⁦-h⁩ يُظهر مساحة حرة.‏

du -xh --max-depth=1 / | sort -h

‏أكبر المجلدات على ذلك القرص، والأكبر في الأسفل. أعِد الأمر بعمق مستوى واحد حتى تجد السبب.‏

‏أصلِح‏

journalctl --vacuum-size=200M

‏يمكن أن ينمو سجل ⁦systemd⁩ بصمت حتى يبلغ جيجابايت. هذا الأمر يقلّصه إلى 200 ميغابايت.‏

lsof +L1

‏ملفات حُذفت لكن عملية ما ما زالت تحتفظ بها مفتوحة. لا تعود المساحة إلا عند إعادة تشغيل تلك العملية. هذه هي الحالة الكلاسيكية: حذفت السجل ولم تتغيّر نتيجة ⁦df⁩.‏

apt clean

‏يحذف حزم التنزيل المخزّنة مؤقتًا. على خادم يعمل منذ سنوات، قد يحرّر هذا وحده مساحة كبيرة.‏

‏امنع‏

logrotate -d /etc/logrotate.conf

‏تجربة تشغيل تُظهر ما سيفعله ⁦logrotate⁩. إن لم يكن سجل تطبيقك في القائمة، فسيزداد إلى ما لا نهاية.‏

‏أنذِر عند 80% — لا عند 100%. القرص لا يمتلئ في ثانية واحدة تقريبًا، وهذا يمنحك أيامًا من الإنذار إذا كان هناك من يراقب.‏

‏افصل /⁦var⁩ — عندما تعيش السجلات على قسم خاص بها، لا يستطيع سجل جامح أن يُسقط النظام كله.‏

‏الفخ الذي يجب تجنّبه‏

‏أمر ⁦rm⁩ ⁦-rf⁩ على مجلد السجلات أثناء تشغيل الخدمة. تفقد الأدلة، وغالبًا لا تعود المساحة على أي حال.‏

‏الأقراص الممتلئة لا تحدث فجأة أبدًا. إنها فقط بلا مراقبة.‏

‏ما الذي ملأ قرصك في المرة الأخيرة؟‏

Full disks are never sudden. They are just unwatched.

No space left on device. The error that stops databases, deployments and backups at the same moment.

Diagnose

df -h

Which filesystem is full. The Use% column tells you where to look.

df -i

Check inodes too. A disk can run out of inodes from millions of tiny files while df -h still shows free space.

du -xh --max-depth=1 / | sort -h

The biggest folders on that disk, largest at the bottom. Repeat one level deeper until you find the culprit.

Fix

journalctl --vacuum-size=200M

The systemd journal can quietly grow to gigabytes. This shrinks it to 200 MB.

lsof +L1

Files that were deleted but are still held open by a process. The space only comes back when that process restarts. This is the classic “I deleted the log but df did not change”.

apt clean

Removes cached package downloads. On a server that has run for years, this alone can free a lot.

Prevent

logrotate -d /etc/logrotate.conf

A dry run that shows what logrotate would do. If your app log is not in the list, it will grow forever.

Alert at 80% — not at 100%. A disk almost never fills in one second. It gives you days of warning if something is watching.

Separate /var — when logs live on their own partition, a runaway log cannot take the whole system down.

The one to avoid

rm -rf on a log folder while the service is running. You lose the evidence, and the space often does not come back anyway.

Full disks are never sudden. They are just unwatched.

What filled up your last disk?

‏اعثر على السطر، ثم شكّله، ثم احسبه‏

‏لا تحتاج السجلات إلى أداة معقّدة. يمكن الإجابة عن معظم أسئلة الخادم باستخدام تسعة أوامر وأنبوب واحد ⁦(pipe)⁩.‏

‏اعثر عليه‏

grep -i "error" app.log

‏كل سطر يذكر كلمة ⁦error⁩، بأي حالة من الأحرف. أضف ⁦-c⁩ لعدّ الأسطر بدلًا من طباعتها.‏

grep -rn "DB_HOST" /etc/app/

‏ابحث في مجلد كامل. يمنحك ⁦-n⁩ رقم السطر، فتنتقل إليه مباشرة.‏

grep -v "healthcheck" access.log

‏أخفِ الضجيج. يعرض ⁦-v⁩ كل سطر لا يطابق النمط.‏

‏شكّله‏

awk '{print $1, $9}' access.log

‏اطبع الحقول التي تهمّك فقط. في سجل وصول ⁦nginx⁩، الحقل الأول هو عنوان ⁦IP⁩ للعميل، والحقل التاسع هو رمز الحالة.‏

cut -d: -f1 /etc/passwd

‏اقسم كل سطر عند النقطتين واحتفظ بالحقل الأول. تلك قائمة بكل مستخدم على الجهاز.‏

sed 's/http:/https:/g' links.txt

‏بحث واستبدال في كل سطر. أضف ⁦-i⁩ لتعديل الملف في مكانه، بعد أخذ نسخة منه.‏

‏احسبه‏

sort ips.txt | uniq -c | sort -rn

‏احسب التكرارات وضع الأكبر في الأعلى. يدمج ⁦uniq⁩ الأسطر المتجاورة فقط، ولهذا يأتي ⁦sort⁩ أولًا.‏

wc -l access.log

‏عدد الأسطر. طريقة سريعة لعدّ الطلبات أو الأخطاء أو المستخدمين.‏

tail -f app.log | grep ERROR

‏تابع السجل مباشرةً، وأظهر الأخطاء فقط عند وصولها.‏

‏اجمعها معًا‏

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

‏يعرض هذا عشرة عناوين ⁦IP⁩ تزور خادمك أكثر من غيرها. سطر واحد، بلا لوحة متابعة.‏

‏الفكرة الأساسية: كل أداة من هذه الأدوات تؤدي مهمة صغيرة واحدة، والأنبوب ⁦(pipe)⁩ هو ما يجعلها قوية.‏

‏أيّها تستخدمه أكثر؟‏

Find the line, shape it, count it

Logs do not need a fancy tool. Most questions about a server can be answered with nine commands and a pipe.

Find it

grep -i "error" app.log

Every line that mentions error, in any case. Add -c to count instead of print.

grep -rn "DB_HOST" /etc/app/

Search a whole folder. -n gives you the line number, so you can jump straight to it.

grep -v "healthcheck" access.log

Hide the noise. -v prints every line that does not match.

Shape it

awk '{print $1, $9}' access.log

Print only the fields you care about. In an nginx access log, field 1 is the client IP and field 9 is the status code.

cut -d: -f1 /etc/passwd

Split each line on a colon and keep the first field. That is a list of every user on the box.

sed 's/http:/https:/g' links.txt

Find and replace on every line. Add -i to change the file in place, after you have a copy.

Count it

sort ips.txt | uniq -c | sort -rn

Count duplicates and put the biggest at the top. uniq only merges neighbours, which is why sort comes first.

wc -l access.log

How many lines. A quick way to count requests, errors or users.

tail -f app.log | grep ERROR

Follow the log live and only show the errors as they arrive.

Put them together

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head

This shows the ten IPs hitting your server the most. One line, no dashboard.

The key insight: each of these tools does one small thing. The pipe is what makes them powerful.

Which one do you use the most?