ביטוי הקרון היקר ביותר שכתבתי אי פעם היה 0 0 * * 0. זה הפעיל אימייל תקציר שבועי עבור Laravel SaaS שבניתי, והייתי בטוח לחלוטין שזה אומר " חצות ביום האחרון של השבוע." זה אומר חצות יום ראשון. המודל המנטלי שלי אמר שהשבוע הסתיים בשבת. במשך חמישה שבועות, הלקוחות קיבלו את "שבוע בסקירה" אימייל באיחור של יום, ואף אחד בצוות לא תפס את זה כי אף אחד בצוות לא יכול היה לקרוא גם את cron - כולנו פשוט פזלו לחמשת השדות והנהנו.
That's הסוד המלוכלך של תחביר cron: כמעט כל מי שכותב אותו תואם דפוסים מביטוי קודם שהם זוכרים למחצה הפורמט הוא בן ארבעים פלוס שנים, צפוף מספיק כדי שדמות בודדת משנה את לוח הזמנים לחלוטין, והוא נכשל בשקט.There's אין שגיאת מהדר עבור " פועל ביום הלא נכון." העבודה פשוט פועלת ביום הלא נכון, לנצח, עד שמישהו שם לב.
א מנתח ביטוי Cron סוגר את הפער הזה אתה מדביק את הביטוי, והוא אומר לך באנגלית פשוטה מה יקרה בפועל - 0 0 * * 0 חוזר בתור "בשעה 00:00, ביום ראשון" - בנוסף כאשר הריצות הבאות יירה. that readback step is the difference between shipping a schedule and shipping a guess.I built the one on Toolz.dev because I got bired of context-switching to a terminal, and because the wp-cron mess I gontaled for years in WP Adminify teached me that scheduling bugs are the most patient bugs in software.
מדריך זה מכסה כיצד להשתמש במנתח, כיצד חמשת השדות פועלים בפועל (כולל שתי המוזרויות שגורמות לרוב תקריות הייצור), והיכן תחביר ה-cron שונה קרונטאב, GitHub Actions, Quartz ו-Laravel.
TL;DR: הדבק כל ביטוי crontab לתוך Toolz.dev Cron Parser וקבל תרגום רגיל לאנגלית בתוספת זמני ריצה קרובים - באופן מיידי, בצד הלקוח, ללא הרשמה לפני שאתה פורס לוח זמנים, ודא תמיד שני דברים: מספור יום השבוע (0 ו-7 הם שניהם יום ראשון) ואזור הזמן שבו המתזמן פועל (GitHub Actions הוא תמיד UTC). חבר אותו ל- ממיר חותמת זמן כאשר אתה צריך לתרגם את זמני הריצה הבאים על פני אזורים, ואת מחשבון הבדלי תאריך לשפיות-בדוק מרווחים.
תכונות מפתח
תרגום רגיל לאנגלית
תפקיד הליבה של המנתח הוא הפיכתו */15 9-17 * * 1-5 לתוך "כל דקה 15 אחרי שעה 9, 10, 11, 12, 13, 14, 15, 16 ו-17, בימים שני, שלישי, רביעי, חמישי ושישי." It's מילולית - הוא מונה ולא ממוטט את "9 עד 17" חזרה לטווח - והמילוליות הזו היא הנקודה. הספירה היא חד משמעית; טווח מסכם הוא הזדמנות נוספת לקריאה שגויה המשפט הוא משהו שאתה יכול להדביק בתיאור בקשת משיכה, לקרוא בקול בסטנדאפ, או להראות בעל עניין לא טכני הביטוי הגולמי הוא לא מניסיוני התרגום חשוב ביותר במהלך סקירת קוד: מבקר שיחתים גומי חמישה שדות סתמיים יתפוס מיד את " רגע, למה מופיעה שעה 17 כשהעבודה אמורה להיפסק ב-5 בערב?" כאשר כל שעה מאויתת התרגום הופך את לוח הזמנים לניתן לזיוף, וזה בדיוק מה שתחביר ה-cron הגולמי נכשל בו.
תצוגה מקדימה של הפעלה הבאה
לדעת איזה ביטוי אמצעים האם חצי מהבעיה; לדעת מתי זה שריפות הבא האם החצי השני המנתח מחשב את חמש זמני הביצוע הבאים כדי שתוכל לגלגל אותם נגד כוונתך. זה המקום שבו צצות טעויות עדינות - ביטוי שקורא מצוין באנגלית אבל מייצר הפעלה הבאה של " תוך 27 ימים" כי בלבלת בין יום לחודש לחודש, או כזה שיורה הלילה בשעה 03:00 כשהתכוונת לשעה 03:00 אחרי סוף השבוע. אני בודק את רשימת הריצה הבאה בכל פעם עכשיו, אפילו עבור ביטויים I'm בטוח לגביהם. במיוחד עבור ביטויים I'm בטוח לגבי - ראה את האנקדוטה הפותחת.
שני פרטים על אופן חישוב הזמנים הללו. ראשית, הם 'הוערכו ב הדפדפן שלך 's אזור זמן מקומי, לא UTC ולא השרת שלך's zone - כל ריצה מוצגת פעמיים, פעם אחת כחותמת זמן מקומית ופעם אחת כרגע UTC המקביל, כך שתוכל לקרוא את מה שמתאים ליעד הפריסה שלך. שנית, כאשר הן יום החודש והן יום השבוע מוגבלים, המנתח מחיל סמנטיקה אמיתית של cron's או ולא AND: 0 0 1 * 1 שריפות ב-1 בחודש ו בכל יום שני, לא רק בימי שני שנופלים ב-1. הכלל הזה מדכא אנשים מנוסים, ולראות חמישה תאריכים קונקרטיים מבהיר את זה באופן שהמשפט לעולם לא עושה.
קצה אחד מחוספס: ביטוי בלתי אפשרי כמו 0 0 30 2 * (30 בפברואר) מנתח כתקף, מתאר את עצמו בשמחה כ-"בשעה 00:00, ביום-חודש 30, בפברואר," ואז מציג רשימה ריקה של ההרצות הבאות. ריק אומר לעולם לא. זה 's נכון, אבל זה 's שקט - " לוח הזמנים הזה לעולם לא יירה" אזהרה היא השיפור הברור ויש לי ' עדיין לא בניתי אותו.
פירוט שדה אחר שדה
המנתח מפצל את הביטוי לחמשת מרכיביו - דקה, שעה, יום בחודש, חודש, יום בשבוע - ומראה מה כל אחד תורם זה משנה כי שגיאות cron הן כמעט תמיד בעיה של שדה בודד: הערך הנכון בעמודה הלא נכונה. 0 12 * * * (צהריים מדי יום) ו 12 0 * * * (12:12 בבוקר מדי יום... לא, 00:12 מדי יום) הם החלפה אחת בנפרד. לראות " שעה: 0" מסומן במפורש הוא איך אתה תופס את ההחלפה הזו תוך שתי שניות במקום שבועיים.
תמיכה בטווחים, שלבים ורשימות
ביטויים בעולם האמיתי נשענים חזק על תחביר האופרטור: 1-5 טווחים, */10 צעדים, 1,15 רשימות, ושילובים כמו 0 8-18/2 * * 1,3,5. המנתח מטפל בכל זה, כולל הטפסים המשולבים שמכשילים את הקוראים האנושיים. ערכי צעד על פני טווחים - 8-18/2 משמעות "כל 2 שעות מ-8 עד 18" - הם חוקיים, שימושיים וכמעט בלתי קריאים ללא כלי עבודה. אם אתה ' ירשת אי פעם crontab מלא באלה מ-sysadmin שעזב, אתה יודע מדוע תכונה זו קיימת.
אימות קפדני של חמישה שדות (כולל מה זה זכה 't קבל)
המנתח לוקח ביטויים סטנדרטיים של חמישה שדות ותו לא. הדבק @daily ואתה מקבל שגיאה - "צפוי 5 שדות (דקה שעה יום-חודש חודש יום-שבוע), קיבל 1" - לא תרגום. אותו דבר עבור @hourly, @weekly, ו @reboot. That's פער אמיתי ולא עיקרון עיצובי, ו-I' מעדיף לומר זאת מאשר לתת לך לגלות אמצע ניפוי באגים; פקודות המאקרו הקיצור נפוצות מספיק ב-crontabs אמיתיות שהן שייכות לכלי. עד שהם' נכנסים, תרגם ידנית: @hourly הוא 0 * * * *, @daily הוא 0 0 * * *, @weekly הוא 0 0 * * 0, @monthly הוא 0 0 1 * *, @yearly הוא 0 0 1 1 *. @reboot אין לו מקבילה של חמישה שדות בכלל - זה ' בלוח זמנים, הוא פועל פעם אחת בעת ההפעלה של daemon, עובדה שהפתיעה הרבה אנשים שמריצים הגירות מ-crontab.
ההקפדה משתלמת במקום אחר ביטוי קוורץ בן שישה שדות נדחה עם ספירת שדות במקום לקרוא אותו לא נכון בשקט ערכים מחוץ לטווח שמות השדה והטווח החוקי (Value 25 out of range for hour (allowed 0-23)). טווחים הפוכים כמו 5-1 נתפסים. והוא מקבל את הדברים ש-crontabs אמיתיים מכילים: שמות חודשים וימים (JAN, SUN), 7 כאיות שני של יום ראשון, והוויקסי 5/15 טופס משמעות "כל 15 החל מ-5". שווה לדעת בזמן שאתה 'מתרגמים את פקודות המאקרו האלה ביד: כל @daily עבודה בשרת יורה באותו רגע - חצות - אז ארבעים מהם הם ספייק עומס לילי. אני מפזר את שלי על פני דקות מוזרות (17 3 * * *, 43 4 * * *) בדיוק מהסיבה הזו.
עיבוד צד לקוח
המנתח פועל כולו בדפדפן שלך שום דבר שאתה מדביק לא מועלה, נרשם או מאוחסן. זה נשמע כמו שפת פרטיות של boilerplate עד שאתה זוכר מה crontabs מכילים בפועל: לוח הזמנים של הגיבוי שלך, תזמון הפעלת החיוב שלך, הדקה המדויקת שבה האבטחה שלך סורקת אש. תזמון תשתית הוא נתוני סיור. שמירה על אנשים אחרים & #39;s שרתים isn't פרנויה; it's פשוט לא יוצרת בעיה שבה אף אחד לא צריך להתקיים.
כיצד להשתמש במנתח Cron
שלב 1: הדבק או הקלד את הביטוי שלך
פתח את מנתח Cron ושחרר את הביטוי - מקובץ crontab, א schedule: חסום בזרימת עבודה של GitHub Actions, מניפסט Kubernetes CronJob או Laravel ->cron() שיחה. תחביר סטנדרטי של חמישה שדות עובד כפי שהוא; @daily ואחיו don't, אז הרחב את אלה לחמישה שדות תחילה. ואז לחץ על ניתוח. אם אתה ' מתחילים מאפס ולא מפענחים, הכפתורים המוגדרים מראש (כל דקה, שעה, יומי בחצות, ימי חול 9 בבוקר, 1 בחודש) טוענים ביטוי עבודה שאתה יכול לשנות שדה אחר שדה, לנתח מחדש תוך כדי.
שלב 2: קרא את התרגום בחזרה
זה הצעד שאנשים מדלגים וצריך't. קרא את הפלט האנגלי הפשוט והשווה אותו מול המשפט בראש שלך. אם כתבת את הביטוי בכוונה " בכל יום שני בשעה 9 AM" וה-readback אומר " בשעה 09:00 ביום-חודש 1" - מזל טוב, פשוט תפסת את החלפת העמודות הקלאסית לפני שהייצור עשה זאת. ה-readback הוא מבחן היחידה שלך.
שלב 3: אמת את זמני הריצה הבאים
בדקו את חמש ההוצאות להורג הקרובות האם התאריכים נוחתים היכן שאתם מצפים? האם הריצה הראשונה היא הלילה, מחר או בחודש הבא? שימו לב לפער בין הריצות - לא במקום */ שלב הופך את "כל 6 שעות" לתוך "כל דקה של כל שעה 6" (* */6 * * * vs 0 */6 * * *), וחמש ריצות בהפרש של דקה במקום בהפרש של שש שעות קשה לפספס. רשימה ריקה פירושה שלוח הזמנים לעולם לא יכול לירות.
שלב 4: חשבון עבור אזור זמן לפני פריסה
המנתח אומר לך כאשר יחסית לשעון; המתזמן שלך מחליט של מי שעון לפני שאתה פורס, אשר באיזה אזור זמן משתמשת המערכת המבצעת. GitHub פעולות: תמיד UTC, ללא חריגים. שרתים: לא משנה מה מערכת ההפעלה מוגדרת, לעתים קרובות UTC בתיבות ענן. Laravel: אזור הזמן של האפליקציה שלך, אלא אם כן אתה משרשר ->timezone(). תרגם זמן ריצה הבא דרך ממיר חותמת זמן אם אתה צריך לראות את זה באזור המקומי שלך או לקוח's.
צלילה עמוקה טכנית: איך ביטויי Cron באמת עובדים
פורמט חמשת השדות מגיע מ-Unix cron, מתוקנן בפועל על ידי Paul Vixie' יישום cron בסוף שנות ה-1980 - זה שתועד ב crontab(5) ועדיין משלוח, בצורת צאצא, ברוב מערכות לינוקס כיום. השדות, משמאל לימין:
| שדה | ערכים מותרים | הערות |
|---|---|---|
| דקה | 0–59 | |
| שעה | 0–23 | שעון 24 שעות, 0 זה חצות |
| יום בחודש | 1–31 | היזהרו חודשים ללא 31 |
| חודש | 1–12 או ינואר–דצמבר | שמות מותרים ב-Vixie cron |
| יום בשבוע | 0–7 או SUN–SAT | 0 ו-7 שניהם יום ראשון |
כל שדה מקבל * (כל ערך), רשימות (1,15), טווחים (1-5), ושלבים (*/10 או 20-59/5). That's כל הדקדוק.The complexity is't בתחביר - it's בשלושה מוזרויות התנהגותיות.
מוזר אחד: יום השבוע אפס. ל crontab(5), גם 0 וגם 7 פירושם יום ראשון. כמה יישומים ישנים או מחמירים יותר מקבלים רק 0. Quartz - מתזמן Java המשמש את ג'נקינס ומחצית מהתוכנות הארגוניות - מספרים ימים 1–7 החל מ- יום ראשון, אז Quartz's 2 הוא יום שני בזמן crontab's 2 הוא יום שלישי אם אי פעם תעביר לוחות זמנים בין מערכות, זה מחכה. תמיד לנתח, לעולם לא לתמלל.
מוזרות שתיים: יום-חודש או יום-שבוע. Here's האחד שכמעט אף אחד לא מכיר עד שהוא נושך אותם. When שניהם שדות יום החודש ויום השבוע מוגבלים (אף אחד מהם אינו מוגבל *), ויקסי קרון מנהלת את העבודה כאשר או או התאמות - OR, לא AND. כך 0 0 13 * 5 does't mean "Friday the 13th." It means "every 13th of the month AND every Friday." This is cordinated behavior in crontab(5) וזה מנוגד לאינטואיציה עמוקה. אם אתה באמת צריך " יום שישי ה-13," אתה צריך בדיקת תאריך בצד הסקריפט או מתזמן עם תחביר עשיר יותר.
Quirk שלוש: אזורי זמן ו-DST. לקרון אין שדה אזור זמן. הביטוי מתפרש במתזמן ' זמן מקומי, מה שזה לא יהיה. שתי השלכות קונקרטיות:
- GitHub Actions פועל
schedule:טריגרים ב-UTC, נקודה. זרימת עבודה מתוכננת ב0 9 * * *שריפות בשעה 9 בבוקר UTC - 4 או 5 בבוקר בניו יורק בהתאם לעונה, כי UTC עושה 't לצפות DST אבל הקהל המיועד שלך 's שעון עושה. שלך "9 AM דוח יומי" נסחף בשעה פעמיים בשנה אלא אם כן אתה מתאים את זרימת העבודה או מטפל בה בקוד. - בשרתים המוגדרים לאזור תצפית DST, לילה אחד בשנה השעה 02:00–03:00 'לא קיים, ולילה אחד זה קורה פעמיים. עבודה מתוזמנת בשעה 02:30 או מדלגת או יורה פעמיים בהתאם ליישום התיקון המשעמם, הנכון: תזמן עבודות קריטיות מחוץ לשעה 01:00–03:00 מקומי, או הפעל שרתים ב-UTC. אני עושה את שניהם.
פורמטים מורחבים. קוורץ משתמש בשישה או שבעה שדות (שדה שניות מובילות ושנה נגררת אופציונלית), בתוספת אופרטורים נוספים כמו L (אחרון), W (יום חול הקרוב ביותר), ו # (יום חול בחודש). חלק מהקרונים תומכים גם בשדה שניות מובילות. אם לביטוי שלך יש שישה שדות ואתה 'לא בטוח באיזה ניב מדובר, הדבק אותו במנתח - ביטוי בן שישה שדות המתפרש כחמישה שדות יפיק פלט שגוי בעליל, שהוא עצמו אבחנתי. ו @reboot, הברווז המוזר של המיתרים המיוחדים, הוא' לוח זמנים בכלל: הוא פועל פעם אחת בעת הפעלת הדמון, אשר במערכות מודרניות פירושו " בכל פעם שהתיבה מופעלת מחדש," עובדה שהפתיעה אנשים רבים שהריצו העברות מסד נתונים מ-crontab.
לסיור רחב יותר בכלי השירות למפתחים המשתלבים עם עבודת תזמון, ה מדריך כלי קידוד מכסה את כל ארגז הכלים.
מקרי שימוש נפוצים
איתור באגים בערך מתזמן Laravel
מתזמן Laravel's עוטף את cron בשיטות שוטפות - ->dailyAt('03:00'), ->weeklyOn(1, '8:00')- אבל פתח המילוט, ->cron('*/5 * * * 1-5'), הוא תחביר קרונטאב גולמי, ולוחות זמנים מסובכים מגיעים לשם. crontab המערכת פועל schedule:run כל דקה, ולארוול מחליט באופן פנימי מה 's בשל. כאשר פקודה מתוזמנת היא 't יורה, המהלך הראשון שלי הוא הדבקת ->cron() מחרוזת לתוך המנתח כדי לאשר את זה אומר מה ההערה מעל זה טוען.About מחצית הזמן, it doesn't. החצי השני, הבאג הוא timezone: האפליקציה מוגדרת ל UTC בעוד המפתח הניח זמן מקומי המנתח פותר את המקרה הראשון תוך שניות ומפנה אצבע לעבר השני.
Untangling wp-cron באתרי וורדפרס
וורדפרס נשלחת עם wp-cron, שהוא 't cron בכלל - it' הוא פסאודו-מתזמן שחוזר על עצמו בביקורים בדף, כך שאתר עם תנועה נמוכה 's "hourly" העבודה עשויה לפעול כל ארבע שעות, ואתר עתיר תנועה משלם מס קטן על כל בקשה במהלך שנות ה-WP Adminify שלי זה יצר זרם קבוע של " פוסטים מתוכננים aren't publishing" דוחות התיקון הסטנדרטי משבית את wp-cron (DISABLE_WP_CRON) ומפעיל wp-cron.php מ-crontab של שרת אמיתי - בשלב זה אתה ' כותבים ביטויי cron בפועל, בדרך כלל */5 * * * *, והמנתח מרוויח את זה תמשיך לאמת אותם. אם אתה מפעיל וורדפרס בכל קנה מידה, כדאי לבצע את ההעברה הזו השבוע, לא מתישהו.
אימות לוחות זמנים של פעולות GitHub
לוחות הזמנים של CI נכשלים בשקט: מבנה לילי שמפסיק לפעול עושה 't דף לאף אחד. בעת כתיבת א schedule: טריגר, אני מנתח את הביטוי, מסתכל על זמני הריצה הבאה, ואז מוסיף נפשית את היסט UTC. שני פרטים נוספים ספציפיים לפעולות: לוחות זמנים פועלים רק בענף ברירת המחדל, וניתן לעכב או להפיל ריצות בתקופות עומס גבוה - GitHub'המסמכים של עצמם אומרים זאת. אם התזמון המדויק חשוב, פעולות המופעלות על ידי cron הן הכלי הלא נכון; אם התזמון המשוער בסדר, לפחות הפוך את הזמן המשוער ל נכון זמן משוער.
ביקורת על Crontab בירושה
כל שרת ארוך חיים צובר crontab שנכתב על ידי אנשים שכבר לא עובדים שם.Running crontab -l והדבקת כל שורה דרך המנתח היא הביקורת המהירה ביותר שאני מכיר: תוך עשר דקות יש לך מלאי לוח זמנים באנגלית, וכמעט תמיד תמצא לפחות עבודה אחת לעשות משהו שאף אחד לא זכר - גיבוי שרץ פעמיים, סקריפט ניקוי ש מעולם לא התאים ליום שבו הוא היה אמור, א * * * * * זה היה צריך להיות 0 * * * * פטיש API שישים פעמים בשעה כאשר משווים crontab ישן מול חדש במהלך הגירה, ה כלי Text Diff לצד המנתח הופך את הסקירה למכנית.
תזמון Kubernetes CronJobs
K8s CronJobs משתמשים בתחביר סטנדרטי של חמישה שדות ומאז 1.27, תומכים בתחביר מפורש timeZone שדה - שיפור אמיתי לעומת cron קלאסי זרימת העבודה מנתח זהה: לאמת את הביטוי, לבדוק ריצות הבאות, ואז לאשר startingDeadlineSeconds ו concurrencyPolicy כסה את מצבי הכשל cron עצמו does 't. ביטוי יכול להיות מושלם והעבודה עדיין נערמת אם ריצה איטית חופפת את הטריגר הבא; המנתח מקבל את לוח הזמנים הנכון כדי שתוכל להקדיש את תשומת הלב שלך להגדרות התפעוליות הללו במקום זאת.
דיאלקטים של קרון בהשוואה
| ויקסי קרון / קרונטאב | פעולות GitHub | קוורץ | לארוול מתזמן | טיימרים systemd | |
|---|---|---|---|---|---|
| שדות | 5 | 5 | 6–7 (שניות, שנה) | 5 (דרך ->cron()) |
OnCalendar תחביר, לא קרון |
| מספור יום בשבוע | 0–7 (0 ו-7 = שמש) | 0–6 (0 = שמש) | 1–7 (1 = שמש) | עוקב crontab | שמות (Mon, Tue) |
| אזור זמן | מערכת מקומית | תמיד UTC | ניתן להגדרה | אזור זמן של אפליקציה או ->timezone() |
מערכת מקומית או Timezone= |
| מיתרים מיוחדים | @daily, @rebootוכו'. |
לא נתמך | לא נתמך | שיטות שוטפות במקום | OnBootSec=, קיצורים של לוח שנה |
| דיוק שניות | לא | לא (דקה ~5 דקות מעשי) | כן | לא (תקתוק לדקה) | כן |
| הטוב ביותר עבור | משרות שרת | לוחות זמנים של CI/CD | מערכות אקולוגיות של JVM | אפליקציות Laravel | שירותי לינוקס מודרניים |
מתי להשתמש באילו: crontab עבור עבודות שרת רגיל, טיימרים systemd כאשר אתה רוצה רישום וטיפול בתלות בחינם בלינוקס המודרנית, מתזמן המסגרת כאשר העבודה חיה בתוך האפליקציה שלך בכל מקרה, ולוחות זמנים של פעולות רק עבור משימות CI שסובלות תזמון מעורפל. לא משנה מה תבחר, הביטוי בן חמשת השדות הוא ה-lingua franca - וזו הסיבה שמנתח שמדבר אותו בצורה שוטפת שייך לסימניות שלך ליד שאר שלך ערכת כלים למפתחי אינטרנט.
שָׁוא
מהו מנתח ביטוי cron?
מנתח ביטוי cron הוא כלי שקורא תחביר crontab - כמו */15 9-17 * * 1-5- ומתרגם אותו לתיאור לוח זמנים באנגלית פשוטה, בדרך כלל לצד תצוגה מקדימה של זמני הביצוע הבאים. זה מאפשר לך לאמת מה לוח זמנים עושה בפועל לפני פריסתו, במקום לגלות שדה קריאה שגוי כאשר עבודה נדלקת בזמן הלא נכון בייצור.
מה המשמעות של חמשת השדות בביטוי cron?
משמאל לימין: דקה (0–59), שעה (0–23), יום בחודש (1–31), חודש (1–12) ויום בשבוע (0–7, כאשר גם 0 וגם 7 פירושם יום ראשון). כל שדה מקבל * עבור כל ערך, רשימות פסיקים, טווחי מקף ו / ערכי צעדים. כך 30 2 1 * * פירושו 02:30 ביום הראשון של כל חודש.
למה עבודת המקורבים שלי פועלת בזמן הלא נכון?
שתי הסיבות הנפוצות ביותר הן בלבול אזור זמן ושדה. Cron פועל במתזמן ' זמן מקומי - GitHub Actions תמיד משתמש ב-UTC, וגם שרתי ענן רבים עושים זאת - אז עבודה מתוכננת עבור "9 AM" עשויה לירות שעות חופש משעון הקיר שלך. הקלאסיקה האחרת היא החלפת שדות, כמו הכנסת ערך השעה בעמודה דקה. ניתוח הביטוי ובדיקת זמני הריצה הבאה תופסים את שניהם.
האם 0 ו-7 שניהם יום ראשון במקורבים?
ב-Vixie cron וברוב יישומי לינוקס, כן - ה crontab(5) דף אדם מאפשר גם 0 וגם 7 ליום ראשון. אבל זה לא אוניברסלי: מספרי קוורץ ימים 1–7 החל מיום ראשון, וכמה מנתחים קפדניים דוחים 7. בעת העברת ביטויים בין מערכות, אמת מחדש את השדה של יום השבוע במקום להניח שהמספור עובר.
מה עושה 0 0 13 * 5 בעצם לעשות?
לא " יום שישי ה-13." כאשר גם יום החודש וגם יום השבוע מוגבלים, cron הסטנדרטי מתייחס אליהם כאל OR: העבודה פועלת בכל 13 בחודש ו בכל יום שישי. זה מתועד התנהגות מקורב של Vixie ואחד מהפורמטים ' הכללים הכי לא מובנים. אם אתה צריך AND אמיתי, הוסף בדיקת תאריך בתוך הסקריפט עצמו.
כיצד שעון הקיץ משפיע על משרות קרונים?
בשרתים באזורי זמן צופים ב-DST, עבודות שמתוזמנות בין 01:00 ל-03:00 זמן מקומי יכולות לדלג על ריצה (כאשר שעונים קופצים קדימה) או לרוץ פעמיים (כאשר הם נופלים אחורה), בהתאם ליישום הדפוסים הבטוחים ביותר הם הפעלת שרתים ב-UTC או תזמון עבודות קריטיות מחוץ לחלון זה שימו לב שמתזמנים מבוססי UTC כמו GitHub Actions don' לא מדלגים על ריצות, אבל הזמן המקומי הם תואמים למשמרות בשעה פעמיים בשנה.
הוא @daily אותו דבר כמו 0 0 * * *?
כן - @daily (והמילה הנרדפת שלו @midnight) מרחיב בדיוק 0 0 * * * ב-vixie cron. שתי אזהרות. ראשית, מנתח Toolz.dev מקבל רק ביטויים של חמישה שדות, אז הדבק 0 0 * * * יותר מאשר @daily לעת עתה. שנית, כל @daily ג'וב יורה באותו רגע, כך ששרת עם רבים מהם מקבל ספייק עומס בחצות. פיזור עבודות יומיות על פני דקות ושעות מדורגות מונע את אותו עדר רועם עצמי.
האם מנתח cron Toolz.dev מעלה את הביטויים שלי?
לא. ה מנתח Cron פועל כולו בדפדפן שלך - ביטויים מנותחים בצד הלקוח ולעולם לא נשלחים לשרת, מתועדים או מאוחסנים. מכיוון ש-crontabs חושפים פרטים תפעוליים כמו תזמון גיבוי וריצות חיוב, הרחקתם משרתי צד שלישי היא ברירת מחדל הגיונית, ואתה יכול לאשר את ההתנהגות בעצמך בדפדפן שלך #39;s כרטיסיית רשת.
קרא אותו בחזרה לפני שאתה שולח אותו
חמישה שבועות של הודעות דואל מעכלות שמגיעות באיחור של יום זה לא הפסקה דרמטית אף אחד לא דפדף בי. That's בדיוק מה שמייקר באגים בתזמון: הם עושים ' לא מכריזים על עצמם, הם פשוט עושים בשקט את הדבר הלא נכון עד שלקוח מזכיר זאת בדרך אגב. ההרגל שתיקן לי את זה הוא 't משמעת או זיכרון טוב יותר לסדר בשטח - it's קריאה חוזרת של שלושים שניות. הדבק את הביטוי, קרא את המשפט באנגלית, הסתכל על חמישה תאריכים קונקרטיים, ואז פרוס.
שמור את מנתח Cron ליד הכלים שאליהם אתה ' תגיע באותה הפעלת ניפוי באגים: ה ממיר חותמת זמן כאשר זמן הריצה הבא צריך לעבור בין אזורים (I've כתב את מלכודות חותמת זמן של יוניקס שנושכים הכי חזק), ה מחשבון הבדלי תאריך למרווחי בדיקת שפיות, וה כלי Text Diff כאשר אתה' משווים crontab ישן מול חדש במהלך הגירה. ה מדריך כלי קידוד עובר על איך הסט משתלב יחד, והכל פועל בצד הלקוח - שעבור קובץ שמתעד בדיוק מתי הגיבויים והחיוב שלך פועלים, הוא ברירת המחדל ההגיונית היחידה.
