קטגוריה: it

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

מזה זמן רב היתה לי בעיה מאוד רצינית עם 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. הגעתי למצב "שהסתובבתי סביב הזנב של עצמי" עם הבעיה במקום לשחרר אותה ולחזור בשלבים מאוחרים יותר.

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

מתכנת IT

הרבה שנים שאני מנסה להסביר לאנשים מה המקצוע שלי. אני מנסה להסביר כי המקצוע שלי הוא "מתכנת IT", אבל אנשים חושבים כי אני מדבר על DevOps.
התשובה היא לא, זה לא DevOps.

תנו לי רגע להסביר מה זה בעצם IT, שכולם אוהבים להתייחס אליו.
IT הם ראשי תיבות של Information Technology. כלומר מי שמוגדר כאיש IT, מתעסק בטכנולוגיות העוסקות במידע.

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

איש DBA יודע למשל המון על IO ועל דיסקים, וזיכרון, אבל זה לא אומר שהוא יודע מספיק בשביל להחליף ציוד, או לבחור חומרה בצורה נכונה. הוא רק יודע מה מסוגל לתת ביצועים טובים, אבל האם לוח מסוים עדיף? האם שרת מסוג מסוים? האם בקר מסוים? האם מעבד מדגם אחד טוב יותר וכיוב', הם פחות מהמומחיות שלו. זה לא אומר שהוא אינו יודע, זה אומר שהוא פחות חי את זה. זה יותר סוג של by-product של העבודה, מאשר המומחיות.

להמשיך לקרוא

מזלגות נעוצים

בתקופה האחרונה, נעשו מספר פעולות fork לפרויקטים מוכרים, בהם node.js ודביאן.
בנוסף, פרויקט docker מקבל מתחרה, לאחר שחברת CoreOS הודיעה כי לא מקובל עליה הכיון של docker.

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

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

החשיבה כאילו systemd גוזל משהו, בכך שהוא בא לסדר בלאגן ובעיות שיש במערכת הקיימת כיום, מקבלת תירוצים של "נוצרת תלות במערכת", והתשובה שלי היא: "כי עד עכשיו התלות ב sysv לא היתה קיימת ?"

המאבקים המפגרים האלו, האם להשתמש בsystemd או לא, פוגעים בלינוקס, ולא האם systemd טוב או לא.

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

הרעיון הוא לא להיות תלוי בהחלטות של חברה מסחרית בפרויקט, ובכך להשאיר אותו פתוח בתפיסה, אם כי זה לא אומר שהתפיסה של המפתחים תהיה מוסכמת על שאר השוק …

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

Rocket
במידה ולא שמעתם על docker, אתם כנראה ישנים איפשהו, או שרחוקים מעולם ה IT. זה השם החם ביותר מאז שסייבר ומחשוב ענן נכנס לעולם, או אולי זה היה 42 ?

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

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

החברה של CoreOS, רוצים container ומשהו שזו כל ההתמחות שלו, אבל docker מתחיל להיות stack שלם של דברים, והם ממש לא אוהבים את זה, כי בסופו של דבר,זו סוג של תחרות, לא ?

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

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