פתרון חיי שירות

פתרון ראשון

נשווה את זמני היומן של תחילת התהליך ושל המעבר למצב פעיל. העברת הודעת המוכנות לפני ההכנה מאפשרת למנהל להכריז על מוכנות מוקדם יותר, אך אינה מקצרת את ההכנה. לקוח תלוי עלול לקבל כשל בזמן שבו המפקח כבר מציג שירות פעיל. התיקון הוא לשלוח הודעה אחרי בדיקת המשאבים הדרושים לבקשה הראשונה.

פתרון שני

נוסיף לשורת ההפעלה את הארגומנט ונבצע טעינה מחדש והפעלה מחדש. נבדוק את הנתונים הבאים לפני איפוס מצב הכשל.

systemctl show amit-notify-lab.service -p Result -p NRestarts -p ExecMainStatus
journalctl -u amit-notify-lab.service --no-pager -n 80

הכשל הצפוי קשור לפיקוח על פעימת החיים, ולא להחזרת שגיאה מפונקציית ההפעלה. כאשר ניסיונות חוזרים מגיעים למגבלה, מנהל השירות מפסיק לנסות לפי חלון ההגבלה. פעימות מתהליכון שאינו תלוי בלולאה התקועה היו מוכיחות רק שאותו תהליכון עדיין חי.

פתרון שלישי

נחליף את ההמתנה האחרונה בקטע הבא כדי להמחיש ניקוז אמיתי של תהליכונים. הקטע משתלב אחרי הודעת העצירה בתוכנית ההרצאה.

let workers: Vec<_> = [100_u64, 400, 900].into_iter().map(|millis| {
    std::thread::spawn(move || {
        std::thread::sleep(Duration::from_millis(millis));
        println!("completed={millis}");
    })
}).collect();
for worker in workers { worker.join().unwrap(); }

במודל הזה העבודות מתחילות בעת הניקוז לצורך ניסוי בלבד. בשירות האמיתי נאסוף את העבודות שכבר התקבלו ונעצור יצירת חדשות. גבול עצירה קצר מהעבודה הארוכה מאפשר למפקח לסיים את התהליך לפני השלמתה, ולכן אין להבטיח שכל עבודה בהכרח הושלמה.

הוראת סדר קובעת מי קודם כאשר שתי יחידות מופעלות. תלות נדרשת גורמת לצירוף היחידה האחרת לפעולה ומגדירה קשרי כשל נוספים. לעיתים צריך את שתיהן, ואפילו אז היישום חייב לטפל בהיעלמות התלות לאחר האתחול.