ฉันควรแก้ไข / etc / crontab หรือรัน crontab -e เป็น root หรือไม่

43

ฉันกำลังตั้งค่างานการบำรุงรักษาระบบเป็นประจำซึ่งต้องทำงานเหมือนรูท ฉันวางแผนที่จะใช้รสชาติของ cron ซึ่งมาพร้อมกับ Ubuntu 14.04 LTS เป็นค่าเริ่มต้น

ฉันเห็นผู้ดูแลระบบคนก่อนหน้า (ผู้ที่ลาออกจาก บริษัท ) แก้ไข / etc / crontab โดยตรง อย่างไรก็ตามฉันเข้าใจวิธีการอื่นที่เป็นไปได้คือใช้crontab -eเป็นรูท มีข้อโต้แย้งที่น่าสนใจที่จะใช้อย่างใดอย่างหนึ่งหรืออื่น ๆ หรือมันจะลงไปที่การตั้งค่า?

linux cron ubuntu-14.04

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

9

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

— MadHatter

1

ฉันเคยไปพิมพ์ crontab -l (เพื่อแสดงรายการ crontab) แต่ฉันพิมพ์ crontab -; โดยไม่ได้ตั้งใจซึ่งลบ crontab ของฉันแทน ฉันเรียนรู้มากในวันนั้น

— ตัดไม้

64

อาจเป็นประโยชน์ที่จะทราบว่างานใน crontab ส่วนบุคคล ( crontab -e) จะถูกดำเนินการเสมอในฐานะเจ้าของของพวกเขาซึ่ง/etc/crontabมี<user>ฟิลด์บังคับเพิ่มเติมที่อนุญาตให้ผู้ดูแลระบบกำหนดค่างานให้รันในฐานะผู้ใช้ที่ไม่ใช่รูท

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

ส่วนตัวฉันชอบตัวเลือกที่สาม : สำหรับการวางงานแต่ละครั้ง

ไฟล์/etc/cron.d/ด้วยโค้ด cron
executable (สคริปต์) ใน/etc/cron.[hourly |daily |weekly |monthly]ไดเรกทอรีที่เกี่ยวข้อง

สคริปต์นั้นง่ายกว่า (คุณสามารถสร้าง / เขียนทับ / ลบไฟล์ดังกล่าวได้โดยที่คุณไม่ต้องยุ่งเกี่ยวกับเนื้อหาของไฟล์ crontab เดียว) และทำงานได้ดีกับเครื่องมือการจัดการการกำหนดค่า ทำอยู่แล้ว

งาน / สคริปต์ในการ/etc/cron.[hourly |daily |weekly |monthly]ที่จะดำเนินการมักจะเป็นรากที่ตัวอย่าง cron ใน/etc/cron.d/ช่วยให้ทั้งสองการตั้งตารางเวลาที่กำหนดเองเช่นเดียวกับการทำงานเป็นผู้ใช้ที่แตกต่างกันกับข้อบังคับที่เดียวกันข้อมูลที่พบใน<user>/etc/crontab

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

18

ข้อเสียเปรียบของการแก้ไข/etc/crontabคือการผสานจะต้องเมื่อใดก็ตามที่คุณปรับปรุงcronแพคเกจ คุณไม่มีปัญหานั้นหากคุณเพิ่งเพิ่มไฟล์ใหม่ไปยังหนึ่งใน/etc/cron.*ไดเรกทอรี

— kasperd

1

คุณควรเพิ่มใน distros ส่วนใหญ่/etc/cron.[hourly |daily |weekly |monthly]ถือexecutablesในขณะที่/etc/cron.dถือ crontabs นอกเหนือจากนั้น +1

— GnP

ฉันเป็นแฟนตัวยงของ cron แน่นอน [เวลา] ไดเรกทอรีฉันไม่ค่อยต้องการอะไรที่ละเอียดมากกว่าตัวเลือก commn แม้ว่าโปรดทราบว่า distros บางตัวโดยเฉพาะ Ubuntu จะไม่สนใจสคริปต์ที่มีนามสกุลไฟล์ในโฟลเดอร์เหล่านี้ (เป็นข้อผิดพลาดทางอินเทอร์เน็ตที่ร้ายแรงเนื่องจากผู้คนส่วนใหญ่จะเพิ่ม. sh ซึ่งอาจได้รับการแก้ไขใน distros ล่าสุด) ยากมากที่จะคิดออกว่าทำไมสคริปต์ไม่ทำงานในสถานการณ์นั้น - อย่างน้อยการเพิ่มลงใน crontab นั้นรับประกันว่าจะสามารถทำงานได้

— Gargravarr

15

ที่ดีที่สุดฉันจำcrontab -eได้ว่ามีข้อได้เปรียบเพิ่มที่จะตรวจสอบไวยากรณ์ crontab ก่อนที่จะติดตั้งและจะผิดพลาดและเรียกคืนก่อนหน้าถ้าคุณทำผิด ด้วยวิธีนี้สิ่งใดก็ตามที่ทำงานก่อนหน้านี้จะไม่หยุดทำงานทันทีหากคุณทำผิดไวยากรณ์ ฉันคิดว่าวิธีปฏิบัติที่ดีที่สุดคือการใช้ยูทิลิตี้เช่นทำงานvisudoแทนการแก้ไข/etc/sudoersโดยตรง

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

2

+1 จุดที่ดีเกี่ยวกับการตรวจสอบความถูกต้องของไวยากรณ์แม้ว่าจะรับรู้ถึงข้อผิดพลาดทางไวยากรณ์บางอย่างมันก็ยังห่างไกลจากการพิสูจน์คนโง่ (เช่นจะช่วยให้คุณป้อน/etc/crontabบรรทัดด้วยชื่อผู้ใช้ในคอลัมน์ที่ 6) - แม้ว่าฉันต้องการจะยืนยันว่าการใช้เครื่องมือแบบอินเทอร์แอคทีฟไม่ใช่"แนวปฏิบัติที่ดีที่สุด"คุณควรทำการใช้เครื่องมืออัตโนมัติเช่น Puppet / Salt / Ansible เป็นต้นและไม่ควรกำหนดค่าเซิร์ฟเวอร์ด้วยมืออีกต่อไปในตอนแรก ในทางตรงกันข้ามถ้าคุณเป็นโรงเรียนเก่าแล้วใช้เครื่องมือของคุณอย่างแน่นอน

— HBruijn

Ansible และอื่น ๆ เป็นสิ่งที่ดีถ้าคุณกำหนดค่าเซิร์ฟเวอร์ 5+ ตัว แต่ไม่คุ้มกับความยุ่งยากเพียงแค่ 1 เท่านั้นคุณสามารถโต้แย้งว่าด้วยเซิร์ฟเวอร์เพียง 1 ตัวสคริปต์ Ansible จะช่วยให้คุณสามารถสร้างมันขึ้นมาใหม่ได้เมื่อล้มเหลว 2 ปี ณ จุดนั้นสคริปต์น่าจะไม่ทำงานอีกต่อไปเนื่องจากการเปลี่ยนแปลง distros / repos

— marcv81

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

— Monty Harder

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

— mckenzm

@mckenzm ตกลงกัน แต่มีเพียงมากงี่เง่าพิสูจน์อักษรคุณสามารถใช้ :)

— Gargravarr

2

มันเป็นคำถามสไตล์จริงๆมีเหตุผลหลายวิธีที่มีให้โดยระบบปฏิบัติการ เพียงแค่สอดคล้องกันและไม่มิกซ์แอนด์แมตช์หากคุณไม่ต้องการสับสนระหว่างคนอื่น (หรือตัวคุณเองหลังจากที่ไม่ได้ติดต่อกับระบบ) - ถ้าเป็นการยากที่จะดูว่างานใดที่มีการกำหนดจริงในโฮสต์ทั้งหมด เพื่อจบด้วยความประหลาดใจที่น่ารังเกียจ

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

2

เพื่อให้แน่ใจว่าจะเพิ่มงาน cron ที่ต้องการสิทธิ์ของผู้ใช้เฉพาะฉันใช้คำสั่งต่อไปนี้:

 # crontab -u <user> -e

คุณสามารถเพิ่มได้sudoเช่นกัน

ตามที่ @rackandboneman ระบุไว้ไม่จำเป็นต้องยุ่งกับไฟล์ /etc/cron.d/ หากเรื่องนี้เกี่ยวกับงาน cron ของผู้ใช้ให้ใช้คุณสมบัติของcrontabคำสั่ง

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

3

-1 ข้อเสียเปรียบครั้งใหญ่ของการทำข้างต้นคือผู้ใช้สามารถแก้ไข / ลบ / ทำลาย cronjob ได้เช่นกันซึ่งโดยทั่วไปแล้วจะไม่เป็นที่ต้องการเมื่อคุณในฐานะผู้ดูแลระบบใช้เวลาอันมีค่าของคุณในการตั้งค่า ... ผู้ใช้เป็นบัญชีบริการและบัญชีนั้นถูกล็อค / หมดอายุบริการจะยังคงทำงานต่อไป แต่แท็บ cron ส่วนบุคคลสำหรับบัญชีที่ถูกล็อคมักจะปิดการใช้งาน

— HBruijn

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

— aesnak