Cron გამოსახულებები ახსნილი, გეიმ სერვერის განრიგებით

Cron გამოსახულება არის ხუთი ველი, გამოყოფილი ინტერვალით და წაკითხული მარცხნიდან მარჯვნივ: წუთი, საათი, თვის დღე, თვე, კვირის დღე. 0 5 * * * ნიშნავს "საათის 5-ის მე-0 წუთზე, ყოველ დღე" - დილის ხუთზე. */15 * * * * ნიშნავს "ყოველ მეთხუთმეტე წუთზე, ყოველ საათს, ყოველ დღე". ეს არის მისი ოთხმოცდაათი პროცენტი და შეგიძლია აქ შეწყვიტო კითხვა, თუ მხოლოდ ღამის restart გჭირდებოდა.

დანარჩენი ათი პროცენტი ისაა, სადაც ხალხი შაბათ-კვირას კარგავს: თვის დღისა და კვირის დღის ველები ისე არ იქცევიან, როგორც მოელი, როცა ორივეს იყენებ, */7 იმას არ აკეთებს, რასაც ჰგავს, დროის სარტყელი ის არ არის, რომელშიც შენ ზიხარ, და ამოცანა, რომელსაც backup-ის შემდეგ სამოც წამიანი დაყოვნება აქვს, backup-ის დასრულებას არ ელოდება. ეს პოსტი სინტაქსს სრულად ფარავს და შემდეგ იმ რამდენიმე განრიგს, რომლებიც გეიმ სერვერზე ნამდვილად ღირს გაშვებად.

ხუთი ველი#

ყველა ველი უნდა იყოს. სტანდარტულ ხუთველიან ფორმაში წამების ველი არ არსებობს და წლის ველიც არა, ამიტომ ყველაზე წვრილი გარჩევადობა ერთი წუთია. თუ შენს წინ scheduler ექვს ველს ითხოვს, ეს ან სისტემური crontab-ია /etc/crontab-ში ან /etc/cron.d-ში, სადაც მეექვსე სვეტი მომხმარებელია, ვისაც უნდა გაეშვას, ან Quartz-ის სტილის parser-ია, სადაც პირველი ველი წამებია. ეს განსხვავებული ფორმატებია, რომლებიც ერთი შეხედვით იდენტურად გამოიყურება, და ერთიდან მეორეში გამოსახულების ჩასმა გავრცელებული გზაა, რომ ამოცანა დაგეგმილზე სამოცჯერ უფრო ხშირად გაეშვას.

სახელები რეგისტრის მიმართ ინსენსიტიურია, ამიტომ MON, Mon და mon ერთი და იგივეა. სახელების დიაპაზონები უმეტეს იმპლემენტაციაში მუშაობს - MON-FRI სწორია - მაგრამ ბიჯები სახელებთან ერთად პორტატული არ არის, ამიტომ დარწმუნებისთვის MON-FRI/2-ის ნაცვლად დაწერე 1-5.

ოთხი ოპერატორი და მეტი არაფერია#

• *** - ყველა მნიშვნელობა.** * * * * * ყოველ წუთს ეშვება, სამუდამოდ. ტესტისთვის კარგი გზაა და საშინელი რამ, რომ ადგილზე დატოვო.
• `,` - სია. 0,30 * * * * არის საათზე და ნახევარ საათზე. სიებს დიაპაზონები შეიძლება ჰქონდეს: 0 2,6,14,22 * * *.
• `-` - დიაპაზონი, ჩათვლით. 0 9-17 * * * არის ყოველ საათს 09:00-დან 17:00-მდე, რაც ცხრა გაშვებაა და არა რვა.
• `/` - ბიჯი. */15 წუთის ველში არის 0, 15, 30, 45. ბიჯი ეხება იმას, რაც მის მარცხნივაა, ამიტომ 0-30/10 არის 0, 10, 20, 30, ხოლო 5/10 წუთის ველში ნიშნავს "დაიწყე 5-დან და წადი 10-ის ბიჯით დიაპაზონის ბოლომდე": 5, 15, 25, 35, 45, 55.

ზოგი parser ასევე იღებს მოკლე მეტსახელებს ხუთივე ველის ნაცვლად: @hourly, @daily (ასევე იწერება @midnight), @weekly, @monthly, @yearly და @reboot. ისინი მოსახერხებელია Linux crontab-ში და არასანდოა პანელის ველებში, რომელთა უმეტესობას ხუთი რეალური ველი უნდა. დაწერე გამოსახულება სრულად; ის ხუთი სიმბოლოთი უფრო გრძელია და ყველგან მუშაობს.

არ არსებობს ოპერატორი "თვის ბოლო დღისთვის", "პირველი ხუთშაბათისთვის" ან "ყოველი მეორე კვირისთვის". Quartz-ის სტილის parser-ები ამის ნაწილისთვის L, W და #-ს ამატებენ, სტანდარტული cron - არა, ხოლო პანელის ველი ჩვეულებრივ სტანდარტულია. შემოვლითი გზა ქვემოთაა.

გაანგარიშებული მაგალითები#

ბოლო ბეჭდვითი შეცდომა არ არის. შუაღამე და საათის დასაწყისი დროა, როცა ყველა დანარჩენის backup-ები, ლოგების როტაცია და განახლების შემოწმებები ეშვება, და საერთო აპარატურაზე ეს გაზომვადი პიკია. უცნაური წუთის არჩევა არაფერი ღირს და შენს ამოცანას უფრო წყნარ ადგილას ათავსებს.

უცნობი გამოსახულება წაიკითხე ველების თანმიმდევრობით გავლით და მათ შორის სიტყვა "-ის"-ის თქმით. 30 3 * * 0 არის "30-ე წუთზე, მე-3 საათის, თვის ნებისმიერი დღის, ნებისმიერი თვის, კვირას". ეს ჩვევა შეცდომების უმეტესობას გაშვებამდე იჭერს.

თვის დღისა და კვირის დღის ხაფანგი#

ეს cron-ის ყველაზე ხშირად არასწორად წაკითხული წესია და მან უფრო მეტი შემთხვევითი წაშლა გამოიწვია, ვიდრე ნებისმიერმა სხვამ.

თუ ორივე თვის დღისა და კვირის დღის ველი შეზღუდულია - არცერთი არ არის * - cron ამოცანას ეშვება, როცა რომელიმე ემთხვევა და არა როცა ორივე. 0 0 13 * 5 არ ნიშნავს "შუაღამე პარასკევ მეცამეტეს". ის ნიშნავს "შუაღამე ყოველ მეცამეტეს და ასევე შუაღამე ყოველ პარასკევს", რაც თვეში დაახლოებით ცხრაჯერაა და არა წელიწადში ერთხელ ან ორჯერ.

როცა ორიდან ერთი *-ია, ქცევა ჩვეულებრივია, რასაც ელოდები: 0 4 * * 1 მხოლოდ ორშაბათებია, 0 4 15 * * მხოლოდ მე-15.

ასე რომ: "თვის პირველი ხუთშაბათის" სათქმელად მარტო cron-ს ვერ გამოიყენებ. Linux მანქანაზე მას ყოველ ხუთშაბათს ანაწილებ და ბრძანებაში იცავ:

# 06:00 on the first Thursday of the month. Note the escaped % in a crontab.0 6 * * 4 [ "$(date +\%d)" -le 07 ] && /opt/scripts/wipe.sh >> /var/log/wipe.log 2>&1

პანელზე, რომელსაც მხოლოდ cron ველი და ბრძანებების სია აქვს, პატიოსანი პასუხია: ხელით გაუშვი, ან ყოველ ხუთშაბათს გაუშვი და შეეგუე, ან ყოველ თვე ერთჯერადად დაგეგმე. Rust-ის იძულებითი wipe ჩვეულებრივი მიზეზია, რატომაც ხალხი ამას კითხულობს, და wipe-ები მოთამაშეების დაკარგვის გარეშე ამტკიცებს, რომ განცხადება ავტომატიზაციაზე მაინც მნიშვნელოვანია.

დროის სარტყლები, საათის ცვლილებები და რას ნიშნავს "შუაღამე"#

Cron-ს საკუთარი დროის სარტყელი არ აქვს. ის იმის საათს იყენებს, რაც მას უშვებს, ანუ Linux მანქანაზე მანქანის ადგილობრივ დროს და ჰოსტინგის პანელში პანელის გამართულ დროის სარტყელს. არცერთი მათგანი აუცილებლად შენი არ არის. თბილისელი მოთამაშე, რომელიც გერმანიაში მდებარე აპარატურაზე restart-ს 0 5 * * *-ით გეგმავს, მას ზამთარში მისი დროით 08:00-ზე და ზაფხულში 07:00-ზე გეგმავს, რაც არავისთვისაა საღამოს შიგნით და მისთვის დილის შუაგულია.

აქედან ორი რამ გამომდინარეობს.

სანამ განრიგს ენდობი, გაიგე, რომელ საათზე ხარ. ყველაზე სწრაფი ტესტია უვნებელი ამოცანის დაყენება - თამაშშიდა განცხადება ან Linux მანქანაზე echo - ორი წუთით მომავალში და დაკვირვება, ეშვება თუ არა, როცა ელოდი. გააკეთე ეს ერთხელ თითო ჰოსტზე; ეს უფრო სწრაფია, ვიდრე ვინმეს დოკუმენტაციის კითხვა.

მოერიდე საათებს, როცა საათი იცვლება. ევროკავშირში, გერმანული აპარატურის ჩათვლით, რომელზეც ჩვენ ვმუშაობთ, საათები წინ ხტება ადგილობრივი დროით 02:00-ზე მარტის ბოლო კვირას და უკან 03:00-ზე ოქტომბრის ბოლო კვირას. წინა ხტომისას საათი 02:00-დან 02:59-მდე არ არსებობს, უკანა ხტომისას კი ორჯერ ხდება. სხვადასხვა cron იმპლემენტაცია ამას სხვადასხვანაირად წყვეტს - ზოგი გამოტოვებს, ზოგი დაგვიანებით ეშვება, ზოგი ორჯერ - და არცერთი არ ღირს კამათად. დაგეგმე მოვლა 04:00-ზე ან 05:00-ზე და კითხვა არასოდეს დგება. თუ ზუსტი ინტერვალები საათის ცვლილების გავლით ნამდვილად გჭირდება, მანქანა და განრიგი UTC-ზე გაუშვი.

განრიგები, რომლებიც გეიმ სერვერზე ღირს#

ოთხი განრიგი უმეტესობას აღკვეთს იმისას, რის გამოც ხალხი ticket-ს ხსნის. ქვემოთ დროები ვარაუდობს, რომ ხუთ საათზე დილით არავინ თამაშობს; ბლოკი გადაიტანე, თანმიმდევრობა შეინარჩუნე.

Save ბრძანება backup-მდე ნაბიჯია, რომელსაც ხალხი გამოტოვებს. Backup არის დისკზე ფაილების ასლი, ხოლო უმეტესი გეიმ სერვერი სამყაროს მეხსიერებაში ინახავს და ტაიმერზე წერს. Backup-ი წინასწარ შენახვის გარეშე გაძლევს ბოლო ავტომატური შენახვისას სამყაროს გარეგნობის არქივს, რომელიც ოცდახუთი წუთის წინანდელი შეიძლება იყოს. გაგზავნე save-all Minecraft-ში, save Valheim-ის კონსოლში, saveworld ან ექვივალენტი იმაში, რასაც უშვებ, შემდეგ დაელოდე წუთს, შემდეგ გააკეთე backup.

ამ ოთხის გარდა, დაამატე ის, რაც შენს თამაშს სჭირდება: ბაზის dump საკუთარ განრიგზე, თუ ერთს უშვებ (ბაზის backup-ები და აღდგენა), შუადღის შენახვა და განცხადება სამშენებლო სერვერზე, ლოგების როტაცია, თუ თამაში საკუთარ ლოგებს წერს (ლოგები, რომლებიც ღირს შენახვად). დაგეგმილი ამოცანები, რომლებიც ღირს ამ სიის მოკლე ვერსიაა, ხოლო restart-ის განრიგები, რომლებიც ეხმარება ფარავს, რამდენად ხშირი არის ზედმეტად ხშირი.

ამოცანების რიგი, დაყოვნებები და გადაფარვადი გაშვებები#

პანელის განრიგი ჩვეულებრივ ერთი cron გამოსახულებაა რამდენიმე ამოცანით მის ქვეშ, თითოეულს წინადან წამებში დაყოვნებით. ეს დაყოვნება ლოდინია და არა დასრულების შემოწმება. ეს უფრო მნიშვნელოვანია, ვიდრე ჩანს:

1. ამოცანა პირველი: გაგზავნე save-all. დაყოვნება 60 წამი.
2. ამოცანა მეორე: შექმენი backup. დაყოვნება 60 წამი.
3. ამოცანა მესამე: გადატვირთე სერვერი.

ეს სწორად გამოიყურება და არ არის. 30 GB სერვერის backup წუთებს გრძელდება და restart ეშვება backup-ის დაწყებიდან სამოც წამში და არა მისი დასრულებიდან. იღებ restart-ს არქივირების ოპერაციის შუაში და არქივს, რომელიც შეიძლება გამოსადეგი იყოს და შეიძლება - არა. გამოსავალია backup-ს დრო მისცე - რამდენიმე წუთი დაყოვნება, შენი სამყაროს ზომაზე მორგებული - ან, უკეთესია, restart ცალკე განრიგზე დააყენო 0 5 * * *-ზე, სანამ backup 50 4 * * *-ზე მუშაობს. ათი წუთით დაშორებული ორი განრიგი უფრო ადვილი გასააზრებელია, ვიდრე ერთი განრიგი გამოცნობილი დაყოვნებით.

Linux crontab-ზე ეკვივალენტური პრობლემაა ამოცანა, რომელსაც თავისი ინტერვალზე მეტი ჭირდება. */5 * * * * სკრიპტზე, რომელიც ზოგჯერ შვიდი წუთი გრძელდება, გაძლევს ორ ასლს, რომლებიც ერთსა და იმავე ფაილებს ეჯიბრებიან. შეფუთე:

*/5 * * * * flock -n /tmp/sync.lock /opt/scripts/sync.sh >> /var/log/sync.log 2>&1

flock -n lock-ს იღებს ან მაშინვე თავს ანებებს, ამიტომ მეორე ასლი გადის და არ ეშვება. ეს ერთი სიტყვაა და ინციდენტების მთელ კატეგორიას აშორებს.

RE:NODE-ის Schedules tab იღებს cron გამოსახულებას და დაყოვნებებით დალაგებულ ამოცანების სიას, ხოლო ამოცანა სამიდან ერთ-ერთია: კონსოლის ბრძანება, backup ან power action. Backup სლოტები ყველა გეგმაზეა, backup დაიბლოკოს, რომ როტაციამ არ წაშალოს, და ასლები ინახება იმ მანქანის გარეთ, რომელსაც იცავს. ეს მთელ ცხრილს ფარავს ზემოთ, სადმე სკრიპტის გარეშე. განრიგების გზამკვლევი შეიცავს დაწკაპუნებ-დაწკაპუნებით ვერსიას, ხოლო როგორ მუშაობს პანელი ქვემოთ განმარტავს, რატომ ცხოვრობს scheduler პანელში და არა შენს სერვერში.

Crontab Linux მანქანაზე: დამატებითი წესები#

თუ VDS-ზე ხარ და არა პანელზე, cron-ს აქვს რამდენიმე ქცევა, რომელსაც გამოსახულებასთან საერთო არაფერი აქვს და მაინც არღვევს ამოცანებს.

• რედაქტირება `crontab -e`-ით, სია `crontab -l`-ით. spool ფაილების ხელით რედაქტირება ისაა, როგორც ბოლოს crontab გიგდება, რომელიც ჩუმად არ იტვირთება.
• `PATH` თითქმის ცარიელია. Cron შენს shell პროფილს არ კითხულობს. node, docker და ყველაფერი /usr/local/bin-ში შეიძლება ვერ მოიძებნოს. გამოიყენე აბსოლუტური გზები ბრძანებაში, ან crontab-ის თავში დააყენე PATH=.
• `%` ნიშნავს ახალ ხაზს. crontab ბრძანებაში გაუექრანებელი % ხაზის გადატანად გარდაიქმნება და პირველის შემდეგ ყველაფერი ამოცანას სტანდარტულ შესასვლელზე მიეწოდება. date +%Y ხდება date + პლუს გაუთვალისწინებელი ხაზი. გაუექრანე ყველა როგორც \%.
• გამოტანა იგზავნება ფოსტით და არ იწერება ლოგში. თუ საფოსტო სისტემა არ არის, გამოტანა არსად მიდის. გადაამისამართე ის თავად >> /var/log/job.log 2>&1-ით და დააყენე MAILTO="" crontab-ის თავში, თუ სიჩუმე გინდა.
• სისტემური crontab-ები იღებენ მომხმარებლის ველს. /etc/cron.d-სა და /etc/crontab-ში ფაილებს ექვსი სვეტი აქვს, მომხმარებელი კვირის დღის ველსა და ბრძანებას შორის. ხუთსვეტიანი ხაზი ამ ფაილებში ვერ მუშაობს.

ყველაფრისთვის, რასაც რეალური დამოკიდებულებების ჯაჭვი აქვს, systemd timer-ები cron-ზე უკეთესია: ისინი journal-ში იწერებიან, შეუძლიათ სხვა unit-ებზე დამოკიდებულება და systemctl list-timers გეუბნება, როდის არის შემდეგი გაშვება - რაც cron არასოდეს გეტყვის. სამუშაოსთვის, რომელსაც საათი კი არა, აპლიკაცია იწვევს, რიგი გინდა: background jobs პატარა სერვერზე.

შეცდომები, რომლებიც ხალხს შაბათ-კვირას ჯდება#

***/7 * * * * არ არის ყოველ შვიდ წუთში.** ბიჯები ყოველი საათის დასაწყისში თავიდან იწყება, ამიტომ ის ეშვება 0, 7, 14, 21, 28, 35, 42, 49, 56-ე წუთზე და შემდეგ ისევ 0-ზე ოთხი წუთის შემდეგ. ნებისმიერ ბიჯს, რომელიც 60-ს არ ყოფს, ყოველ საათს მოკლე ხვრელი აქვს. გამოიყენე 5, 10, 15, 20 ან 30.

**0 0 * * * საერთო მანქანაზე.** შუაღამე ნებისმიერ node-ზე დღის ყველაზე დატვირთული წუთია. გადაიტანე.

Restart უფრო ხშირად, ვიდრე გჭირდება. ექვსსაათიანი restart სერვერზე, რომელიც კვირაობით კარგადაა, დღეში ოთხი შეწყვეტაა, ყიდვის გარეშე. გადატვირთე მტკიცებულებით და არა ცრურწმენით - რატომ რესტარტდება შენი გეიმ სერვერი განუწყვეტლივ ფარავს leak-ის ნორმალური ზრდისგან გარჩევას.

Backup განრიგი, საიდანაც არავის აღუდგენია. Backup, რომლიდანაც არასოდეს აღგიდგენია, ჰიპოთეზაა. აირჩიე წყნარი კვირა და გამოსცადე აღდგენა, სანამ დაგჭირდება.

განრიგის არსებობის დავიწყება. ექვსი თვის შემდეგ ამოცანა ისევ ცარიელებს დირექტორიას, სადაც ახლა სხვა რამაა. ჩაწერე განზრახვა განრიგის სახელში და წაიკითხე განრიგების სია სეზონში ერთხელ.

FAQ#

რას ნიშნავს */15 * * * *?

საათის ყოველი მეთხუთმეტე წუთი: 00, 15, 30 და 45. */15 ბიჯია წუთის ველში; დარჩენილი ოთხი ვარსკვლავი ნიშნავს, რომ ის არ არის შეზღუდული რომელიმე კონკრეტული საათით, რიცხვით, თვით ან კვირის დღით.

რატომ ეშვება ჩემი cron ამოცანა ორჯერ, ან არასწორ დროს?

ორი ჩვეულებრივი მიზეზია თვის დღისა და კვირის დღის წესი - თუ ორივე ველია მითითებული, cron ეშვება, როცა რომელიმე ემთხვევა - და დროის სარტყელი, რომელიც ჰოსტის ან პანელისაა და არა შენი. შეამოწმე ორივე, სანამ იფიქრებ, რომ scheduler გატეხილია.

შეუძლია თუ არა cron-ს რაიმეს გაშვება ყოველ 30 წამში?

მარტო - არა; ერთი წუთი ყველაზე წვრილი ინტერვალია. გაუშვი ამოცანა ყოველ წუთს და დააძინე 30 წამით და გაიმეორე შიგნიდან, ან გამოიყენე systemd timer OnUnitActiveSec=30s-ით, ან ციკლი ჩადე პროგრამაში, რომელსაც ის სჭირდება.

backup უნდა იყოს პირველი თუ restart?

Backup პირველი, მის წინ save ბრძანებით, შემდეგ restart კომფორტული მარაგით მოგვიანებით. გამორთვისას გადაღებული backup სერვერის backup-ია, რომელიც ითიშება, ხოლო backup, რომელიც restart-მდე სამოც წამში დაიწყო, შეიძლება არ დასრულებულიყო.

უნდა გადავტვირთო თუ არა რამე crontab-ის რედაქტირების შემდეგ?

არა. Cron ფაილს crontab -e-ის შენახვის შემდეგ ხელახლა კითხულობს. პანელზე განრიგი ძალაში შედის, როგორც კი შეინახება, და ყველაზე უსაფრთხო დადასტურებაა, რომ ერთხელ ორი წუთით წინ დააყენო და უყურო, როგორ ეშვება.

რა დროის სარტყელს იყენებს პანელის განრიგები?

იმას, რაზეც პანელია გამართული, რაც ჩვეულებრივ აპარატურის მდებარეობაა და არა შენი. ჩვენი გერმანიაშია, ამიტომ იქ ადგილობრივი დრო ზაფხულსა და ზამთარს შორის ერთი საათით იცვლება. სანამ მოვლის ფანჯარას მას ანდობ, გამოსცადე უვნებელი ამოცანით.