რატომ უნდა გიყვარდეთ systemd-ის ტაიმერები cron-ის დემონზე მეტად

ყველა, ვინც Linux-ზე დავალებებს განრიგებს, cron-ს მიმართავს, და ეს სიტყვა დაგეგმილი გაშვების ზოგად სახელად იქცა. 2026 წლის მაისში tjll.net-ის ავტორი ბლოგზე ამტკიცებს, რომ 2026 წელს პირდაპირი მნიშვნელობით cron-ის დემონი და მისი უფრო თანამედროვე ნათესავებიც არასწორი ინსტრუმენტია, systemd-ის ტაიმერი კი იმაზე მეტ სიყვარულს იმსახურებს, ვიდრე იღებს.

რატომ არა cron

მისი წინააღმდეგობები პრაქტიკულია და არა იდეოლოგიური. $PATH-ის ბუნდოვანი პარამეტრები cron-ის სკრიპტების გაშვებას ძნელად წინასწარმეტყველებადს ხდის. stdout და stderr ხშირად შავ ხვრელში ქრება ან ჰოსტის საფოსტო სისტემაში ხვდება, რაც იშვიათად არის სასურველი. გაშვებების ისტორიის თვალყურის დევნება და გამოკვლევა რთულია. განრიგის გრამატიკა კი, რომლითაც ზოგი ამაყობს, ადვილად არ იკითხება: `01,31 04,05 1-15 1,6 *` გასაშიფრად რეალურ ძალისხმევას მოითხოვს. ტაიმერები, მისი სიტყვებით, ამ ყველაფერს და მეტსაც წყვეტს.

სერვისი, ტაიმერი და განრიგი

systemd-ის ტაიმერი unit-ის ტიპია, რომელიც სხვა unit-ს — ჩვეულებრივ სერვისს — განრიგებს. სტატიის მაგალითია სერვისი, რომელსაც ათიდან ერთი შანსი აქვს კომპიუტერი გამორთოს და რომელსაც იმავე სახელის ტაიმერი უკავშირდება /etc/systemd/system-ში, ვინაიდან ტაიმერის ნაგულისხმევი Unit= პარამეტრი შესაბამის .service-ს ირჩევს. .timer-ის გაშვება მას გრაფიკზე აყენებს, მაგრამ სამიზნეს არ ასრულებს; enable კი ჩატვირთვისას ამუშავებს WantedBy=timers.target-ის მეშვეობით. ორი დეტალი ხშირად აბნევს ხალხს: ExecStart ნაგულისხმევად shell-ის გავლით არ სრულდება, ამიტომ pipe-ები ისე არ მუშაობს, როგორც დაწერილია, და ის არ იმკვიდრებს გარემოს ცვლადებს სისტემური მენეჯერის ნაგულისხმევის მიღმა.

კალენდარული მოვლენები და დროის შუალედები

cron-თან შედარებით ყველაზე დიდი კონცეპტუალური ნახტომი ისაა, რომ systemd ორ სახის განრიგს გვთავაზობს. ერთი ნაცნობი კალენდარული მოვლენაა — daily ან მისი სრული ფორმა `*-*-* 00:00:00` — მეორე კი წინა მოვლენის მიმართ გაზომილი დროის შუალედი, მაგალითად OnBootSec=1h და OnUnitActiveSec=1h, რაც ჩატვირთვიდან საათში ერთხელ და შემდეგ ყოველი გაშვებიდან საათში ერთხელ სრულდება. მეორე ფორმა ხშირად რეალურ განზრახვას ემთხვევა: დროებითი საქაღალდის გასუფთავებას ჩატვირთვისთანავე გაშვება თითქმის არაფერს აძლევს, ხოლო ბოტი, რომელიც API-ს ყოველ თხუთმეტ წუთში ზუსტად საათის მიხედვით ეკითხება, ტრაფიკის მწვერვალს ქმნის, რასაც დროის შუალედზე დაფუძნებული განრიგი აირიდებს. ავტორი პირველ წყაროდ systemd.time-ის სახელმძღვანელოს მიუთითებს და systemd-analyze calendar-ს, რომელიც გამონათქვამებს ამოწმებს, ხსნის და კლასიკური cron-ის wildcard-ებსაც კი შიფრავს.

ის ასევე გამოყოფს შესაძლებლობებს, რომლებსაც cron ვერ სთავაზობს: list-timers, რომელიც ერთ ცხრილში აჩვენებს, რა გაეშვება შემდეგ და რა გაეშვა ბოლოს; WakeSystem=, რომელიც ჩარჩენილ მანქანას აღვიძებს დავალების შესასრულებლად; FixedRandomDelay= და RandomizedOffsetSec=, რომლებიც გაშვებებს აფანტავს thundering herd-ის მწვერვალების თავიდან ასაცილებლად; და Persistent=, რომელიც გამოტოვებულ გაშვებას ტაიმერის გააქტიურებისთანავე ასრულებს — სასარგებლოა კონფიგურაციის მართვის შემოწმებისთვის გამორთულ ლეპტოპზე. მომხმარებლის დონის ტაიმერები systemctl --user-ით თანაბრად ვალიდურია, თუმცა [Install]-ის სამიზნე ზოგჯერ default.target უნდა იყოს. საათი მაინც ზუსტი უნდა იყოს და timedatectl timesync-status აჩვენებს, ასეა თუ არა.