Gateway

قفل Gateway

لماذا

تأكد من تشغيل مثيل Gateway واحد فقط لكل منفذ أساسي على المضيف نفسه؛ ويجب أن تستخدم مثيلات Gateway الإضافية ملفات تعريف معزولة ومنافذ فريدة.
تحمّل الأعطال/SIGKILL من دون ترك ملفات قفل قديمة.
افشل سريعًا مع خطأ واضح عندما يكون منفذ التحكم مشغولًا بالفعل.

يحصل Gateway أولًا على ملف قفل لكل تهيئة ضمن دليل أقفال الحالة، ويفحص المنفذ المهيأ بحثًا عن مستمع موجود.
إذا كان مالك القفل المسجل غير موجود، أو كان المنفذ حرًا، أو كان القفل قديمًا، تستعيد عملية بدء التشغيل القفل وتتابع.
بعد ذلك يربط Gateway مستمع HTTP/WebSocket (الافتراضي ws://127.0.0.1:18789) باستخدام مستمع TCP حصري.
إذا فشل الربط مع EADDRINUSE، ترمي عملية بدء التشغيل GatewayLockError("another gateway instance is already listening on ws://127.0.0.1:<port>").
عند الإيقاف، يغلق Gateway خادم HTTP/WebSocket ويزيل ملف القفل.

إذا كانت عملية أخرى تحتفظ بالمنفذ، ترمي عملية بدء التشغيل GatewayLockError("another gateway instance is already listening on ws://127.0.0.1:<port>").
تظهر حالات فشل الربط الأخرى على هيئة GatewayLockError("failed to bind gateway socket on ws://127.0.0.1:<port>: …").

إذا كان المنفذ مشغولًا بواسطة عملية أخرى، فالخطأ هو نفسه؛ حرر المنفذ أو اختر منفذًا آخر باستخدام openclaw gateway --port <port>.
تحت مشرف خدمة، تترك عملية Gateway جديدة ترى مستجيب /healthz سليمًا موجودًا تلك العملية مسيطرة. على systemd، يخرج مشغّل النسخة المكررة بالرمز 78 بحيث يمنع الإعداد الافتراضي RestartPreventExitStatus=78 خيار Restart=always من الدخول في حلقة بسبب تعارض قفل أو EADDRINUSE. إذا لم تصبح العملية الموجودة سليمة أبدًا، تكون المحاولات محدودة وتفشل عملية بدء التشغيل بخطأ قفل واضح بدل الدوران إلى الأبد.
لا يزال تطبيق macOS يحتفظ بحارس PID خفيف خاص به قبل تشغيل Gateway؛ ويُفرض قفل وقت التشغيل بواسطة ملف القفل إضافة إلى ربط HTTP/WebSocket.