ארכיון חודשי: ספטמבר 2021

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

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

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

שכתוב הגדרות עבור neovim 0.5

ב2017 עברתי מ VIM לפרויקט חדש (יחסית) בשם neovim אשר שם לו למטרה לבצע refactoring ב VIM ולהסיר קוד ישן, לתקן קוד קיים בעייתי, בו בעת להמשיך את VIM והתפתחות שלו.

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

לאחרונה שוחררה גרסה 0.5 ל neovim אשר מביאה המון חידושים ותוספות.
בין היתר גם:

  • חלון Popup.
  • תמיכה מלאה ב Lua כשפה first class (ביחד עם VimL).
  • תמיכה ב LSP.
  • תמיכה ב tree-sitter.
  • תוספות UI (למשל ל Popup message).

ועוד.

השינויים שלי

בחודשים האחרונים עברתי לעבוד עם coc.nvim אשר מנסה לספק השלמה אוטומטית, תמיכה ב LSP, תמיכה ב Linting ואפילו Fuzzy Finder, וכל זה בשימוש של תוספים המבוססים על Visual Studio Code וכתוב ב node.js.

הבעיות שלי עם coc.nvim שיש לי איתו צרות של CPU גבוה מאוד ובנוסף זיכרון שמתמלא כאשר אני עובד עם קבצים של אלפי שורות קוד שכולם פתוחים ב buffer כי אני עובר בין אחד לשני הרבה.
בנוסף לזה, הייתי מוצא מספר process של LSP שונים לאותה שפה (בפורטים שונים) עם הודעות שגיאה ב messages כשהוא מנסה להעלות אותם ונכשל (עד שמוצא פורט פנוי).

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

nvim הנוכחי שלי

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

אלו הטכנולוגיות העיקריות שאני משתמש בהם.

השינוי מאפשר לי להתאים כלים עבור neovim עם היכולות שלו ולמעשה אני מסיר תוספים לא נדרשים שהייתי צריך אותם ב vim 7 כי לvim עצמו לא היתה תמיכה בדברים.

עבור צביעת התחביר בחרתי לעבור לשימוש ב tree-sitter, תוסף שאמור לספק תמיכה מדוייקת יותר מאשר הצביעה ה"רגילה" המשתמשת בregex, אשר נמצא בשימוש אף הוא אצלי, במידת הצורך.

השימוש שלי ב nvim-lsp מאפשרת לי לקבל הגדרות ברירת מחדל (שאני יכול לעקוף) למנועים מוסימים ובכך אני לא זקוק ל ALE לדעת על בעיות מצד אחד, ומצד שני אין לי צורך ב coc להשלמה.
זה מאפשר לי גם לספק כלי חדש לראות symbols שונים עם LSP בנוסף ל ctags למשל, ולכן אני משתמש ב vista.vim במקום Tagbar.

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

עבור מערכת ה Fuzzy Finding החלטתי לעבוד עם Telescope. התוסף מכוון אצלי לעבוד עם ripgrep בברירת מחדל, אבל יש לי גם תמיכה ל fzf במידת הצורך.

יכולות telescope

השלמה אוטומטית שלי היא כאמור באמצעות ddc.vim אשר משתמש בdino, ולמעט באג בהשלמה של zsh (אשר ביטלתי את התוסף), החתימה שלו מאוד קטנה בזיכרון וב cpu שלי, ומצד שני קל מאוד לקינפוג, אבל רק אחרי שמבינים את הגישה שלו (אשר לא אינטואיטיבית).

השלמה אוטומטית, פלוס הדפסת הcommit האחרון (שלא קיים) בשורה שאני עומד עליה

בנוסף, ל snippets שהייתי עובד איתם בצורה רגילה, החלטתי להוסיף לשם שינוי גם snippets לbolier plate שאני עושה המון בשפות שונות ואין לי snippets עבורם. החיבור עם ddc עובד ממש יפה לרוב.
מערכת ה Snippets שבחרתי היא UltiSnips.

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

הצגת שגיאות מבסיס LSP

סיכום

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

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