מי הרג את התוכנה שלי?

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

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

כאשר אני מריץ ידנית את התוכנה, הכל עובד ללא בעיות וההתנהגות היא כמצופה.
אבל כאשר אני מריץ אותה ב systemd, וההגדרות של המערכת היא יצירה של הרבה פרוססים, המערכת נתקעת או מתה מהר מאוד ללא שגיאה כלשהי (לרוב מתה מהר).

מחקר

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

התחלתי לשחק קצת עם הגדרות systemd בכיוונים של type ב service שיצרתי, אבל זו לא היתה הבעיה.

התחלתי לחשוב כי אולי מדובר במשתני סביבה, או אפילו limits שונים, אבל הליכה ל pid תחת proc לא הראתה משהו ממש שונה שהרים לי נורה אדומה או שוני הנדרש ממני מעבר להגדרות הסביבה עצמה שהוגדרו.

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

על מנת להבטיח כי זו אינה הבעיה, עשיתי הרצה עם detach ואז התנתקות מה ssh.
חזרתי לשרת אחרי עשר דקות בערך והמערכת עדיין רצה ללא בעיה, למרות שכבר לא היה לה טרמינל, הצלחתי לשלול את זה לגמרי (?).

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

במקרה באחד הבאגים, היתה שאלה אשר ביקשה לקבל מידע על הגדרות בנושא של systemd.kill ושיש לבדוק אותו.

כאשר התחלתי לחפש על הנושא במנוע חיפוש, גיליתי כי מרבית השאילתות במנוע החיפוש היו איך "להרוג" את התוכנה עם systemd ואיך שולחים אותות (סיגנאלים) עם systemd, ופתאום האתר החביב על כולם stack-overflow גילה לי שיש אופציה ששוה לבדוק בשם KillMode (ואתם חשבתם כי דף 3-4 במנוע חיפוש זה מקום שפתרונות באים למות בהם).

חיפוש של systemd.kill עם KillMode הוביל אותי לתוצאות רלוונטיות יותר.

מציאת פיתרון

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

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

מסתבר כי ברירת המחדל היא להרוג "קבוצה" של תהליכים, כלומר התהליך שלי והבנים שלו, גם אם אני הרצתי עם exec ומנותק לגמרי מהבנים, עצם זה שהתהליך הריץ עוד דברים בזמן עליה, תגרום לכך שהיציאה של התהליך (במקרה הזה), תהרוג את הבנים (תודה stack overflow להסבר).

הפיתרון היה לשים

KillMode=process

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

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

מבט לאחור

היו לי מספר דברים מאוד מביכים:

1. לא שמתי לב כי בתחתית התיעוד של כל תיעוד בנושא יש הפניה לעוד נושאים עם קישור.
2. החיפושים שלי היו שגויים ובדיעבד רק כאשר הבנתי שהמילים שלי היו לא נכונות התחלתי למצוא מידע רלוונטי.
3. הגעתי למצב "שהסתובבתי סביב הזנב של עצמי" עם הבעיה במקום לשחרר אותה ולחזור בשלבים מאוחרים יותר.

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