עובדים עם קלוד קוד? מה שעון החורף עשה למערכת שלי בלילה אחד
במוצאי שבת 25.10.2026, בשתיים בלילה, השעון חזר שעה אחורה. התוכנה שמריצה משימות קבועות נכנסה ללולאה, אצלי ואצל הרבה אנשים בעולם. שתי מערכות שלי כתבו את אותה שורה 590 פעמים בשנייה, שעתיים ו-48 דקות, עד שש מיליון. הן לא ענו לאף אחד, ואף אחד לא קיבל הודעה. כאן: מה קרה, היומן עצמו, המספרים, ומה לבקש מקלוד קוד לבדוק אצלכם.
עובדים עם קלוד קוד (Claude Code)? בניתם לעצמכם בוט, תזכורות, מערכת קטנה שרצה לבד? יפה. עכשיו שאלה: מה שעון החורף קשור לזה?
במוצאי שבת, בשתיים בלילה, השעון חזר שעה אחורה. שתי מערכות שלי התחילו לכתוב את אותה שורה, שוב ושוב, ולא הפסיקו שעתיים וארבעים ושמונה דקות. כאן הכול: מה קרה, המספרים, היומן עצמו, מי עוד נפל, שלושה כללים, ומה לבקש מקלוד קוד לבדוק אצלכם.
הסיפור, צעד אחרי צעד
השעה שקרתה פעמיים
במעבר לשעון חורף השעון זז מ-02:00 ל-01:00. כלומר השעה אחת עד שתיים קרתה באותו לילה פעמיים: פעם בשעון קיץ, ופעם בשעון חורף. לרוב התוכנות זה לא משנה. למשימה שרצה כל כמה דקות זה משנה מאוד.
לולאה בלי יציאה
כמעט כל מערכת שרצה לבד מחזיקה משימות מתוזמנות: כל רבע שעה לבדוק תזכורות, כל שעה לשלוח דוח. מי שמריצה אותן היא ספרייה, קוד מוכן שמתכנתים, וגם קלוד קוד, לוקחים מהמדף. הספרייה מחזיקה לכל משימה "מתי הריצה הבאה", ובודקת כל רגע: הזמן הזה כבר עבר? אם עבר בלי שהמשימה רצה, היא כותבת אזהרה ליומן, מחשבת מה הריצה הבאה, ובודקת שוב.
בשתיים בלילה השעון חזר לאחת. התוכנה שאלה את עצמה: מתי הריצה הבאה? וקיבלה תשובה שכבר עברה, 01:15 של קודם. אז היא כתבה ליומן "פספסתי", שאלה שוב, וקיבלה שוב את אותה תשובה. וחוזר חלילה. לולאה בלי יציאה, שלא נותנת לתוכנה לעשות שום דבר אחר: לא לענות לבקשות, לא לשלוח תזכורות. ובכל סיבוב היא תופסת עוד קצת זיכרון, עד שהתוכנה נופלת.
שש מיליון פעמים אותה שורה
וזה הגיע גם אליי. שתי מערכות שלי התחילו לכתוב את אותה שורה ליומן. חמש מאות ותשעים פעמים בשנייה. שלושים וחמישה אלף בדקה. בזמן שלוקח לקרוא את המשפט הזה, עוד כמעט אלפיים. וככה, בלי לעצור, שעתיים וארבעים ושמונה דקות. בסוף: כמעט שש מיליון פעמים אותה שורה. אדם שכותב שורה בשנייה, יום ולילה בלי לישון, היה גומר את זה אחרי שבעים יום.
מה הציל, ומה חסר
כל הזמן הזה שתי המערכות לא ענו לאף אחד. הן קרסו ארבע פעמים. מה שהציל אותן: הן מוגדרות לקום לבד אחרי קריסה. בלי זה הן היו נשארות מתות עד שמישהו שם לב. מה שלא היה: אף אחד לא קיבל הודעה. לא על הקריסה, לא על שעתיים בלי תשובה, לא על היומן שתפח בלילה אחד. ידעתי על זה רק אחרי שלושה ימים.
אני לא כתבתי את הבאג הזה
הוא יושב בתוך ספרייה שיורדת כארבעה וחצי מיליון פעמים בשבוע. אם בניתם בנוד (Node, סביבה נפוצה לבניית מערכות כאלה) משימה שרצה כל כמה דקות, סיכוי טוב שהספרייה הזאת אצלכם.
שתי שאלות
כשהמערכת שלכם נופלת, היא קמה לבד? ומי מקבל על זה הודעה, ותוך כמה זמן? בהמשך העמוד: ניסוח מוכן שבודק את זה בשבילכם.
מהשטח
מתוך היומן של השרת שלי, שעון ישראל. שתי מערכות, בלי שמות.
- 02:00:00.003: שלוש אלפיות שנייה אחרי המעבר, שתי המערכות מתחילות לכתוב את אותה שורה: "פספסתי ריצה ב-01:15".
- 02:50, 03:20, 03:49, 04:48: ארבע קריסות, כי הזיכרון של המחשב נגמר. שתיים לכל מערכת. אחרי כל אחת המערכת קמה לבד, ונתקעה שוב באותה לולאה.
- 04:48:09: השורה האחרונה. מכאן הכול תקין.
- רביעי 28.10, 11:00: בדיקת אחסון שגרתית: 95% תפוס. ככה נודע לי.
| מה | כמה |
|---|---|
| שורות סך הכול | 5,949,160 |
| משך | שעתיים ו-48 דקות (168 דקות) |
| לשנייה | כ-590 |
| לדקה | כ-35,400 |
| לשעה | כ-2.1 מיליון |
| נפח ביומן | 1.8GB, כמו 120 אלף עמודים מודפסים (50 שורות בעמוד) |
| קריסות | 4, שתיים לכל מערכת |
| בלי תשובה | שעתיים ו-48 דקות למערכת אחת, שעתיים ו-23 דקות לשנייה |
| אדם שכותב שורה בשנייה, יום ולילה | 69 ימים |
| עד שידעתי | שלושה ימים |
שורה אחת מהיומן, כמו שהיא:
2026-10-25T02:00:00.003642+02:00 node[15772]: [NODE-CRON] [WARN] missed execution at Sun Oct 25 2026 01:15:00 GMT+0300
ואותה שורה עוד חמישה מיליון תשע מאות אלף פעמים.
זה לא רק אצלי
הספרייה הזאת היא אחת הנפוצות למשימות מתוזמנות בנוד: כ-4.5 מיליון הורדות בשבוע (לפי מונה ההורדות הציבורי, 20 עד 26.10.2026). באותו לילה, עשרים דקות לפני המעבר אצלי, מישהו באזור הזמן של ביירות פתח תלונה: אלפי שורות בשנייה, השרת לא עונה, הופעל מחדש יותר ממאה פעמים. ארבעה ימים לפני שגיליתי אצלי. שנה קודם, במעבר של אוקטובר 2025, מישהו באזור הזמן של וינה כתב שכל שלושת השרתים שלו נפלו במעבר השעון הראשון מאז שהכניס את הספרייה. נפלו, כלומר הפסיקו לענות עד שקמו מחדש. לא נהרסו.
חלק מהבעיה תוקן בגרסה שיצאה ביוני 2026. אצלי רצה גרסה מיולי 2025. ולפי התלונה מביירות, גם בגרסה האחרונה נשארה סיבה שנייה לתקיעה. אם קלוד קוד בנה לכם משימה שרצה כל כמה דקות, כדאי לדעת איזו גרסה הוא הוריד.
ומה אם זה היה קורה ביום
אצלי זה קרה בלילה, ולמיטב ידיעתי לא נפגע כלום. בעשר בבוקר אלה היו כמעט שלוש שעות שבהן מי שכותב לבוט לא מקבל תשובה, ואף אחד לא יודע, כי הכול נראה דולק.
שלושה כללים
ככה אני עובד, ושלושתם ביחד הם התשובה לשאלה "מה קורה כשהמערכת נופלת".
- קמה לבד. תהליך שמת חוזר אוטומטית. זה הכלל היחיד שהיה אצלי, והוא זה שהציל.
- ליומן יש גבול. קובץ יומן לא עובר גודל מסוים, אף פעם. אצלי לא היה גבול, ו-1.8GB נכתבו בלי שאף אחד עצר. באחסון של 40GB זה עוד עבר. באחסון קטן יותר זה היה יכול למלא את השרת כולו, כולל המקום לגיבוי הלילה.
- מישהו מקבל הודעה. כשמשהו קורס, כשהמערכת לא עונה, כשהאחסון מתמלא: אדם מקבל הודעה. לזה קוראים ניטור והתראה. בלעדיו לא מרגישים שזה קרה.
לבדוק אצלכם
שתי שאלות. אם בניתם בעצמכם, שואלים את קלוד קוד. אם מישהו בנה לכם, שולחים לו את אותן שאלות.
- כשהמערכת שלי נופלת, היא קמה לבד?
- מי מקבל על זה הודעה, ותוך כמה זמן?
ולמי שעובד עם קלוד קוד, ניסוח מוכן שבודק את כל הסיפור הזה במערכת שלכם. מדביקים בשיחה בתוך תיקיית הפרויקט:
תבדוק את המערכת הזאת בחמישה דברים ותענה לי בעברית ברורה, בלי לשנות כלום בינתיים: 1. אילו משימות מתוזמנות יש כאן (cron, setInterval, node-cron וכדומה), באיזו תדירות כל אחת רצה, ואיזו ספרייה מריצה אותן ובאיזו גרסה. 2. האם משימות שרצות יותר מפעם בשעה מוגדרות באזור זמן בלי מעבר שעון (UTC), ואם לא, מה יקרה במעבר הבא לשעון קיץ או חורף. 3. אם התהליך קורס, מי מרים אותו מחדש (systemd, pm2, docker restart), ואם אין כזה, להגיד. 4. לאיזה קובץ נכתב הלוג, והאם יש לו גבול גודל. 5. אם המערכת לא עונה או שהדיסק מתמלא, האם מישהו מקבל הודעה, ואיך. בסוף: טבלה קצרה של מה בסדר, מה חסר, ומה היית מתקן קודם.
למתכנת: הפרטים הטכניים
הספרייה: node-cron, אצלי גרסה 4.2.1 (יולי 2025). הקוד שנתקע, מתוך src/scheduler/runner.ts בגרסה הזאת:
if (expectedNextExecution && expectedNextExecution.getTime() < currentDate.getTime()) {
while (expectedNextExecution.getTime() < currentDate.getTime()) {
logger.warn(`missed execution at ${expectedNextExecution}! ...`);
expectedNextExecution = this.timeMatcher.getNextMatch(expectedNextExecution);
runAsync(this.onMissedExecution, expectedNextExecution, defaultOnError);
}
}
ה-while מניח ש-getNextMatch תמיד מחזיר זמן מאוחר יותר. בשעה כפולה זה לא נכון, ואין שום הגנה. התיקונים #508, #517 ו-#533 מוזגו ביוני 2026 ויצאו בגרסה 4.3.0 (17.6.2026). הגרסה העדכנית היום: 4.6.0.
תלונה #624 (24.10.2026, אזור זמן ביירות): המדווח כתב בהתחלה 4.6.0 ותיקן שהיומנים שלו מגרסה 4.2.1; משתמש אחר שחזר את התקיעה גם ב-4.2.1 וגם ב-4.6.0, כנראה בגלל סיבה שנייה (nowWithoutMs). נכון ל-28.10 אין תגובת מתחזק, ותיקון מוצע (PR #626) פתוח. תלונה #492 (26.10.2025, אזור זמן וינה) היא על ^4.2.1 בדיוק, וסיבת הנפילה שם: הזיכרון נגמר.
התיעוד הרשמי (פרק Timezones and DST ב-README הנוכחי; ב-README של 4.2.1 אין אזכור) ממליץ להריץ משימות במרווח קבוע באזור זמן בלי מעבר שעון, למשל UTC. לפי #624 מה שקובע הוא אזור הזמן של התהליך כולו (TZ), לא רק האפשרות timezone של המשימה. אצלי נפלו רק משימות שרצות יותר מפעם בשעה; המשימה היומית של 03:00 לא. מה שהציל: systemd עם Restart=always. מה שלא היה: logrotate עם גבול גודל, והתראה. ועוד נתון ליומן: 1.8GB הם בערך 300 מיליון טוקנים, הערכה לפי 6 תווים לטוקן. אף אחד לא יקרא את זה, גם לא קלוד.
מה עוד לא יודעים, ומה אני מתקן
- כל מערכת קרסה פעמיים וקמה שלוש פעמים. בפעמיים הראשונות היא נתקעה שוב, ובשלישית יצאה מהלולאה. למה דווקא בשלישית? לא בדקתי.
- האם מעבר האביב, שבו שעה נעלמת במקום להיכפל, עושה משהו דומה. לא נבדק, ואבדוק לפני מרץ.
- האם תזכורות שהיו אמורות לצאת בין שתיים לחמש בבוקר באמת לא יצאו. ייתכן. בלילה, בלי נזק שידוע לי.
מה אני מתקן אצלי: גבול גודל ליומן, העברת המשימות שרצות כל כמה דקות לאזור זמן בלי מעבר שעון, והתראה על מערכת שלא עונה ועל אחסון שמתמלא. נכון ל-29.10.2026 זה עוד לא רץ, ואעדכן כאן כשירוץ. המעבר הבא הוא לשעון קיץ, במרץ.
הצעד הבא
שלחתם את שתי השאלות, קיבלתם תשובה ולא ברור לכם מה היא אומרת? כתבו לי מה המערכת ומה קלוד ענה. ומי שמעדיף שהמערכת תרוץ על שרת שמישהו אחר מחזיק ומתחזק: זה המסלול שבו בונים לכם.
