แยกวิเคราะห์และสร้างนิพจน์ Cron
อ่านนิพจน์ cron ของ Unix, Spring, Quartz และ AWS ดูเวลาทำงานครั้งถัดไปในเขตเวลาใดก็ได้ หรือสร้างนิพจน์ทีละฟิลด์
ตารางเวลา
รายละเอียดแต่ละฟิลด์
| ฟิลด์ | นิพจน์ | ค่า |
|---|
เวลาทำงานครั้งถัดไป
ตัวสร้างแบบภาพ
เลือกวิธีการวนซ้ำของแต่ละฟิลด์ “ค่าที่ระบุ” รับรายการเช่น 1,15 หรือ MON,WED “ช่วง” รับจาก-ถึงเช่น 9-17 “ทุก N” รับช่วงห่าง
อักขระพิเศษ
| * | ทุกค่าของฟิลด์ |
| , | รายการค่า เช่น 1,15,30 |
| - | ช่วง เช่น 9-17 หรือ MON-FRI |
| / | ช่วงห่าง เช่น */15 = ทุก 15; 5/15 = เริ่มที่ 5 ทุก 15 (ไม่มีใน Unix cron) |
| ? | ไม่ระบุค่า Quartz และ AWS กำหนดให้ใช้ในฟิลด์วันที่หรือวันในสัปดาห์ |
| L | สุดท้าย: L ในวันที่ = วันสุดท้าย; L-3 = สามวันก่อนหน้านั้น; 5L ในวันในสัปดาห์ = วันพฤหัสบดีสุดท้าย (การนับเลขแบบ Quartz) |
| W | วันทำงานที่ใกล้ที่สุด: 15W = วันทำงานที่ใกล้วันที่ 15 ที่สุด; LW = วันทำงานสุดท้ายของเดือน |
| # | วันในสัปดาห์ลำดับที่ N ของเดือน: 6#3 = วันศุกร์ที่สามใน Quartz/AWS (1 = วันอาทิตย์); 5#3 ใน Spring (0 = วันอาทิตย์) |
| @daily … | มาโคร: @yearly, @monthly, @weekly, @daily, @hourly; @reboot ทำงานครั้งเดียวเมื่อเริ่มระบบ |
วิธีใช้
- พิมพ์หรือวางตารางเวลาลงใน “นิพจน์ Cron” หรือคลิกรายการใดรายการหนึ่งใน “ตัวอย่าง” ซึ่งจะตั้ง “รูปแบบ” เป็น “ตรวจจับอัตโนมัติ” ด้วย สรุปและเวลาทำงานจะอัปเดตขณะที่คุณพิมพ์
- ปล่อย “รูปแบบ” ไว้ที่ “ตรวจจับอัตโนมัติ” หรือเลือกระบบที่นิพจน์นั้นเขียนขึ้นมาใช้ การตรวจจับอัตโนมัติจะอ่าน 5 ฟิลด์เป็น Unix และ 7 ฟิลด์เป็น Quartz สำหรับ 6 ฟิลด์ จะเลือก AWS หรือ Quartz จากตำแหน่งของ “?” เลือก AWS เมื่อฟิลด์สุดท้ายมีปีตั้งแต่ 1970 ถึง 2199 และหากไม่ใช่กรณีเหล่านี้จะถือว่าเป็น Spring มาโครอย่าง @weekly จะอ่านเป็น Unix เมื่อนิพจน์ถูกต้อง บรรทัดสถานะจะระบุรูปแบบที่ใช้
- อ่าน “ตารางเวลา” และ “รายละเอียดแต่ละฟิลด์” เพื่อดูว่าแต่ละฟิลด์ตรงกับค่าใด แล้วตรวจสอบวันที่ใน “เวลาทำงานครั้งถัดไป” “เขตเวลา” จะเริ่มต้นที่เขตเวลาของเบราว์เซอร์ หากจำเป็นให้เลือกเขตเวลาอื่น และเลือก 5, 10 หรือ 20 ใน “จำนวนครั้งที่แสดง” สำหรับเขตเวลาอื่นที่ไม่ใช่ UTC แต่ละรอบจะแสดงเวลา UTC ด้วย
- หากต้องการสร้างนิพจน์เอง ให้เปิด “ตัวสร้างแบบภาพ” เลือกรูปแบบ แล้วเลือกวิธีวนซ้ำของแต่ละฟิลด์ พร้อมป้อนค่าในฟิลด์ที่ต้องระบุ ปุ่ม “ใช้นิพจน์นี้” จะคัดลอก “นิพจน์ที่สร้างขึ้น” ไปไว้ใน “นิพจน์ Cron” ตั้ง “รูปแบบ” ให้ตรงกับรูปแบบของตัวสร้าง แล้วแยกวิเคราะห์นิพจน์ เพื่อให้คุณตรวจสอบเวลาทำงานได้
คำถามที่พบบ่อย
นิพจน์ที่ฉันป้อนถูกส่งไปที่ใดหรือไม่
ไม่ นิพจน์จะถูกแยกวิเคราะห์และเวลาทำงานจะถูกคำนวณในเบราว์เซอร์ของคุณด้วย JavaScript โดยไม่ถูกอัปโหลดไปยัง LeedyBox
ทำไม 0 0 13 * 5 จึงทำงานทุกวันศุกร์ ไม่ใช่เฉพาะวันศุกร์ที่ 13
ใน Unix cron เมื่อทั้งฟิลด์วันที่และวันในสัปดาห์ถูกจำกัดค่า (ไม่มีฟิลด์ใดขึ้นต้นด้วย *) วันหนึ่งจะตรงเงื่อนไขหากฟิลด์ใดฟิลด์หนึ่งตรง นิพจน์นี้จึงทำงานทุกวันที่ 13 ของเดือนและทุกวันศุกร์ เครื่องมือนี้ใช้กฎนี้กับนิพจน์ Unix และ “ตารางเวลา” จะแสดงว่า “ตรงอย่างใดอย่างหนึ่งก็พอ” สำหรับนิพจน์ Spring เครื่องมือกำหนดให้ทั้งสองฟิลด์ต้องตรง ส่วน Quartz และ AWS เลี่ยงปัญหานี้โดยกำหนดให้ใส่ “?” ในฟิลด์ใดฟิลด์หนึ่งจากสองฟิลด์นี้ ใน Unix cron วิธีแก้ที่นิยมคือตั้งให้ทำงานทุกวันศุกร์ แล้วตรวจสอบวันที่ภายในงานนั้น
วันอาทิตย์คือ 0, 1 หรือ 7
ขึ้นอยู่กับรูปแบบ ในนิพจน์ Unix และ Spring ทั้ง 0 และ 7 หมายถึงวันอาทิตย์ และ 1 คือวันจันทร์ ส่วนใน Quartz และ AWS 1 คือวันอาทิตย์และ 7 คือวันเสาร์ 1-5 ในรูปแบบเหล่านี้จึงหมายถึงวันอาทิตย์ถึงวันพฤหัสบดี การใช้ชื่อวันอย่าง MON-FRI ช่วยเลี่ยงความต่างนี้ได้ใน Spring, Quartz และ AWS
ทำไมบรรทัด crontab หรือนิพจน์ cron( ) ของ AWS จึงถูกปฏิเสธ
ให้ป้อนเฉพาะฟิลด์ตารางเวลา คำสั่งที่ท้ายบรรทัด crontab และชื่อผู้ใช้ใน /etc/crontab จะถูกนับเป็นฟิลด์ส่วนเกิน เครื่องมือจึงแจ้งว่าฟิลด์ไม่ถูกต้องหรือจำนวนฟิลด์ไม่ถูกต้อง สำหรับ AWS ให้วางเฉพาะหกฟิลด์ที่อยู่ภายใน cron( ) โดยไม่ต้องมีส่วนที่ครอบอยู่
จะเขียนนิพจน์ Unix ใหม่สำหรับ Spring, Quartz หรือ AWS ได้อย่างไร
Spring เพิ่มฟิลด์วินาทีไว้ด้านหน้า 0 9 * * 1-5 จึงกลายเป็น 0 0 9 * * 1-5 ส่วน Quartz ยังต้องมี “?” ในฟิลด์วันฟิลด์ใดฟิลด์หนึ่ง และนับวันอาทิตย์เป็น 1 ตารางเวลาเดียวกันจึงเป็น 0 0 9 ? * MON-FRI สำหรับ AWS ไม่มีฟิลด์วินาที ต้องมี “?” ในฟิลด์วันฟิลด์ใดฟิลด์หนึ่งเหมือน Quartz และเพิ่มปีไว้ท้าย: 0 9 ? * MON-FRI * หากนิพจน์ Unix จำกัดค่าทั้งสองฟิลด์วัน นิพจน์นั้นอาศัยกฎ “อย่างใดอย่างหนึ่ง” ที่อธิบายไว้ข้างต้น ซึ่งรูปแบบเหล่านี้ไม่ได้ใช้ โดยทั่วไปจึงต้องแยกเป็นสองตารางเวลา ให้ตรวจผลลัพธ์โดยเลือกรูปแบบปลายทาง แล้วเปรียบเทียบเวลาทำงานครั้งถัดไป
ทำไมเครื่องมือจึงแจ้งว่าไม่พบเวลาทำงาน
นิพจน์ถูกต้อง แต่ไม่พบเวลาที่ตรงเงื่อนไขในช่วงประมาณ 8 ปีข้างหน้าที่เครื่องมือค้นหา สาเหตุที่พบบ่อยคือวันที่ที่ไม่มีอยู่จริง เช่น 0 0 30 2 * (30 กุมภาพันธ์) หรือวันที่ 31 ที่ใช้คู่กับเดือนที่มี 30 วันเท่านั้น และฟิลด์ปีที่ผ่านไปแล้ว ปีที่อยู่ไกลกว่า 8 ปีข้างหน้าก็จะได้ข้อความเดียวกัน แม้ตารางเวลานั้นอาจยังทำงานได้ในภายหลัง ตัวจัดตารางงานบางตัว รวมถึง Unix cron แบบดั้งเดิม ยอมรับวันที่ที่ไม่มีอยู่จริงโดยไม่แจ้งเตือน และงานนั้นก็จะไม่ทำงาน
ใช้เขตเวลาใด และเวลาออมแสงมีผลอย่างไร
เวลาทำงานคำนวณตามเขตเวลาที่เลือกใน “เขตเวลา” ให้เลือกเขตเวลาที่ตัวจัดตารางงานของคุณใช้ โดยทั่วไป crontab จะใช้เขตเวลาของเซิร์ฟเวอร์ กฎแบบตั้งเวลา (scheduled rule) ใน AWS EventBridge ใช้ UTC และ EventBridge Scheduler ให้คุณกำหนดเขตเวลาได้ เมนูมีเขตเวลาของเบราว์เซอร์ UTC และเขตเวลาที่ใช้บ่อยจำนวนหนึ่ง หากไม่มีเขตเวลาของตัวจัดตารางงานของคุณ ให้เลือกเขตเวลาที่มีค่าชดเชยจาก UTC และวันเปลี่ยนเวลาออมแสงตรงกัน รอบที่ตรงกับเวลาที่ถูกข้ามเมื่อนาฬิกาเลื่อนไปข้างหน้าจะไม่อยู่ในรายการ และเวลาที่เกิดซ้ำสองครั้งเมื่อนาฬิกาเลื่อนย้อนกลับจะแสดงเพียงครั้งเดียว cron daemon แต่ละตัวจัดการช่วงเวลาเหล่านี้ต่างกัน เช่น cronie อาจรันงานของชั่วโมงที่ถูกข้ามทันทีหลังการเปลี่ยนเวลา ให้ตรวจสอบพฤติกรรมของตัวจัดตารางงานของคุณ หรือใช้ UTC ซึ่งไม่มีเวลาออมแสง เขตเวลา Asia/Bangkok ก็ไม่มีเวลาออมแสงเช่นกัน แต่เรื่องนี้ยังสำคัญเมื่อเซิร์ฟเวอร์ตั้งค่าเขตเวลาที่มีการเปลี่ยนเวลา เช่น Europe/London หรือ America/New_York