Cron vs systemd ตัวจับเวลา

เมื่อเร็ว ๆ นี้ชี้ให้ฉันเห็นว่ามีทางเลือกอื่นสำหรับ cron คือ systemd timers

อย่างไรก็ตามฉันไม่รู้อะไรเลยเกี่ยวกับตัวจับเวลา systemd หรือ systemd ฉันใช้ cron แล้วเท่านั้น

มีเล็ก ๆ น้อย ๆ คือการอภิปรายใน Arch วิกิพีเดีย อย่างไรก็ตามฉันกำลังมองหาการเปรียบเทียบรายละเอียดระหว่างcronและตัวจับเวลา systemd โดยเน้นไปที่ข้อดีและข้อเสีย ฉันใช้ Debian แต่ฉันต้องการเปรียบเทียบโดยทั่วไปสำหรับทุกระบบที่มีตัวเลือกสองตัวเลือกนี้ ชุดนี้อาจรวมถึงการกระจาย Linux เท่านั้น

นี่คือสิ่งที่ฉันรู้

Cron มีอายุมากย้อนกลับไปในช่วงปลายทศวรรษ 1970 ผู้แต่งดั้งเดิมของ cron คือ Ken Thompson ผู้สร้าง Unix Vixie cron ซึ่ง crons ในการแจกแจงลินุกซ์รุ่นใหม่เป็นรุ่นที่สืบทอดโดยตรงตั้งแต่ปี 1987

Systemd ใหม่กว่ามากและค่อนข้างขัดแย้ง Wikipedia บอกฉันว่ารุ่นแรกคือ 30 มีนาคม 2010

ดังนั้นรายการปัจจุบันของข้อได้เปรียบของ cron มากกว่าตัวจับเวลา systemd คือ:

Cron รับประกันว่าจะอยู่ในระบบที่เหมือน Unix ใด ๆ ในแง่ของการเป็นชิ้นส่วนซอฟต์แวร์ที่ติดตั้งได้ นั่นจะไม่เปลี่ยนแปลง ในทางตรงกันข้าม systemd อาจหรือไม่อาจอยู่ในลีนุกซ์ลีนุกซ์ในอนาคต. เป็นระบบเริ่มต้นส่วนใหญ่และอาจถูกแทนที่ด้วยระบบเริ่มต้นที่แตกต่างกัน
Cron ใช้งานง่าย ง่ายกว่าตัวจับเวลา systemd แน่นอน

รายการข้อดีที่สอดคล้องกันของตัวจับเวลา systemd บน cron คือ:

ตัวจับเวลา Systemd อาจมีความยืดหยุ่นและความสามารถมากกว่า แต่ฉันต้องการตัวอย่างของสิ่งนั้น

ดังนั้นเพื่อสรุปนี่เป็นสิ่งที่ดีที่จะเห็นในคำตอบ:

การเปรียบเทียบรายละเอียดของตัวจับเวลา cron vs systemd รวมถึงข้อดีข้อเสียของการใช้แต่ละตัว
ตัวอย่างของสิ่งหนึ่งที่สามารถทำได้ที่อื่นไม่สามารถ
การเปรียบเทียบสคริปต์ cron เทียบกับสคริปต์ตัวจับเวลา systemd อย่างน้อยหนึ่งรายการ

cron systemd-timer

— Faheem Mitha
แหล่งที่มา

"Cron รับประกันว่าจะอยู่ในระบบที่เหมือนยูนิกซ์ใด ๆ นั่นจะไม่เปลี่ยนแปลง" - ฉันจะขอโต้แย้งอย่างนี้ ในขณะที่ cron ในอดีตมักถูกรวมอยู่ในการติดตั้งพื้นฐานของการติดตั้ง Unix ในระบบส่วนใหญ่ในปัจจุบันก็เป็นเพียงซอฟต์แวร์เสริมที่ไม่จำเป็นสำหรับผู้อื่น ในความเป็นจริงมีหลายทางเลือก cron ยอดนิยมรอบ (เช่น anacron, fcron, jobber) ซึ่งอาจจะดีกว่า cron ฟังก์ชั่นของ cron ไม่จำเป็นสำหรับการทำงานของระบบตามที่ systemd หรือ init เป็นดังนั้นหากคุณกังวลเกี่ยวกับการพกพาในปัจจุบันและอนาคตฉันจะไม่วางเดิมพันของฉัน

— กุยโด้

นั่นเป็นรายการสิ่งที่คุณต้องการในคำตอบ ฉันคิดว่าบางทีคุณควรใช้เวลาในการเรียนรู้เครื่องมือด้วยตัวเองและดูว่าคุณสามารถกำหนดคำตอบเหล่านั้นด้วยตนเองได้หรือไม่และถ้าคุณมีบางสิ่งที่คุณไม่เข้าใจให้ถามพวกเขาที่นี่

— larsks

ไม่ได้จริงๆ ฉันได้กล่าวทั้งหมดที่ฉันต้องการพูดในหัวข้อ การพูดคุยกันอย่างกว้างขวางเกี่ยวกับสิ่งใดก็ตามที่เกี่ยวข้องกับ systemd นั้นแย่กว่าไม่มีจุดหมาย - บางคนคิดว่าประโยชน์เล็กน้อยที่ systemd นำมานั้นคุ้มค่ากับการรวมระบบองค์กรลินุกซ์ คนอื่นทำไม่ได้

— cas

"Cron แก่มากแล้วย้อนกลับไปในช่วงปลายทศวรรษ 1970" ถูกต้องตามความเป็นจริง แต่ไม่เกี่ยวข้องอย่างสมบูรณ์ตราบใดที่แพ็คเกจในระบบของคุณได้รับการบำรุงรักษาอย่างเหมาะสมและมีเสถียรภาพ ดวงอาทิตย์ยังเก่ามาก แต่ฉันหวังว่านั่นไม่ได้หมายความว่าเราควรแทนที่มันด้วยสิ่งที่ดีกว่าและใหม่กว่า

— Otheus

@Ousus ฉันคิดว่าคุณกำลังทำผิดส่วน - การพูดอะไรบางอย่างที่มีมาเป็นเวลานานไม่ใช่การดูถูก อย่างน้อยก็เป็นจำนวนมากที่คนยูนิกซ์ มันเหมือนการบอกว่าบ้านมีอายุหลายร้อยปี - แน่นอนว่ามันจะมีปัญหาบางอย่างบางสิ่งจะแปลกจากการเดิน แต่มันก็มีเสน่ห์บางอย่างและมันต้องถูกสร้างขึ้นอย่างดี มันไม่ได้บอกว่ามันอ่อนล้า มันเป็นเครื่องมือง่ายๆที่พิสูจน์แล้วว่ามีประโยชน์สำหรับสี่ทศวรรษ

— Derobert

คำตอบ:

นี่คือบางจุดเกี่ยวกับสองสิ่งนี้ :

การตรวจสอบว่างาน cron ของคุณทำอะไรได้บ้าง แต่เหตุการณ์ systemd timer ทั้งหมดจะถูกบันทึกอย่างระมัดระวังใน systemd journal เช่นเดียวกับ systemd units อื่น ๆ ตามเหตุการณ์ที่ทำให้สิ่งต่าง ๆ ง่ายขึ้นมาก
systemd timers เป็น systemd services ที่มีความสามารถทั้งหมดสำหรับการจัดการทรัพยากร, การกำหนดเวลา IO CPU, ...
มีรายการอยู่:
- ตัวกรอง systemcall
- รหัสผู้ใช้ / กลุ่ม
- membershipcontrols
- คุ้มค่าสม
- คะแนน OOM
- คลาสการกำหนดตาราง IO และลำดับความสำคัญ
- นโยบายการกำหนดเวลา CPU CPU
- สัจจะ
- กางเกงทรงหลวมจับเวลา
- บิตที่ปลอดภัย
- การเข้าถึงเครือข่ายและ, ...
ด้วยตัวเลือกการพึ่งพาเช่นเดียวกับบริการ systemd อื่น ๆ สามารถมีการอ้างอิงในเวลาเปิดใช้งาน
หน่วยสามารถเปิดใช้งานในรูปแบบที่แตกต่างกันรวมทั้งสามารถกำหนดค่าได้ บริการสามารถเริ่มต้นและเรียกใช้โดยเหตุการณ์ที่แตกต่างกันเช่นผู้ใช้บูตการเปลี่ยนแปลงสถานะของฮาร์ดแวร์หรือตัวอย่างเช่น 5 นาทีหลังจากเสียบปลั๊กฮาร์ดแวร์และ ...
การกำหนดค่าง่ายขึ้นมากบางไฟล์และแท็กตรงไปข้างหน้าเพื่อทำการปรับแต่งที่หลากหลายตามความต้องการของคุณด้วยตัวจับเวลา systemd
เปิด / ปิดการใช้งานทั้งหมดได้อย่างง่ายดายด้วย:
```
systemctl enable/disable 
```
และฆ่าลูก ๆ ของงานทั้งหมดด้วย:
```
systemctl start/stop
```
ตัวจับเวลา systemd สามารถกำหนดเวลาด้วยปฏิทินและเวลาแบบโมโนโทนิกซึ่งมีประโยชน์จริง ๆ ในกรณีของเขตเวลาที่แตกต่างกันและ ...
เหตุการณ์เวลา systemd (ปฏิทิน) มีความแม่นยำมากกว่า cron (ดูเหมือนแม่นยำ 1s)
เหตุการณ์เวลา systemd มีความหมายมากกว่าสำหรับเหตุการณ์ที่เกิดซ้ำหรือเหตุการณ์ที่เกิดขึ้นหนึ่งครั้งนี่คือตัวอย่างจาก เอกสาร :
```
Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00
  Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                Wed *-1 → Wed *-*-01 00:00:00
        Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
             Wed, 17:48 → Wed *-*-* 17:48:00 
```
จากมุมมองการใช้งาน CPU systemd timer จะทำให้ CPU ทำงานในเวลาที่ผ่านไป แต่ cron ทำบ่อยกว่านั้น
เหตุการณ์ตัวจับเวลาสามารถกำหนดเวลาตามเวลาสิ้นสุดของการประมวลผลความล่าช้าบางอย่างสามารถตั้งค่าได้ระหว่างการประมวลผล
การสื่อสารกับโปรแกรมอื่น ๆ ก็มีความโดดเด่นในบางครั้งก็เป็นสิ่งจำเป็นสำหรับบางโปรแกรมอื่น ๆ ที่จะรู้ว่าตัวจับเวลาและสถานะของงานของพวกเขา

— F.sb
แหล่งที่มา

นั่นเป็นความพยายามที่ดีขอบคุณ อย่างไรก็ตามการเปรียบเทียบโดยตรงกับ cron จะเป็นประโยชน์มากขึ้นรวมถึงตัวอย่าง นอกจากนี้สิ่งที่คุณเขียนบางอย่างไม่ชัดเจนเช่น "จากตัวจับเวลาการใช้งาน CPU system view point ทำให้ CPU ในเวลาที่ผ่านไป แต่ cron ทำเช่นนั้นบ่อยขึ้น"

— Faheem Mitha

สวัสดี @ F.sb! คำตอบของคุณดูเหมือนจะบอกเป็นนัยว่าคุณสามารถกำหนดเวลางานโดยใช้เขตเวลาที่แตกต่างกัน ถูกต้องหรือไม่ คุณจะทำอย่างไร มันจะเป็นข้อได้เปรียบที่สำคัญกว่าการใช้ cron แบบมาตรฐาน แต่ฉันไม่สามารถหาข้อมูลใด ๆ ได้ยกเว้นman systemd.timeว่าดูเหมือนจะขัดแย้งกัน: เขตเวลานอกท้องถิ่นยกเว้น UTC ไม่ได้รับการสนับสนุน

— ตาด Lispy

การอ้างอิงมีประโยชน์ ตัวอย่างเช่นหากการสำรองข้อมูลโฮสต์ทำงานเป็นตัวจับเวลา systemd คุณสามารถใช้การพึ่งพาเพื่อให้แน่ใจว่าการส่งออกฐานข้อมูลเสร็จสมบูรณ์ทันทีก่อนการสำรองข้อมูล

— vk5tu

โปรดซื่อสัตย์มากขึ้นล่วงหน้า คุณเริ่มต้นด้วยการพูดว่าเหล่านี้เป็นบางจุดเกี่ยวกับสองแล้วดำเนินการต่อไปโดยรายชื่อข้อดีของทางเลือกที่ดีของคุณ มันไม่ได้เลวร้ายที่คุณมีความพึงพอใจ แต่คุณควรระบุไว้ล่วงหน้า ด้านบนของที่ความจริงที่ว่ามันเป็นทั้งหมดในความโปรดปรานของระบบใดระบบหนึ่งและไม่ได้ดูที่ข้อดีที่ว่าระบบได้ทำให้ฉันรู้สึกคำตอบนี้เป็นเบ้

— Jasper

@jasper ที่รักฉันใช้ทั้งสองอย่างตามความต้องการของฉันและมันก็เป็นทางเลือกของคุณที่จะเลือกตามความต้องการของคุณฉันแค่พูดถึงข้อเท็จจริงบางอย่างจากเอกสารและคู่มือ

— F.sb

พูดตรงๆจากปากม้าเพื่อพูด: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

ข้อความที่ตัดตอนมาจากหน้าเว็บด้านบน:

ประโยชน์ที่ได้รับ

ประโยชน์หลักของการใช้ตัวจับเวลามาจากแต่ละงานที่มีบริการ systemd ของตัวเอง บางส่วนของผลประโยชน์เหล่านี้คือ:

สามารถเริ่มงานได้อย่างอิสระโดยอิสระจากตัวจับเวลา วิธีนี้ช่วยให้การดีบักง่ายขึ้น

แต่ละงานสามารถกำหนดค่าให้ทำงานในสภาพแวดล้อมเฉพาะ (ดูที่ systemd.exec (5))

สามารถแนบงานกับกลุ่ม cg ได้

สามารถตั้งค่างานให้ขึ้นอยู่กับหน่วย systemd อื่น ๆ

งานถูกบันทึกไว้ใน systemd journal เพื่อให้ง่ายในการดีบัก

คำเตือน

บางสิ่งที่ง่ายต่อการทำ cron นั้นทำได้ยากด้วยตัวตั้งเวลาเพียงอย่างเดียว

ความซับซ้อน: การตั้งค่างานที่หมดเวลาด้วย systemd คุณสร้างสองไฟล์และเรียกใช้คำสั่ง systemctl คู่ เปรียบเทียบกับการเพิ่มบรรทัดเดียวกับ crontab

อีเมล: ไม่มี MAILTO ในตัวของ cron สำหรับการส่งอีเมลเมื่องานล้มเหลว ดูส่วนถัดไปสำหรับตัวอย่างของการตั้งค่าที่เทียบเท่าโดยใช้ OnFailure =

— shdwlynx
แหล่งที่มา

ผิดพลาด ... ไม่แน่ใจว่าฉันรู้สึกอย่างไรกับคำตอบที่เกือบจะคัดลอก & วางโดยเฉพาะอย่างยิ่งเนื่องจากสิทธิ์ใช้งานไม่เข้ากัน แต่อย่างน้อยคุณควรแก้ไขบิต "ดูหัวข้อถัดไป" ด้วยความผิดพลาดนั้นให้ความรู้สึกราวกับว่าคุณไม่ได้อ่านสิ่งที่คุณคัดลอกและวาง

— Derobert

เมื่อคุณพูดวัสดุจากที่ไหนสักแห่งคุณต้องอ้างอิงแหล่งที่มาอย่างชัดเจนและคุณจะต้องระบุว่าจะยกมา การขโมยความคิดไม่เย็น

— Gilles