دسکتاپ، Worker و محاسبات محلی · فصل ۲ — Supervisor، Executor و Coordinator · 179
Worker Supervisor به‌عنوان OS Service
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Worker Supervisor به‌عنوان OS Service». می‌تواند «Worker Supervisor به‌عنوان OS Service» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خلاصهٔ درس
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Worker Supervisor به‌عنوان OS Service».
می‌تواند «Worker Supervisor به‌عنوان OS Service» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خروجی این درس
می‌تواند «Worker Supervisor به‌عنوان OS Service» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
پیش‌نیازها
1. مسئله: Worker نباید به عمر Session کاربر وابسته باشد
اگر Worker از Tray یا Terminal تعاملی شروع شود، logout، reboot یا crash می‌تواند اجرای آن را قطع کند؛ حتی بدتر، چند launch path ممکن است دو Worker را هم‌زمان روی یک queue فعال کنند. هدف این درس تبدیل «اجرای یک process» به یک lifecycle قابل حسابرسی زیر مالکیت service manager سیستم‌عامل است.
2. مرز مالکیت: Supervisor چه چیزی را مالک است و چه چیزی را نه
Supervisor مالک long-lived lifecycle، service identity، startup dependency، state/log path، single-instance guard، bounded recovery و graceful stop است. اجرای Job با privilege محدود متعلق به LOC-007 است و coordinator protocol متعلق به LOC-008؛ پس این درس sandbox یا RPC envelope را جذب نمی‌کند.
3. Desired State را از Observed State جدا کنید
desired_state=RUNNING فقط intent است. observed_state می‌تواند STARTING، READY، STOPPING، FAILED یا CRASH_LOOP باشد. اگر desired و observed جدا نشوند، restart خودکار می‌تواند شکست واقعی را پشت ظاهر «همیشه روشن» پنهان کند.
4. Service Identity: هویت اختصاصی و کم‌اختیار
Service باید با identity مشخص و قابل audit اجرا شود، نه با account تعاملی کاربر و نه با privilege بیش از نیاز. در Windows، SCM سرویس را با security context پیکربندی‌شده اجرا می‌کند؛ در Linux نیز unit باید ownership و دسترسی‌های runtime خود را صریح نگه دارد. Service identity مرز Supervisor است، نه مجوز Executor برای هر Job.
5. Startup Dependency و Boot Ordering
شروع سرویس باید dependencyهای ضروری را از preference جدا کند. وجود network interface به معنی آماده‌بودن coordinator یا storage نیست. در ledger باید dependency، نوع آن، evidence و رفتار در حالت unavailable ثبت شود؛ اگر evidence کافی نیست، state باید STARTING یا NOT_READY بماند.
6. Process Running با Readiness برابر نیست
PID زنده فقط می‌گوید process وجود دارد. Readiness باید با evidence جداگانه مثل self-check محلی، queue initialization یا health state اثبات شود. تا وقتی readiness evidence موجود نیست، process می‌تواند RUNNING باشد ولی service برای پذیرش کار NOT_READY بماند.
7. Watchdog یک Signal صریح است، نه حدس از وجود Process
در systemd، watchdog با notification صریح service به manager تازه می‌شود؛ پس heartbeat watchdog evidence مشخص دارد. ولی حتی watchdog تازه نیز به‌تنهایی business readiness را ثابت نمی‌کند. در طراحی MAKNOW، watchdog و readiness دو ستون جدا در Recovery Ledger هستند.
8. Restart Policy باید محدود، شمارش‌پذیر و دارای Backoff باشد
Restart فوری و بی‌نهایت می‌تواند crash storm بسازد. Policy باید failure count، reset window، backoff و سقف تلاش‌ها را مشخص کند. اگر تعداد شکست‌ها در window از حد عبور کند، state به CRASH_LOOP می‌رود و recovery از automatic retry به operator escalation تغییر می‌کند.
9. Single-instance Guard و Duplicate Start
Service manager باید تنها مالک lifecycle باشد. Tray، Task Scheduler یا اسکریپت دستی نباید copy دوم Worker را شروع کنند. هر start attempt باید ownership token یا lock قابل بررسی داشته باشد؛ مشاهده دو instance فعال، حتی با readiness سبز، failure در ownership است و نباید PASS شود.
10. Graceful Stop، Drain و Stop Timeout
Stop باید ابتدا intake جدید را ببندد، کار در حال انجام را drain کند و سپس termination را ثبت کند. اگر drain تا timeout تمام نشود، forced termination باید با reason و exit evidence ثبت شود. ارسال stop signal به‌تنهایی اثبات STOPPED نیست.
11. Durable State Directory و Log Sink
State موردنیاز recovery نباید در temp session کاربر یا working directory مبهم بماند. مسیر state، log sink، ownership و retention باید مشخص باشند تا reboot یا تغییر user session، evidence را از بین نبرد. این مسیرها اطلاعات operational هستند و نباید secretهای Job را به Supervisor منتقل کنند.
12. Linux/systemd: Mechanism را از MAKNOW Policy جدا کنید
Restart=، WatchdogSec= و notificationهای watchdog ابزارهای systemd هستند؛ مقدار آن‌ها به‌خودی‌خود policy صحیح MAKNOW را تعریف نمی‌کند. MAKNOW از آن‌ها برای پیاده‌سازی lifecycle contract استفاده می‌کند ولی تصمیم READY یا CRASH_LOOP را از evidence ترکیبی می‌سازد.
13. Windows SCM: Service State، Account و Failure Actions
SCM database اطلاعات نصب و state سرویس را نگه می‌دارد؛ service با account/security context پیکربندی‌شده اجرا می‌شود و failure actions می‌توانند restart با delay/reset period داشته باشند. این primitiveها باید به همان lifecycle platform-neutral نگاشت شوند و نباید به‌عنوان proof سلامت application تفسیر شوند.
14. Lab: Worker Supervisor Service Contract & Recovery Ledger v1
در fixture، Tray Worker را شروع کرده، logout آن را حذف می‌کند و یک crash باعث start از دو مسیر شده است. شما باید جدول ۲۳بعدی service evidence را پر کنید، process-only readiness را رد کنید، crash loop را تشخیص دهید، duplicate ownership را متوقف کنید و stop/drain را با timeout ثبت کنید. پاسخ‌های expected در learner package وجود ندارند.
15. Transfer: Linux به Windows بدون کپی‌کردن Directiveها
در Transfer همان lifecycle را روی Windows بازسازی کنید: service manager، service identity، startup evidence، readiness/watchdog equivalent، bounded failure actions، graceful stop، durable paths و single-instance ownership. معیار خروج این است که contract platform-neutral ثابت بماند ولی mechanismها متناسب با target service manager تغییر کنند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 application
Build a supervisor service contract for a worker that must survive user logout and reboot without duplicate instances.
Q2 diagnosis
Explain why a live PID with missing readiness evidence is not enough to mark the worker READY.
Q3 decision
Issue a typed service decision after repeated failures inside the reset window and define the escalation trigger.
Q4 transfer
Map the same lifecycle from systemd to Windows SCM without copying platform-specific directives.
ملاک‌های ارزیابی (rubric)
- State separation: desired state and observed/readiness state remain distinct.
- Evidence discipline: process existence, watchdog and readiness are not collapsed into one signal.
- Bounded recovery: restart attempts, backoff, reset window and crash-loop escalation are explicit.
- Lifecycle ownership: duplicate starts and user-session coupling are rejected.
- Transfer: lifecycle semantics survive Linux→Windows while mechanisms change.
- Auditability: decision and reason trace to the service contract and recovery ledger.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
Use the eight synthetic fixtures to implement an evaluator that keeps desired state separate from observed service evidence. Your output should explain lifecycle, readiness/watchdog evidence, bounded recovery, ownership, and the final typed decision.
Do not treat PID existence, restart configuration, or a sent stop request as stronger proof than the evidence supports. The transfer case maps the same lifecycle to Windows SCM.