סובב יומן של שומר VPN בלי לשבור את הכותב

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

בחרו ביעד לפני מדיניות הסיבוב

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

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

כתבו את הקטע כך שיתאים לכותב

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

/var/log/vpn-watchdog.log {
    daily
    rotate 7
    create 0600 root root
    missingok
    notifempty
}

המדריך של logrotate מגדיר את המספר כמספר הגרסאות המסובבות שנשמרות, לא כערובה לשבעה ימים של היסטוריה, והמילה daily מוערכת כשהמשימה רצה ולא פועלת כמתזמן משל עצמה. ברוב ההפצות טיימר systemd או רשומת cron כבר מחזיקים בהפעלה הזאת, לכן בדקו איזה מהם קיים לפני שמוסיפים שני. התאמת הבעלות חשובה יותר ממספר השמירה. העתקת הרשאה של root בלבד לקובץ שנכתב בידי חשבון שירות עוצרת את התיעוד בסיבוב הבא, והכשל מופיע שעות אחר כך כחותמת זמן מיושנת ולא כשגיאה. אשרו את המשתמש של הכותב לפני שאתם מעתיקים קטע ממקום אחר.

כותב שלעולם אינו פותח מחדש זקוק לתיקון אחר

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

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

ביחידות ש-systemd מפעיל, כוונו את StandardOutput ליומן או לקובץ ותנו ליחידה להחזיק במחזור החיים. לולאת shell שמוסיפה דרך tee -a בלי גבול גודל היא הסידור שממלא מחיצה בזמן תקלה, כי בדיקה שנכשלת מתעדת לעתים קרובות הרבה יותר מבדיקה בריאה.

בדקו את הסיבוב בלי להמתין לטיימר

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

logrotate -d /etc/logrotate.d/vpn-watchdog
logrotate -f /etc/logrotate.d/vpn-watchdog
ls -l /var/log/vpn-watchdog.log*
tail -n 3 /var/log/vpn-watchdog.log
df -h /var/log

קראו את הפלט בסדר הזה. מעבר הניפוי אמור לנקוב בשם הקובץ ובפעולות שהוא מתכוון לבצע; הרצה כפויה אמורה להפיק את השם המסובב שציפיתם לו; ה-tail אמור להראות רשומה חדשה אחרי שהכותב ירוץ שוב. ערך df גדל עם קובץ נראה שמתכווץ פירושו בעיית התיאור שתוארה למעלה.

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

שמרו על אפשרות חזרה ועל תיעוד כתוב

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

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

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