Gateway

قفل Gateway

چرا

فقط یک فرایند Gateway باید مالک یک پیکربندی و درگاه مشخص روی یک میزبان باشد؛ Gatewayهای اضافی را با پروفایل‌های مجزا و درگاه‌های یکتا اجرا کنید.
بدون باقی گذاشتن فایل‌های قفل منقضی پس از خرابی یا SIGKILL، به کار ادامه دهد.
هنگامی که Gateway دیگری از قبل مالک درگاه است، سریعاً با خطایی واضح متوقف شود.

راه‌اندازی، مالکیت تک‌نمونه‌ای را به‌ترتیب در دو مرحله مستقل اعمال می‌کند:

قفل فایل یک فایل قفل مختص هر پیکربندی را در دایرکتوری قفل وضعیت به دست می‌آورد. هنگام به دست آوردن آن، راه‌اندازی درگاه پیکربندی‌شده را برای یافتن شنونده‌ای فعال بررسی می‌کند تا مالک منقضی‌شدهٔ قفل (ناشی از خرابی) را تشخیص دهد.
اتصال سوکت شنوندهٔ HTTP/WebSocket (با مقدار پیش‌فرض ws://127.0.0.1:18789) را به‌عنوان یک شنوندهٔ انحصاری TCP متصل می‌کند.

هر لایه می‌تواند به‌طور مستقل شکست بخورد و GatewayLockError مختص خود را ایجاد کند.

اگر فایل قفل وجود نداشته باشد، فرایند مالک ثبت‌شده دیگر در حال اجرا نباشد، یا بررسی درگاه مالک هیچ شنوندهٔ فعالی را نشان ندهد، راه‌اندازی قفل را بازپس می‌گیرد و ادامه می‌دهد.
اگر قفل فعالانه در اختیار باشد و هیچ‌یک از شرایط بالا صدق نکند، راه‌اندازی پیش از صرف‌نظر کردن، حداکثر تا ۵ ثانیه (به‌طور پیش‌فرض) دوباره تلاش می‌کند:
text
```
GatewayLockError("gateway already running (pid <pid>); lock timeout after <ms>ms")
```

در صورت وقوع EADDRINUSE، راه‌اندازی عملیات اتصال را حداکثر ۲۰ بار با فاصله‌های ۵۰۰ میلی‌ثانیه‌ای (در مجموع حدود ۱۰ ثانیه) دوباره امتحان می‌کند تا پنجرهٔ TIME_WAIT پس از خروج اخیر یک فرایند سپری شود.
اگر پس از تلاش‌های مجدد، درگاه همچنان در حال استفاده باشد:
text
```
GatewayLockError("another gateway instance is already listening on ws://127.0.0.1:<port>")
```

سایر خطاهای اتصال:

text

GatewayLockError("failed to bind gateway socket on ws://127.0.0.1:<port>: <cause>")

هنگام خاموش شدن، Gateway سرور HTTP/WebSocket را می‌بندد و فایل قفل را حذف می‌کند.

اگر درگاه توسط فرایند دیگری غیر از Gateway اشغال شده باشد، خطا یکسان است؛ درگاه را آزاد کنید یا با openclaw gateway --port <port> درگاه دیگری انتخاب کنید.
تحت نظارت یک مدیر سرویس، فرایند جدید Gateway که با یکی از دو خطای بالا مواجه شود، ابتدا /healthz را در فرایند موجود بررسی می‌کند. اگر آن فرایند سالم باشد، فرایند جدید به‌جای شکست خوردن، کنترل را در اختیار آن باقی می‌گذارد. در systemd، با کد 78 خارج می‌شود؛ تنظیم RestartPreventExitStatus=78 در واحد مانع می‌شود که Restart=always در اثر تداخل قفل یا EADDRINUSE وارد حلقه شود. اگر فرایند موجود هرگز سالم نشود، تلاش مجدد برای بررسی سلامت دارای محدودیت زمانی است و سپس راه‌اندازی به‌جای تکرار بی‌پایان، با خطای قفل بالا شکست می‌خورد.
برنامهٔ macOS پیش از راه‌اندازی Gateway، محافظ سبک PID مخصوص خود را حفظ می‌کند؛ قفل فایل و اتصال سوکت بالا، سازوکارهای واقعی اعمال محدودیت در زمان اجرا هستند.

Was this useful?