פתרון טעינה ויומן

פתרון ראשון

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

פתרון שני

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

temp=$(mktemp ./service.conf.XXXXXX)
chmod 600 "$temp"
printf 'capacity=24\ntimeout_ms=800\n' > "$temp"
mv -T -- "$temp" ./service.conf

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

פתרון שלישי

נשתמש בשדות כגון AMIT_EVENT=CONFIG_RELOAD_ACCEPTED, שדה דור חדש ושדה מזהה בקשת טעינה. בדחייה נשתמש בשם אירוע נפרד ובדור שנשאר פעיל, ונרשום קוד שגיאה מוגדר במקום התוכן שהכשיל את המפרש. את המערכים הדינמיים נשמור בחיים עד חזרת sd_journal_sendv.

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