0 10 * * 3 או * 10 * * 3? קראו את שדה הדקות

שני הביטויים נראים כמו בוקר יום רביעי, ורק אחד מהם פירושו פעם אחת. 0 10 * * 3 מופעל בשעה 10:00 ביום רביעי; * 10 * * 3 מופעל בכל דקה של השעה העשירית, ששים הזדמנויות להפעיל את אותו מנהרה. אם הפקודה היא מפעיל שאינו בודק אם קיימת הפעלה, הגרסה השנייה אינה טעות בתזמון, היא לולאה שמייצרת בעלים מתחרים. קראו את שדה הדקות לפני כל דבר אחר.

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

שדה הדקות קובע כמה פעמים

המספר המוביל הוא הדקה, ולכן 0 10 * * 3 היא הדקה הראשונה של השעה העשירית ביום רביעי. החלפתו בכוכבית משמרת את השעה ואת היום ומסירה את תכונת הפעם-היחידה, מה שמייצר ששים התאמות. cron אינו מסיר כפילויות: כל התאמה מפעילה את הפקודה שוב. זו אינה דקות-דקות של cron, זו סמנטיקה של שדות, וכדאי לקרוא את העזר של המתזמן המותקן, כי סדר השדות ועמודת שם המשתמש האופציונלית שונים בין crontab של משתמש ל-crontab של המערכת.

בדקו בפקודה לא מזיקה שכותבת חתימת זמן משלה במשך יום. שורה אחת ביומן היא לוח זמנים; ששים שורות בתוך שעה הן שיעור.

מה הפעלה שנייה עושה לראשונה

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

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

ספרו את השדות לפני הפקודה

crontab של משתמש ושל מערכת נבדלים בשאלה אם מופיעה עמודת שם משתמש לפני הפקודה. רשומה שהועתקה ביניהם או רצה תחת החשבון הלא נכון או מעבירה את שם המשתמש כמילה הראשונה של הפקודה. בדקו את העזר המותקן ולא מדריך, וספרו את השדות בשורה שלכם. רשומה בת חמישה שדות עם מילה שישית לפני הפקודה היא crontab של מערכת; אותה שורה ב-crontab של משתמש מנסה להריץ את המילה הזו כתוכנית.

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

המתינו למוכנות, לא לשעון

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

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

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