أمر إعادة تشغيل Linux: reboot و shutdown -r now و systemctl

أمر إعادة التشغيل في Linux: reboot و shutdown -r now و systemctl reboot

في أي توزيعة حديثة، تعيد الأوامر الثلاثة التالية تشغيل الجهاز بالطريقة نفسها تمامًا. نفّذ أحدها بصلاحية root أو عبر sudo؛ فعبر SSH يحصل الحساب غير المميّز على الرسالة Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

ليست هذه ثلاث تطبيقات مختلفة. ففي توزيعات systemd تكون /sbin/reboot و/sbin/shutdown و/sbin/halt و/sbin/poweroff روابط رمزية إلى systemctl، الذي يتحقق من الاسم الذي استُدعي به وينتقل إلى وضع التوافق المناسب؛ ويكشف ls -l $(which reboot) هذا الرابط. وأيًا كانت الصيغة التي تكتبها، يبدأ systemd الهدف reboot.target، ويوقف كل وحدة بترتيب معكوس للاعتماديات، ويفصل تركيب أنظمة الملفات، ثم يطلب من النواة إعادة التشغيل. وعبر SSH ينقطع الاتصال خلال ثانية أو ثانيتين؛ أما مدة غياب الجهاز فتتوقف على النواة، وعلى أي فحص لنظام الملفات، وعلى مسار الإقلاع لدى المزوّد، لذا امنحه دقيقة قبل افتراض وجود خلل.

إيقاف التشغيل: shutdown -h now و poweroff و halt والأمر القديم init 6

لإطفاء الجهاز، يكفي أي من الأمرين التاليين:

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

في systemd تعني -h "إيقاف النظام أو إطفاء الطاقة، أيهما الافتراضي"، والافتراضي هو إطفاء الطاقة، لذا فإن shutdown -h now وshutdown -P now متطابقان. والأمر الذي يوقع كثيرين في الخطأ هو halt المجرد: فهو يوقف نظام التشغيل لكنه لا يرسل طلب إطفاء الطاقة أبدًا، فيبقى الجهاز الافتراضي عند رسالة System halted، محجوزًا ومحتسَبًا في الفاتورة، إلى أن توقفه من لوحة التحكم. استخدم بدلًا منه halt -p أو poweroff أو shutdown -h now.

لا تزال صيغ SysV تعمل لأن systemd يربط مستويات التشغيل بالأهداف: فـ init 6 وtelinit 6 يؤولان إلى reboot.target، وinit 0 إلى poweroff.target. وهي غير ضارة داخل سكربت قديم، لكنها لا توفر رسالة تنبيه ولا جدولة ولا تدوينًا في السجل، فلا داعي لكتابتها يدويًا.

جدولة إعادة التشغيل وإلغاؤها وتنبيه المستخدمين المتصلين

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

يمكن أن يكون الوقت now، أو +m أي بعد m دقيقة من الآن، أو hh:mm بنظام 24 ساعة (والوقت الذي مضى اليوم يعني الغد). وإن لم تحدد وقتًا إطلاقًا، يفترض shutdown القيمة +1: فأمر sudo shutdown المجرد يطفئ الجهاز بعد ستين ثانية. وكل ما يأتي بعد الوقت يُبَث كرسالة تنبيه عامة إلى كل طرفية متصلة، ويكرر logind التنبيه كلما اقترب الموعد؛ ويكتم --no-wall هذه الرسائل، بينما يرسل shutdown -k التنبيه دون جدولة أي شيء. وقبل خمس دقائق من الموعد ينشئ logind الملف /run/nologin، فتُرفض عمليات تسجيل الدخول الجديدة منذ تلك اللحظة.

يلغي shutdown -c العملية المعلّقة، ويحذف /run/nologin، ويبلغ المستخدمين المتصلين بإلغاء الإيقاف. وللتحقق من وجود عملية معلّقة، ابحث عن /run/systemd/shutdown/scheduled: فهو لا يوجد إلا أثناء انتظار إيقاف مجدول، ويسجل الوضع والوقت المستهدف. كما تقبل إصدارات systemd الحديثة الصيغة systemctl reboot --when=+10m مع --when=show و--when=cancel (تحقق عبر systemctl --help؛ فالإصدارات الأقدم تفتقر إليها).

ما الذي يحدث للخدمات وجلسات SSH أثناء إعادة التشغيل

عند طلب reboot.target، يوقف systemd كل ما يتعارض معه، أي كل الوحدات تقريبًا. وتتوقف الخدمات بترتيب معكوس للاعتماديات: تنفّذ كل خدمة أمر ExecStop الخاص بها أو تتلقى SIGTERM، وإن لم تنتهِ بعد TimeoutStopSec (90 ثانية افتراضيًا، من DefaultTimeoutStopSec= في /etc/systemd/system.conf) تتلقى SIGKILL. وهذه المهلة هي العدّاد التنازلي A stop job is running for ... الذي يظهر على وحدة التحكم؛ وسببه عادةً خدمة تتجاهل SIGTERM أو قاعدة بيانات ما زالت تفرغ بياناتها. بعدها يُفصل تركيب أنظمة الملفات أو يُعاد تركيبها للقراءة فقط، ثم تعيد النواة التشغيل. ولا حاجة إلى تنفيذ sync مسبقًا.

لا تحظى جلسة SSH بأي معاملة خاصة. فتتوقف ssh.service، ويتلقى النطاق الذي يحتضن جلستك إشارة SIGTERM، فتنتهي الصدفة ويطبع العميل Connection to 203.0.113.10 closed by remote host. وخادم tmux أو screen يحميك من انقطاع الاتصال لا من إعادة التشغيل: فكل ما يعمل داخله ينتهي أيضًا.

ما يعود للعمل تحدده حالة التفعيل لا ما كان يعمل قبل ذلك. فالوحدات الموسومة enabled تبدأ من جديد؛ أما ما شُغّل يدويًا عبر systemctl start، أو عملية nohup، أو حاوية Docker بلا سياسة إعادة تشغيل، فلا يعود. نفّذ systemctl list-unit-files --state=enabled قبل الإعادة وsystemctl --failed بعدها؛ ويشرح دليل سرد الخدمات وتصفيتها باستخدام systemctl كيفية قراءة الاثنين.

إعادة تشغيل خادم VPS بأمان: قائمة التحقق قبل الإقلاع

على خادم VPS لا يوجد وصول فيزيائي، لذا فإن إعادة تشغيل لا يعود بعدها الجهاز تعني اللجوء إلى وحدة تحكم المزوّد. وخمس عمليات تحقق، لا تستغرق مجتمعة أكثر من دقيقة، تمنع هذا اللجوء في معظم الحالات.

1. تأكد من أن إعادة التشغيل ضرورية فعلًا

ليس كل تحديث يستلزمها. ففي Ubuntu يوجد الملف /var/run/reboot-required عندما تطلب حزمة إعادة التشغيل، ويسمّيها /var/run/reboot-required.pkgs؛ ويقوم needrestart في Debian وUbuntu، وneeds-restarting -r من dnf-utils في عائلة RHEL، بالفحص نفسه في غيرها. فنواة جديدة أو glibc أو systemd تبرر إعادة التشغيل، أما nginx بعد ترقيع فيكفيه systemctl restart nginx. ثبّت التحديثات المعلّقة أولًا لتعيد التشغيل مرة واحدة لا مرتين؛ ويغطي شرح تحديث Ubuntu من سطر الأوامر تسلسل أوامر apt وعلامة reboot-required.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. تأكد من عدم وجود عملية كتابة جارية

مقاطعة مدير الحزم أسرع طريق إلى نظام نصف مهيّأ، والنسخة الاحتياطية التي تُقطع في منتصفها تتحول إلى ملف ستظنه لاحقًا نسخة سليمة. ابحث عن هذه العمليات وتحقق ممن يستخدم الخادم أيضًا:

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. تحقق من الإعدادات التي يجب أن تصمد بعد الإقلاع

ثلاثة ملفات قادرة على تحويل إعادة تشغيل روتينية إلى حجب كامل للوصول. فخطأ نحوي في sshd_config يعني أن sshd لن يبدأ ولن تتمكن من الدخول: والأمر sudo sshd -t لا يطبع شيئًا عندما يكون الملف سليمًا، وإن كنت قد شدّدت أمان خدمة SSH مؤخرًا فنفّذه الآن. ومدخل في /etc/fstab يشير إلى جهاز لم يعد موجودًا يُسقط الإقلاع في وضع الطوارئ ما لم يحمل الخيار nofail؛ ويكشف sudo findmnt --verify معظم هذه الحالات. كما أن امتلاء /boot قد يترك نواة نصف مثبتة، فتحقق من المساحة الحرة فيه. وقواعد الجدار الناري المكتوبة مباشرة بـ iptables أو nft دون حفظ تختفي عند إعادة التشغيل؛ بينما تبقى قواعد UFW وfirewalld.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. سجّل حالة مرجعية

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. أعد التشغيل ثم تحقق

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

تطابق نتيجة uname -r، ونظافة systemctl --failed، وخلوّ المقارنة من فروق، تعني أن إعادة التشغيل أدت مهمتها.

عندما تتعلق إعادة التشغيل: فرضها، ومتى تلجأ إلى وحدة تحكم المزوّد

إذا عاد أمر reboot دون أن يتوقف الجهاز، فهناك مهمة إيقاف عالقة؛ ويظهرها systemctl list-jobs. ويتخطى systemctl reboot --force الإيقاف المنظم للوحدات: إذ تُقتل العمليات مباشرة مع بقاء فصل تركيب أنظمة الملفات، فهو حاد لكنه آمن إلى حد معقول. أما --force --force فيعيد التشغيل فورًا دون فصل أي تركيب وقد يفقد بيانات؛ فعامله كأنه فصل للتيار. وتبقى واجهة SysRq في النواة الملاذ الأخير عندما يتوقف systemd نفسه عن الاستجابة. والكتابة إلى /proc/sysrq-trigger مسموحة دائمًا لـ root مهما كانت قيمة kernel.sysrq، لكن إعادة التوجيه يجب أن تُنفَّذ بصلاحية root، فاستخدم صدفة root أو sudo sh -c:

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

الجأ إلى لوحة المزوّد أو وحدة التحكم عندما يعجز النظام الضيف عن مساعدة نفسه: تعذّر الوصول عبر SSH بعد تغيير في الشبكة أو الجدار الناري، أو نواة تنهار عند الإقلاع، أو موجّه وضع الطوارئ بسبب سطر خاطئ في fstab، أو كلمة مرور root منسية. وزر Reboot أو Shutdown في اللوحة يرسل عادةً حدث طاقة ACPI يتعامل معه النظام الضيف عبر logind (HandlePowerKey= في logind.conf)، فتتوقف الخدمات بشكل نظيف. أما Reset أو Force stop أو Power cycle فتقطع الطاقة الافتراضية بلا إنذار: فيُعاد تشغيل سجل نظام الملفات عند الإقلاع التالي، لكن كل ما لم يُكتب يضيع. ووحدة تحكم VNC أو التسلسلية هي ما يتيح لك مشاهدة GRUB ورسائل النواة وصدفة الطوارئ التي لا يظهرها SSH أبدًا.

معرفة مدة التشغيل وآخر إعادة تشغيل للجهاز

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

يطبع uptime -s وwho -b وقت الإقلاع مباشرة. ويقرأ last -x الملف /var/log/wtmp ويسرد سجلات reboot وshutdown معًا: فسطر reboot لا يسبقه سطر shutdown يعني أن الجهاز توقف بشكل غير نظيف (انهيار أو إعادة تعيين قسرية). ويرقّم journalctl --list-boots كل إقلاع يعرفه السجل، فالرقم 0 هو الحالي و-1 هو السابق؛ ثم يعرض journalctl -b -1 -e آخر الأسطر قبل الإيقاف السابق، حيث تترك مهلة مهمة إيقاف أو قتل بسبب نفاد الذاكرة أثرها. وإن لم يُدرج سوى الإقلاع الحالي فالسجل متطاير: أنشئ /var/log/journal وأعد تشغيل systemd-journald.

تقوم كل الأوامر السابقة على افتراض واحد: أنك تستطيع الوصول إلى النظام الضيف حتى عندما يرفض العودة. وخادم Linux VPS بتقنية KVM مع وصول إلى وحدة التحكم يمنحك ذلك تحديدًا: جهاز افتراضي حقيقي بنواة خاصة به، ومعالج وذاكرة مخصصين، وصلاحية root كاملة، ووحدة تحكم للأيام التي لا يكون فيها SSH خيارًا. وتسلّمه rdp.monster خلال نحو 10 ثوانٍ بعد تأكيد الدفع، مع نطاق ترددي غير محدود (ضمن الاستخدام العادل)، بلا إجراءات KYC، مع قبول البطاقات والعملات المشفّرة، ابتداءً من 8.99$ شهريًا.