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 perintah
systemctl 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 |
|
X | Waktu pengoperasian pengatur waktu diatur relatif terhadap saat pengaktifan pengatur waktu. |
|
X | Pengatur waktu disetel relatif terhadap saat sistem melakukan booting. |
|
X | . OnBootSec=, . , , , , , . |
|
X | , , , . |
|
X | , , , . |
|
. 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 |
|
Setiap hari setiap bulan setiap tahun, 15 menit 30 detik setelah tengah malam. |
|
Setiap hari Senin pukul 00:00:00. |
|
Sama seperti Weekly. |
|
Sama seperti Weekly. |
|
Setiap Rabu 2020 pukul 00:00:00. |
|
Setiap hari kerja pada tahun 2021 pukul 00:00:00. |
|
1 dan 15 Juni, Juli dan Agustus 2022 01:15:00setelah tengah malam. |
|
, , , 3 . |
|
, 4 , . |
|
3 , , β , . . , ~. |
|
, β . . , (-). |
,
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?
