هل الـ Service منفصلة عن PM2 اللي فيه الـ Apps؟

الإجابة

لأ، مش منفصلة. الـ service دي مجرد مفتاح تشغيل لنفس الـ PM2 اللي ماسك الـ apps بتاعتك.

الترتيب

systemd └─ pm2-ubuntu.service      ← بتقوم مع الـ boot     └─ PM2 daemon          ← نفس الـ PM2 اللي بتكلمه بـ pm2 list         ├─ LMS::backend worker 1         ├─ LMS::backend worker 2         └─ ...

• systemd: وظيفته بس إنه يشغّل الـ PM2 daemon لما السيرفر يقوم.
• الـ PM2 daemon: هو اللي بيدير الـ apps. بيشغّلها، ويرجّع اللي يقع منها، ويوزّع الـ requests في الـ cluster.
• أوامر pm2 في الـ terminal: بتكلم نفس الـ daemon ده عن طريق socket في ~/.pm2، مش نسخة تانية.

الـ service بتعمل إيه جواها؟

لو فتحت الملف بالأمر ده:

systemctl cat pm2-ubuntu

هتلاقي حاجة شبه كده:

[Service]Type=forkingUser=ubuntuEnvironment=PATH=/usr/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbinEnvironment=PM2_HOME=/home/ubuntu/.pm2PIDFile=/home/ubuntu/.pm2/pm2.pidRestart=on-failureExecStart=/usr/bin/pm2 resurrectExecReload=/usr/bin/pm2 reload allExecStop=/usr/bin/pm2 kill

• عند الـ boot: بتنفذ pm2 resurrect، فيقوم الـ daemon ويقرأ dump.pm2 ويرجّع الـ apps.
• عند الإيقاف: بتنفذ pm2 kill. يعني لو عملت systemctl stop pm2-ubuntu هتقفل الـ apps كلها، لأنه نفس الـ daemon.
• systemctl reload pm2-ubuntu: بينفذ pm2 reload all.
• Environment=PATH: هنا بالظبط مسار الـ node اللي اتحفظ وقت الـ startup. ولو Node متسطب بـ nvm، هتلاقي أول المسار حاجة زي /home/ubuntu/.nvm/versions/node/v22.11.0/bin، وكمان الـ pm2 في ExecStart هيبقى من نفس الفولدر. وده سبب إنك تعيد الـ startup بعد تغيير Node.
• User وPM2_HOME: دول اللي بيحددوا أنهي daemon وأنهي dump.pm2 هيتقري.

حاجتين ممكن يلخبطوك

• pm2 وsudo pm2 اتنين daemons مختلفين. كل يوزر ليه PM2 خاص بيه في الـ home بتاعه، فـ root عنده /root/.pm2. لو شغلت الـ apps بـ sudo pm2 وعملت startup ليوزر عادي، بعد الـ reboot مش هتلاقيهم. خليك على يوزر واحد في كل حاجة.
• أول مرة بعد pm2 startup، ممكن systemctl status يقولك إن الـ service مش شغالة (inactive)، رغم إن الـ apps شغالة. ده لأن الـ daemon الحالي إنت اللي شغلته بإيدك، مش systemd، وpm2 startup بيعمل enable بس مش start. ودي مش مشكلة، فبعد أول reboot systemd هيبقى هو اللي مشغّله.

pm2 list          # الـ apps بتاعة اليوزر الحاليsudo pm2 list     # الـ apps بتاعة root، غالبًا فاضية، ولو مش فاضية ده سبب اللخبطة

🧪 Lab: جرّب الـ reboot بجد

متعتبرش الإعداد ناجح عشان systemctl status أخضر. جرّب في وقت هادي:

whoami                                 # لازم يكون يوزر الـ apppm2 list && pm2 savesystemctl is-enabled pm2-$(whoami)     # enabledsudo reboot

بعد ما يقوم:

systemctl status pm2-$(whoami)         # المرة دي active (running)pm2 list                               # نفس الأسماء ونفس العددcurl -k https://localhost:4000         # الـ app بيرد فعلًا

لو الـ apps مرجعتش

اسأل بالترتيب ده:

1. هل الـ service enabled؟ systemctl is-enabled pm2-ubuntu.
2. هل هي لنفس اليوزر؟ قارن سطر User= في systemctl cat بـ whoami.
3. هل dump.pm2 موجود وحديث؟ ls -l ~/.pm2/dump.pm2، وقارن الوقت بآخر تغيير عملته.
4. هل مسار الـ node لسه موجود؟ قارن سطر Environment=PATH بـ which node.
5. إيه اللي اتكتب وقت الـ boot؟ journalctl -u pm2-ubuntu -b.
6. الـ app قام ووقع؟ pm2 logs --err --lines 50، وغالبًا السبب env ناقصة أو cwd غلط.

بديل: cron لو مفيش systemd

ده حل احتياطي، مش أحسن من الـ service. في crontab لنفس اليوزر:

which pm2      # خد المسار الكاملcrontab -e

@reboot /home/pmstest/.npm-global/bin/pm2 resurrect

لازم تكتب المسار الكامل، لأن cron بيشتغل بـ PATH صغير جدًا ومش هيلاقي pm2 بالاسم بس. ولو pm2 بيتشغّل بـ node من nvm، cron مش هيلاقي node برضه، فاكتب في السطر قبله PATH= بمسار فولدر الـ node.

خلّصت الفصل لما

• تشرح إن الـ service بتشغّل نفس الـ daemon اللي pm2 list بتكلمه
• تقرا systemctl cat وتعرف ExecStart وExecStop
• تعرف إن systemctl stop بيقفل كل الـ apps
• تفرق بين pm2 وsudo pm2
• متقلقش من inactive أول مرة
• تعمل reboot تجريبي وتختبر الـ endpoint
• تشخّص بالترتيب لو الـ apps مرجعتش
• تكتب cron بالمسار الكامل لو مفيش systemd