Menggunakan timer systemd sebagai ganti tugas cron

Saat ini saya sedang dalam proses mengganti pekerjaan cron saya dengan timer systemd. Saya telah menggunakan pengatur waktu selama beberapa tahun, tetapi biasanya saya tidak mendalami seluk-beluk penggunaannya, hanya mencari tahu apa yang diperlukan untuk menyelesaikan tugas yang menarik bagi saya. Saya baru-baru ini mengerjakan serangkaian artikel tentang systemd dan menemukan bahwa timer systemd memiliki beberapa fitur yang sangat menarik.







Pengatur waktu ini, seperti tugas cron, dapat, pada waktu tertentu, memicu berbagai tindakan pada sistem. Misalnya - menjalankan skrip atau program shell. Pengatur waktu bisa bekerja, misalnya sekali sehari, dan hanya pada hari Senin. Contoh lainnya adalah pengatur waktu yang menyala setiap 15 menit selama jam kerja (dari jam 8 pagi hingga 6 sore). Tetapi pengatur waktu systemd dapat melakukan sesuatu yang tidak dapat dilakukan oleh cron job. Misalnya, pengatur waktu dapat memanggil skrip atau program waktu tertentu setelah suatu peristiwa. Peristiwa semacam itu dapat berupa boot sistem atau startup systemd, penyelesaian tugas sebelumnya, atau bahkan penghentian layanan yang sebelumnya dipanggil oleh pengatur waktu.



Pengatur waktu yang digunakan untuk pemeliharaan sistem



Ketika Fedora atau distribusi Linux berbasis systemd lainnya diinstal di komputer, beberapa pengatur waktu dibuat sebagai bagian dari rutinitas pemeliharaan sistem. Prosedur ini secara otomatis dilakukan pada sistem Linux manapun. Pengatur waktu yang sesuai memicu berbagai tugas layanan, seperti memperbarui database sistem, menghapus direktori sementara, memutar file log, dan sebagainya.



Sebagai contoh, saya akan memberikan informasi di sini tentang pengatur waktu yang tersedia di mesin virtual yang saya gunakan untuk eksperimen. Di sini, untuk mendapatkan daftar semua timer, saya menggunakan perintahsystemctl status *timer... Karakter pengganti asterisk memainkan peran yang sama di sini seperti pada perintah serupa lainnya. Yaitu, ini memberi tahu sistem bahwa kita tertarik pada semua pengatur waktu (unit pengatur waktu, mereka juga disebut "file unit pengatur waktu" atau "unit pengatur waktu") dari systemd:



[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
     Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● mlocate-updatedb.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.

● sysstat-summary.timer - Generate summary of yesterday's process accounting
     Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
   Triggers: ● sysstat-summary.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.

● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
     Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
   Triggers: ● sysstat-collect.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.

● dnf-makecache.timer - dnf makecache --timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
   Triggers: ● dnf-makecache.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.

● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
   Triggers: ● systemd-tmpfiles-clean.service
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.


Setiap timer dikaitkan dengan setidaknya enam baris yang berisi informasi tentangnya:



  • Baris pertama berisi nama file timer dan penjelasan singkat tentang tujuan keberadaan timer.
  • Baris kedua menampilkan informasi tentang status pengatur waktu. Yaitu, melaporkan apakah itu dimuat, memberikan path lengkap ke file timer, menunjukkan keadaan preset vendor (dinonaktifkan atau diaktifkan).
  • Baris ketiga menunjukkan informasi tentang aktivitas timer, yang mencakup informasi tentang kapan timer diaktifkan.
  • Baris keempat berisi tanggal dan waktu dimulainya penghitung waktu berikutnya dan perkiraan waktu yang tersisa sampai dimulai.
  • Baris kelima memberi nama layanan atau acara yang dipanggil oleh pengatur waktu.
  • Beberapa (tapi tidak semua) file unit timer systemd berisi petunjuk untuk dokumentasi. Petunjuk seperti itu, dalam contoh saya, ada dalam deskripsi tiga timer.
  • Baris terakhir dalam deskripsi timer adalah entri log yang dikaitkan dengan layanan terbaru yang dipanggil oleh timer.


Jika Anda mencoba menjalankan perintah di komputer Anda systemctl status *timer, rangkaian pengatur waktu yang ditampilkan mungkin berbeda dari milik saya.



Pembuatan pengatur waktu



Meskipun kami dapat mengetahui secara spesifik bagaimana pengatur waktu bekerja dengan menganalisis pengatur waktu yang ada, saya sarankan untuk membuat file unit layanan Anda sendiri (file konfigurasi layanan , unit layanan ) dan file pengatur waktu yang akan digunakan untuk memanggil layanan terkait. Kami di sini, agar tidak memperumit cerita, berikan contoh yang agak sepele. Tapi setelah kita menanganinya, akan lebih mudah bagi Anda untuk memahami pekerjaan pengatur waktu lain.



Pertama, mari buat file konfigurasi layanan sederhana yang akan menjalankan sesuatu yang sederhana seperti perintah free. Misalnya, ini mungkin diperlukan jika kita perlu memantau jumlah memori kosong secara teratur. Mari buat file unit bernama myMonitor.servicedi folder /etc/systemd/system. Itu tidak harus dapat dieksekusi.



# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target


File ini mungkin adalah file konfigurasi layanan yang paling sederhana. Sekarang mari kita periksa statusnya dan mengujinya untuk memastikan bahwa itu berfungsi seperti yang diharapkan.



[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#


Mengapa tidak ada yang di-output ke konsol? Ini karena, secara default, keluaran standar ( stdout) dari program yang dimulai oleh systemd menggunakan file unit layanan diarahkan ke log systemd. Oleh karena itu, setidaknya selama catatan terkait ada, catatan ini dapat dianalisis. Mari kita lihat di log dan mencari entri yang terkait dengan layanan kami dan hari kami menguji. Perintah yang sesuai akan terlihat seperti ini : journalctl -S today -u myMonitor.service. Kuncinya -Sadalah versi singkat --since. Ini memungkinkan Anda untuk menentukan periode waktu untuk utilitas tersebutjournalctlmencari catatan. Intinya bukanlah kita tidak tertarik dengan hasil sebelumnya. Dalam kasus kami, hasil seperti itu tidak akan terjadi. Kunci ini digunakan untuk mengurangi waktu yang dibutuhkan utilitas untuk mencari data. Jika komputer telah bekerja untuk waktu yang lama, banyak entri dapat terkumpul di log.



[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]:               total        used        free      shared  buff/cache   available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem:       12635740      522868    11032860        8016     1080012    11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap:       8388604           0     8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#


Tugas yang diluncurkan menggunakan file konfigurasi layanan dapat direpresentasikan sebagai satu program, urutan program, atau skrip yang ditulis dalam bahasa skrip apa pun. Mari tambahkan myMonitor.servicetugas lain ke file unit , termasuk yang [Service]berikut ini di akhir bagian :



ExecStart=/usr/bin/lsblk


Mari mulai layanan lagi dan periksa log. Harus ada sesuatu di sana yang menyerupai yang ditunjukkan di bawah ini. Yakni, log harus berisi keluaran data oleh kedua perintah:



Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]:               total        used        free      shared  buff/cache   available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem:       12635740      531788    11019540        8024     1084412    11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap:       8388604           0     8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda             8:0    0  120G  0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: β”œβ”€sda1          8:1    0    4G  0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2          8:2    0  116G  0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   β”œβ”€VG01-root 253:0    0    5G  0 lvm  /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   β”œβ”€VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   β”œβ”€VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   β”œβ”€VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   β”œβ”€VG01-var  253:4    0   20G  0 lvm  /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0            11:0    1 1024M  0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.


Sekarang, setelah kita yakin semuanya bekerja dengan benar, kita akan membuat, di folder /etc/systemd/system, file unit pengatur waktu, memberinya nama myMonitor.timer. Tambahkan berikut ini ke file:



# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service

[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target


Stempel waktu OnCalendardalam file ini ,, *-*-* *:*:00harus menyebabkan timer memanggil unit myMonitor.servicesetiap menit. OnCalendarKami akan membicarakannya lebih lanjut di bawah.



Sementara itu, kita dapat melihat entri log yang terkait dengan memulai layanan pengatur waktu. Kami juga dapat mengaktifkan mode arloji timer. Namun, pemantauan layanan akan memungkinkan Anda untuk melihat hasilnya hampir secara real time. Untuk melakukan ini, Anda perlu menjalankan journalctldengan key -f( follow):



[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --


Mulai pengatur waktu, tetapi jangan memasukkannya ke dalam mulai otomatis saat boot sistem. 



[root@testvm1 ~]# systemctl start myMonitor.timer
[root@testvm1 ~]#


Perhatikan apa yang terjadi sebentar.



Salah satu hasilnya langsung muncul. Dan yang berikutnya akan ditampilkan dengan interval sekitar satu menit. Tonton majalah selama beberapa menit.



[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]:               total        used        free      shared  buff/cache   available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem:       12635740      556604    10965516        8036     1113620    11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap:       8388604           0     8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda             8:0    0  120G  0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: β”œβ”€sda1          8:1    0    4G  0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2          8:2    0  116G  0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   β”œβ”€VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   β”œβ”€VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   β”œβ”€VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   β”œβ”€VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   β”œβ”€VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]:               total        used        free      shared  buff/cache   available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem:       12635740      555228    10966836        8036     1113676    11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap:       8388604           0     8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda             8:0    0  120G  0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: β”œβ”€sda1          8:1    0    4G  0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2          8:2    0  116G  0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   β”œβ”€VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   β”œβ”€VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   β”œβ”€VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   β”œβ”€VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   β”œβ”€VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]:               total        used        free      shared  buff/cache   available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem:       12635740      553488    10968564        8036     1113688    11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap:       8388604           0     8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda             8:0    0  120G  0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: β”œβ”€sda1          8:1    0    4G  0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2          8:2    0  116G  0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   β”œβ”€VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   β”œβ”€VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   β”œβ”€VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   β”œβ”€VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   β”œβ”€VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0            11:0    1 1024M  0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.


Pastikan untuk memeriksa status pengatur waktu dan status layanan.



Apakah Anda berhasil memperhatikan di sini apa yang saya perhatikan? Anda mungkin telah memperhatikan setidaknya dua hal saat Anda membaca majalah.



Pertama - kenyataan bahwa Anda tidak perlu melakukan sesuatu yang istimewa untuk penebangan yang ExecStartdari myMonitor.servicemenulis dalam stdout. Fitur ini adalah bagian dari fungsi startup systemd standar. Tetapi ini berarti bahwa Anda mungkin perlu berhati-hati saat menjalankan skrip dari file konfigurasi layanan, mencatat berapa banyak data yang mereka tulis stdout.



Kedua, Anda mungkin memperhatikan bahwa pengatur waktu tidak dimulai tepat pada:00detik dari setiap menit, dan bahkan tidak tepat satu menit setelah lari terakhir. Ini adalah salah satu fitur pengatur waktu, jika perlu (atau jika itu menyakiti perasaan administrator sistem), perilaku pengatur waktu ini dapat diubah dengan membuatnya lebih akurat.



Alasan timer tidak mulai dalam :00hitungan detik setiap menit adalah karena sistem cenderung mencegah beberapa layanan dimulai secara bersamaan. Misalnya, saat menyiapkan indikator waktu, OnCalendarAnda dapat menggunakan nilai seperti Weekly, Dailydan lain-lain. Cara singkat penamaan titik waktu ini dikonfigurasi sehingga pengatur waktu yang digunakan untuk memulai00:00:00hari yang sesuai. Saat beberapa timer dikonfigurasi dengan cara ini, kemungkinan besar mereka akan aktif pada saat yang sama.



Inilah sebabnya mengapa pengatur waktu systemd sengaja dirancang sehingga tidak akan mulai tepat pada waktu yang ditentukan, tetapi dengan beberapa penyimpangan acak darinya. Penyimpangan ini tidak bisa disebut sepenuhnya tidak disengaja. Pengatur waktu dimulai di suatu tempat dalam jendela waktu yang dimulai pada saat yang ditentukan dan berakhir pada satu menit dari aslinya. Kali ini, sesuai dengan dokumentasi untuk systemd.timer, disimpan dalam keadaan stabil, dengan mempertimbangkan semua pengatur waktu lain yang dideklarasikan dalam sistem. Dalam fragmen log di atas, Anda dapat melihat bahwa pengatur waktu dipicu segera setelah dimulai, dan kemudian - kira-kira 46 atau 47 detik setelah dimulainya setiap menit berikutnya.



Paling sering, pendekatan probabilistik untuk menentukan waktu yang tepat dari pengatur waktu cocok untuk semua orang. Saat menjadwalkan tugas seperti membuat cadangan sesuatu sementara tugas tersebut dilakukan di luar jam kerja, ini tidak menimbulkan masalah. Administrator sistem, menyiapkan pekerjaan cron, dapat menentukan waktu yang ditentukan dengan jelas untuk memulainya, seperti 01:05:00mencoba memastikan bahwa pekerjaan ini tidak bertentangan dengan yang lain. Ada banyak cara untuk menentukan waktu yang memungkinkan ini. Perubahan acak pada waktu mulai tugas yang tidak melebihi satu menit biasanya tidak memainkan peran khusus.



Tetapi untuk beberapa tugas, waktu yang tepat dari pengatur waktu sangatlah penting. Dalam kasus seperti itu, saat menyetel pengatur waktu, Anda dapat menentukan waktu pengoperasiannya yang lebih akurat (hingga keakuratannya, diukur dalam mikrodetik). Ini dilakukan dengan menambahkan file deskripsi pengatur waktu, di bagian Timer, konstruksi yang menyerupai berikut ini:



AccuracySec=1us


Anda dapat menggunakan kata kunci khusus untuk menentukan presisi pengatur waktu yang diinginkan. Kata kunci ini juga dapat digunakan saat menyiapkan acara rutin dan satu kali. Sistem memahami kata kunci berikut:



  • Mikrodetik: usec, us, Β΅s.
  • Milidetik: msec, ms.
  • Kedua: seconds, second, sec, s.
  • Menit: minutes, minute, min, m.
  • Jam: hours, hour, hr, h.
  • Hari: days, day, d.
  • Minggu: weeks, week, w.
  • Bulan: months, month, M(bulan didefinisikan sebagai 30,44 hari).
  • Tahun: years, year, y(tahun didefinisikan sebagai 365,25 hari).


Semua timer standar yang tersedia di /usr/lib/systemd/systemdikonfigurasi menggunakan rentang yang lebih panjang yang menyetel keakuratan pemicuannya, karena dalam kasus timer ini, pemicuannya pada waktu yang ditentukan secara ketat tidak terlalu penting. Lihat spesifikasi beberapa timer yang dihasilkan sistem:



[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#


Untuk mendapatkan pemahaman yang lebih baik tentang struktur internal file pengatur waktu dari direktori /usr/lib/systemd/system, Anda dapat melihat isinya.



Anda tidak perlu mengonfigurasi pengatur waktu pembelajaran kami untuk diaktifkan saat sistem Anda boot. Namun, jika Anda mau, Anda dapat menggunakan perintah berikut untuk ini:



[root@testvm1 system]# systemctl enable myMonitor.timer


File timer yang akan Anda buat tidak perlu dapat dieksekusi. Selain itu, file konfigurasi layanan tidak perlu dikonfigurasi untuk diaktifkan saat boot, karena dipanggil oleh timer. Jika perlu, layanan juga dapat dipanggil secara manual dari baris perintah. Coba ini dan lihat di log systemd.



Untuk mempelajari lebih lanjut tentang keakuratan timer, cara menentukan waktu pemicuan peristiwa, dan cara memicu peristiwa, lihat dokumentasi untuk systemd.timerdan systemd.time.



Jenis pengatur waktu



Pengatur waktu Systemd memiliki fitur lain yang tidak dimiliki tugas cron, satu kali atau berulang, yang hanya dipanggil dengan tanggal waktu nyata dan waktu nyata. Timer Systemd dapat dikonfigurasi untuk dipanggil berdasarkan perubahan status unit systemd lainnya. Misalnya, pengatur waktu dapat dikonfigurasi sehingga akan dipicu setelah waktu tertentu setelah sistem melakukan booting, setelah pengguna masuk ke dalamnya, atau setelah waktu tertentu setelah mengaktifkan layanan tertentu. Pengatur waktu ini disebut monotonik. Pengatur waktu ini disetel ulang setelah setiap boot ulang sistem.



Tabel berikut menunjukkan daftar timer monotonik dengan penjelasan singkat tentang masing-masing timer tersebut. Ada juga deskripsi timer.OnCalendar, yang tidak monoton dan digunakan dalam kasus di mana Anda perlu mengatur peluncuran satu kali atau berulang kali di masa depan. Tabel ini berdasarkan dokumentasi systemd.timer.

Timer Nada datar Deskripsi
OnActiveSec=


X Waktu pengoperasian pengatur waktu diatur relatif terhadap saat pengaktifan pengatur waktu.
OnBootSec=


X Pengatur waktu disetel relatif terhadap saat sistem melakukan booting.
OnStartupSec=


X . OnBootSec=, . , , , , , .
OnUnitActiveSec=


X , , , .
OnUnitInactiveSec=


X , , , .
OnCalendar=


  . systemd.time(7). OnActiveSec=. β€” systemd, , cron.


Saat mengatur timer monotonik, kata kunci yang sama dapat digunakan seperti yang dijelaskan di atas saat membicarakannya AccuracySec. Tetapi perlu dicatat bahwa systemd mengubah interval waktu yang sesuai menjadi detik. Misalnya, Anda mungkin ingin menyetel pengatur waktu yang menyala sekali, lima hari setelah sistem melakukan booting. Ini mungkin terlihat seperti deskripsi seperti ini: OnBootSec=5d. Jika komputer itu boot 2020-06-15di 09:45:27, timer akan mulai 2020-06-20pada 09:45:27(atau dalam waktu 1 menit setelah titik waktu).



Deskripsi acara kalender



Menerapkan acara kalender adalah bagian penting dalam mendeskripsikan pengatur waktu yang dipanggil secara berkala. Mari kita periksa beberapa fitur dari peristiwa tersebut yang digunakan saat mengatur indikator waktu OnCalendar.



Systemd dan pengatur waktu yang sesuai menggunakan format waktu dan tanggal yang berbeda dari crontab. Format ini lebih fleksibel daripada yang digunakan di crontab. Ini memungkinkan Anda untuk menentukan tanggal dan waktu dengan cara yang disederhanakan, dalam gaya perintah at. Bagi mereka yang terbiasa dengannya at, seharusnya mudah untuk memahami pengaturan timer systemd.



Saat digunakan OnCalendar=untuk mengatur pengatur waktu, format dasar berikut digunakan untuk menentukan tanggal dan waktu:



DOW YYYY-MM-DD HH:MM:SS


DOW(Day Of Week), ini adalah bagian opsional dari konstruksi di atas. Di bidang lain, Anda dapat menggunakan simbol asterisk ( *) untuk mewakili nilai apa pun yang mungkin ada di posisinya. Semua bentuk indikasi tanggal dan waktu diubah menjadi bentuk normalisasi. Jika tidak ada waktu yang ditentukan, maka dianggap demikian 00:00:00. Jika tanggal tidak ditentukan, tetapi waktu ditentukan, maka pengatur waktu akan bekerja pada hari dimulainya (secara relatif, "hari ini"), atau hari berikutnya ("besok"). Itu tergantung pada waktu saat ini. Bulan dan hari dalam seminggu dapat diberi nama menggunakan namanya. Anda dapat menggunakan daftar nilai yang dipisahkan koma di sini. Rentang nilai dapat dipisahkan oleh tiga titik ( …), yang muncul di antara nilai awal dan akhir rentang.



Saat menentukan tanggal, kami memiliki beberapa opsi menarik yang kami inginkan. Misalnya, tilde (~) dapat digunakan untuk menunjukkan hari terakhir suatu bulan, atau untuk menunjukkan tanggal sejumlah hari sebelum hari terakhir bulan itu. Garis miring (/) dapat digunakan sebagai pengubah untuk menunjukkan hari dalam seminggu.



Tabel berikut menunjukkan beberapa contoh umum pengaturan waktu yang digunakan dalam ekspresi OnCalendar.



Contoh penyajian acara kalender DOW YYYY-MM-DD HH:MM:SS

Deskripsi
*-*-* 00:15:30


Setiap hari setiap bulan setiap tahun, 15 menit 30 detik setelah tengah malam.
Weekly


Setiap hari Senin pukul 00:00:00.
Mon *-*-* 00:00:00


Sama seperti Weekly.
Mon


Sama seperti Weekly.
Wed 2020-*-*


Setiap Rabu 2020 pukul 00:00:00.
Mon..Fri 2021-*-*


Setiap hari kerja pada tahun 2021 pukul 00:00:00.
2022-6,7,8-1,15 01:15:00


1 dan 15 Juni, Juli dan Agustus 2022 01:15:00setelah tengah malam.
Mon *-05~03


, , , 3 .
Mon..Fri *-08~04


, 4 , .
*-05~03/2


3 , , β€” , . . , ~.
*-05-03/2


, β€” . . , (-).


,



Systemd memiliki alat yang hebat untuk memeriksa dan memeriksa spesifikasi acara kalender. Kami berbicara tentang tim systemd-analyze calendaryang mengurai deskripsi acara kalender dan menyajikannya dalam bentuk yang dinormalisasi. Perintah ini juga memberikan informasi menarik lainnya, seperti tanggal dan waktu acara berikutnya, dan perkiraan waktu yang tersisa hingga saat itu.



Pertama, mari kita lihat spesifikasinya, yang hanya berisi tanggal, tidak berisi informasi tentang waktu (perhatikan bahwa waktu di kolom Next elapsedan (in UTC)berbeda, perbedaan ini tergantung pada zona waktu lokal):



[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#


Sekarang mari tambahkan informasi waktu ke deskripsi. Dalam contoh ini, tanggal dan waktu dianalisis secara terpisah, sebagai entitas yang tidak terkait satu sama lain:



[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#


Sekarang perhatikan contoh di mana tanggal dan waktu dianggap bersama. Untuk melakukan ini, mereka harus diapit tanda kutip. Tetapi jika Anda menggunakan konstruksi seperti itu OnCalendar, jangan lupa untuk menghapus tanda kutip, jika tidak, Anda akan menghadapi kesalahan:



[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16        
    Next elapse: Mon 2030-06-17 15:21:16 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#


Sekarang mari kita periksa sesuatu dari tabel sebelumnya. Saya terutama menyukai deskripsi ini darinya:



2022-6,7,8-1,15 01:15:00


Mari kita analisis:



[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
  Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
    Next elapse: Wed 2022-06-01 01:15:00 EDT
       (in UTC): Wed 2022-06-01 05:15:00 UTC
       From now: 1 years 11 months left
[root@testvm1 system]#


Sekarang mari kita lihat deskripsinya Mon *-05~3, tetapi kali ini kita akan meminta informasi program tentang 5 kali timer berikutnya, yang menggunakan pengaturan berikut:



[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3                
Normalized form: Mon *-05~03 00:00:00      
    Next elapse: Mon 2023-05-29 00:00:00 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#


Saya yakin kita telah membahas cukup banyak kasus penggunaan systemd-analyze calendaruntuk membantu Anda mulai menguji deskripsi acara kalender Anda sendiri. Perlu diingat bahwa alat tersebut systemd-analyzememiliki fitur menarik lainnya.



Bahan tambahan



Ada banyak publikasi di systemd di internet, tetapi kebanyakan terlalu pendek, sangat sederhana, atau bahkan buggy. Artikel ini memberikan beberapa sumber informasi yang baik tentang systemd. Di bawah ini adalah daftar tautan ke beberapa materi berkualitas lainnya tentang topik ini. 



  • Panduan praktis untuk systemd oleh Proyek Fedora.
  • Lembar contekan dari Proyek Fedora yang memetakan perintah SystemV dan systemd lama.
  • Detail tentang systemd dan mengapa itu dibuat.
  • Materi dengan informasi dan saran, didedikasikan untuk systemd.
  • (Lennart Poettering), systemd. , 2010 2011, . systemd .
  • systemd.
  • systemd.




Timer Systemd dapat digunakan untuk menyelesaikan tugas yang sama dengan tugas cron. Tetapi systemd memberi Anda lebih banyak fleksibilitas dalam hal mengonfigurasi kalender dan pengatur waktu monotonik.



Meskipun file konfigurasi layanan yang kami buat selama eksperimen kami biasanya dipanggil menggunakan timer, Anda dapat memanggilnya kapan saja menggunakan perintah seperti systemctl start myMonitor.service. Satu pengatur waktu dapat memulai beberapa tugas. Ini bisa berupa, misalnya, skrip Bash dan utilitas Linux. File konfigurasi layanan dapat dibuat sehingga ketika dipanggil, beberapa skrip dijalankan. Anda juga dapat menjalankan skrip secara terpisah.



Jika kita berbicara tentang koeksistensi systemd, cron dan at, maka saya ingin mencatat bahwa saya belum melihat tanda-tanda cron atau tidak digunakan lagi. Saya berharap mereka akan terus didukung, karena setidaknya jauh lebih mudah daripada systemd untuk digunakan untuk menjadwalkan tugas satu kali.



Apa yang kamu gunakan? Pengatur waktu sistem atau tugas cron?






All Articles