Saya sedang dalam proses mengubah pekerjaan cron saya ke pengatur waktu systemd. Saya telah menggunakan pengatur waktu selama beberapa tahun, tetapi biasanya, saya belajar cukup untuk melakukan tugas yang sedang saya kerjakan. Saat melakukan penelitian untuk seri systemd ini, saya mengetahui bahwa pengatur waktu systemd memiliki beberapa kemampuan yang sangat menarik.
Seperti pekerjaan cron, pengatur waktu systemd dapat memicu peristiwa—skrip dan program shell—pada interval waktu tertentu, seperti sekali sehari, pada hari tertentu dalam sebulan (mungkin hanya jika hari Senin), atau setiap 15 menit selama jam kerja dari jam 8 pagi sampai jam 6 sore. Timer juga dapat melakukan beberapa hal yang tidak dapat dilakukan oleh pekerjaan cron. Misalnya, timer dapat memicu skrip atau program untuk menjalankan jumlah waktu tertentu setelah suatu peristiwa seperti booting, startup, penyelesaian tugas sebelumnya, atau bahkan penyelesaian unit layanan sebelumnya yang dipanggil oleh timer.
Pengatur waktu pemeliharaan sistem
Ketika Fedora atau distribusi berbasis systemd diinstal pada sistem baru, itu membuat beberapa penghitung waktu yang merupakan bagian dari prosedur pemeliharaan sistem yang terjadi di latar belakang setiap host Linux. Timer ini memicu peristiwa yang diperlukan untuk tugas pemeliharaan umum, seperti memperbarui database sistem, membersihkan direktori sementara, memutar file log, dan banyak lagi.
Sebagai contoh, saya akan melihat beberapa timer di workstation utama saya dengan menggunakan systemctl status *timer perintah untuk mendaftar semua penghitung waktu di Host saya. Simbol asterisk berfungsi sama seperti untuk file globbing, jadi perintah ini mencantumkan semua unit pengatur waktu 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 memiliki setidaknya enam baris informasi yang terkait dengannya:
- Baris pertama memiliki nama file pengatur waktu dan deskripsi singkat tentang tujuannya.
- Baris kedua menampilkan status timer, apakah itu dimuat, path lengkap ke file unit timer, dan preset vendor.
- Baris ketiga menunjukkan status aktifnya, yang mencakup tanggal dan waktu timer menjadi aktif.
- Baris keempat berisi tanggal dan waktu timer akan dipicu berikutnya dan perkiraan waktu hingga pemicu terjadi.
- Baris kelima menunjukkan nama acara atau layanan yang dipicu oleh timer.
- Beberapa (tetapi tidak semua) file unit systemd memiliki petunjuk ke dokumentasi yang relevan. Tiga dari penghitung waktu di output mesin virtual saya memiliki petunjuk ke dokumentasi. Ini adalah data yang bagus (tapi opsional).
- Baris terakhir adalah entri jurnal untuk contoh layanan terbaru yang dipicu oleh timer.
Tergantung pada host Anda, Anda mungkin akan memiliki set timer yang berbeda.
Buat timer
Meskipun kita dapat mendekonstruksi satu atau lebih timer yang ada untuk mempelajari cara kerjanya, mari buat unit layanan kita sendiri dan unit timer untuk memicunya. Kami akan menggunakan contoh yang cukup sepele untuk membuatnya tetap sederhana. Setelah kita menyelesaikan ini, akan lebih mudah untuk memahami cara kerja timer lain dan menentukan apa yang mereka lakukan.
Pertama, buat layanan sederhana yang akan menjalankan sesuatu yang mendasar, seperti free memerintah. Misalnya, Anda mungkin ingin memantau memori bebas secara berkala. Buat myMonitor.service berikut ini file unit di /etc/systemd/system direktori. Itu tidak perlu 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
Sekarang mari kita lihat statusnya dan uji unit layanan kita untuk memastikannya berfungsi seperti yang kita harapkan.
[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]#
Dimana keluarannya? Secara default, keluaran standar (STDOUT ) dari program yang dijalankan oleh unit layanan systemd dikirim ke jurnal systemd, yang meninggalkan catatan yang dapat Anda lihat sekarang atau nanti—sampai titik tertentu. (Saya akan melihat penjurnalan sistem dan strategi retensi dalam artikel mendatang dalam seri ini.) Lihat jurnal khusus untuk unit layanan Anda dan hanya untuk hari ini. -S opsi, yang merupakan versi pendek dari --since , memungkinkan Anda untuk menentukan periode waktu journalctl alat harus mencari entri. Ini bukan karena Anda tidak peduli dengan hasil sebelumnya — dalam hal ini, tidak akan ada — ini untuk mempersingkat waktu pencarian jika host Anda telah berjalan lama dan telah mengumpulkan banyak entri dalam jurnal:
[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 dipicu oleh layanan dapat berupa program tunggal, serangkaian program, atau skrip yang ditulis dalam bahasa skrip apa pun. Tambahkan tugas lain ke layanan dengan menambahkan baris berikut ke akhir [Service] bagian myMonitor.service berkas satuan:
ExecStart=/usr/bin/lsblkMulai layanan lagi dan periksa jurnal untuk hasilnya, yang akan terlihat seperti ini. Anda akan melihat hasil dari kedua perintah di jurnal:
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 Anda mengetahui bahwa layanan Anda berfungsi seperti yang diharapkan, buat file unit pengatur waktu, myMonitor.timer di /etc/systemd/system , dan tambahkan berikut ini:
# 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
OnCalendar spesifikasi waktu dalam myMonitor.timer file , *-*-* *:*:00 , harus memicu timer untuk mengeksekusi myMonitor.service satuan setiap menit. Saya akan menjelajahi OnCalendar pengaturannya nanti di artikel ini.
Untuk saat ini, amati entri jurnal apa pun yang berkaitan dengan menjalankan layanan Anda saat dipicu oleh timer. Anda juga dapat mengikuti penghitung waktu, tetapi mengikuti layanan memungkinkan Anda melihat hasilnya hampir secara real time. Jalankan journalctl dengan -f (ikuti) opsi:
[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Mulai tetapi jangan aktifkan timer, dan lihat apa yang terjadi setelah berjalan beberapa saat:
[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#
Satu hasil langsung muncul, dan hasil berikutnya muncul—semacam—interval satu menit. Tonton jurnal selama beberapa menit dan lihat apakah Anda memperhatikan hal yang sama yang saya lakukan:
[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 timer dan layanan.
Selengkapnya tentang sysadmin
- Aktifkan blog Sysadmin
- Perusahaan Otomatis:panduan untuk mengelola TI dengan otomatisasi
- eBook:Kemungkinan Otomatisasi untuk SysAdmins
- Kisah dari lapangan:Panduan administrator sistem untuk otomatisasi TI
- eBook:Panduan Kubernetes untuk SRE dan sysadmin
- Artikel sysadmin terbaru
Anda mungkin memperhatikan setidaknya dua hal dalam jurnal. Pertama, Anda tidak perlu melakukan sesuatu yang khusus untuk menyebabkan STDOUT dari ExecStart pemicu di myMonitor.service unit yang akan disimpan dalam jurnal. Itu semua adalah bagian dari penggunaan systemd untuk menjalankan layanan. Namun, ini berarti Anda mungkin perlu berhati-hati dalam menjalankan skrip dari unit layanan dan seberapa banyak STDOUT mereka hasilkan.
Hal kedua adalah bahwa timer tidak memicu tepat pada menit di :00 detik atau bahkan tepat satu menit dari contoh sebelumnya. Ini disengaja, tetapi dapat diganti jika perlu (atau jika hanya menyinggung perasaan sysadmin Anda).
Alasan perilaku ini adalah untuk mencegah beberapa layanan terpicu pada waktu yang sama persis. Misalnya, Anda dapat menggunakan spesifikasi waktu seperti Mingguan, Harian, dan lainnya. Semua pintasan ini ditetapkan untuk dipicu pada pukul 00:00:00 pada hari dipicu. Ketika beberapa timer ditentukan dengan cara ini, ada kemungkinan besar bahwa mereka akan mencoba untuk memulai secara bersamaan.
pengatur waktu systemd sengaja dirancang untuk memicu agak acak di sekitar waktu yang ditentukan untuk mencoba mencegah pemicu simultan. Mereka memicu semi-acak dalam jendela waktu yang dimulai pada waktu pemicu yang ditentukan dan berakhir pada waktu yang ditentukan ditambah satu menit. Waktu pemicu ini dipertahankan pada posisi stabil sehubungan dengan semua unit pengatur waktu lain yang ditentukan, menurut systemd.timer halaman manual. Anda dapat melihat dalam entri jurnal di atas bahwa timer langsung terpicu saat dimulai dan kemudian sekitar 46 atau 47 detik setelah setiap menit.
Sebagian besar waktu, waktu pemicu probabilistik seperti itu baik-baik saja. Saat menjadwalkan tugas seperti pencadangan untuk dijalankan, selama itu berjalan di luar jam kerja, tidak akan ada masalah. Seorang sysadmin dapat memilih waktu mulai deterministik, seperti 01:05:00 dalam spesifikasi tugas cron biasa, agar tidak bertentangan dengan tugas lain, tetapi ada rentang besar nilai waktu yang akan menyelesaikannya. Keacakan satu menit dalam waktu mulai biasanya tidak relevan.
Namun, untuk beberapa tugas, waktu pemicu yang tepat adalah persyaratan mutlak. Untuk itu, Anda dapat menentukan akurasi rentang waktu pemicu yang lebih besar (hingga dalam mikrodetik) dengan menambahkan pernyataan seperti ini ke Timer bagian dari file unit pengatur waktu:
AccuracySec=1usRentang waktu dapat digunakan untuk menentukan akurasi yang diinginkan serta untuk menentukan rentang waktu untuk peristiwa berulang atau satu kali. Ia mengenali unit-unit berikut:
- gunakan, kami, s
- mdtk, md
- detik, detik, detik, s
- menit, menit, menit, m
- jam, jam, jam, j
- hari, hari, h
- minggu, minggu, w
- bulan, bulan, M (didefinisikan sebagai 30,44 hari)
- tahun, tahun, y (didefinisikan sebagai 365,25 hari)
Semua timer default di /usr/lib/systemd/system tentukan rentang akurasi yang jauh lebih besar karena waktu yang tepat tidak kritis. Lihat beberapa spesifikasi di pengatur waktu yang dibuat 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]#
Lihat konten lengkap dari beberapa file unit timer di /usr/lib/systemd/system direktori untuk melihat bagaimana mereka dibangun.
Anda tidak harus mengaktifkan timer dalam eksperimen ini untuk mengaktifkannya saat boot, tetapi perintah untuk melakukannya adalah:
# systemctl enable myMonitor.timerFile unit yang Anda buat tidak perlu dieksekusi. Anda juga tidak mengaktifkan unit layanan karena dipicu oleh timer. Anda masih dapat memicu unit layanan secara manual dari baris perintah, jika Anda mau. Coba itu dan amati jurnalnya.
Lihat halaman manual untuk systemd.timer dan systemd.time untuk informasi selengkapnya tentang akurasi pengatur waktu, spesifikasi waktu peristiwa, dan peristiwa pemicu.
Jenis pengatur waktu
pengatur waktu systemd memiliki kemampuan lain yang tidak ditemukan di cron, yang hanya dipicu pada tanggal dan waktu waktu nyata yang berulang. pengatur waktu systemd dapat dikonfigurasi untuk memicu berdasarkan perubahan status di unit systemd lainnya. Misalnya, pengatur waktu mungkin dikonfigurasi untuk memicu waktu tertentu yang telah berlalu setelah boot sistem, setelah startup, atau setelah unit layanan yang ditentukan diaktifkan. Ini disebut pengatur waktu monoton. Monotonik mengacu pada hitungan atau urutan yang terus meningkat. Timer ini tidak persisten karena disetel ulang setelah setiap boot.
Tabel 1 mencantumkan timer monoton bersama dengan definisi singkat masing-masing, serta OnCalendar timer, yang tidak monoton dan digunakan untuk menentukan waktu mendatang yang mungkin berulang atau tidak berulang. Informasi ini berasal dari systemd.timer halaman manual dengan beberapa perubahan kecil.
| Pengatur waktu | Monotonik | Definisi |
|---|---|---|
OnActiveSec= | X | Ini mendefinisikan timer relatif terhadap saat timer diaktifkan. |
OnBootSec= | X | Ini mendefinisikan timer relatif terhadap saat mesin melakukan booting. |
OnStartupSec= | X | Ini mendefinisikan timer relatif terhadap saat manajer layanan pertama kali dimulai. Untuk unit pengatur waktu sistem, ini sangat mirip dengan OnBootSec= , karena manajer layanan sistem umumnya mulai sangat awal saat boot. Ini terutama berguna ketika dikonfigurasi dalam unit yang berjalan di manajer layanan per pengguna, karena manajer layanan pengguna biasanya dimulai pada login pertama saja, bukan saat boot. |
OnUnitActiveSec= | X | Ini mendefinisikan timer relatif terhadap kapan timer yang akan diaktifkan terakhir kali diaktifkan. |
OnUnitInactiveSec= | X | Ini mendefinisikan timer relatif terhadap kapan timer yang akan diaktifkan terakhir kali dinonaktifkan. |
OnCalendar= | Ini mendefinisikan timer real-time (yaitu, jam dinding) dengan ekspresi acara kalender. Lihat systemd.time(7) untuk informasi lebih lanjut tentang sintaks ekspresi acara kalender. Jika tidak, semantiknya mirip dengan OnActiveSec= dan pengaturan terkait. Timer ini adalah yang paling mirip dengan yang digunakan dengan layanan cron. |
Tabel 1:definisi pengatur waktu systemd
Timer monoton dapat menggunakan nama pintasan yang sama untuk rentang waktunya seperti AccuracySec pernyataan yang disebutkan sebelumnya, tetapi systemd menormalkan nama-nama itu menjadi detik. Misalnya, Anda mungkin ingin menentukan timer yang memicu suatu peristiwa satu kali, lima hari setelah sistem melakukan booting; yang mungkin terlihat seperti:OnBootSec=5d . Jika host melakukan booting pada 2020-06-15 09:45:27 , timer akan terpicu pada 2020-06-20 09:45:27 atau dalam satu menit setelahnya.
Spesifikasi acara kalender
Spesifikasi acara kalender adalah bagian penting dari memicu timer pada waktu berulang yang diinginkan. Mulailah dengan melihat beberapa spesifikasi yang digunakan dengan OnCalendar pengaturan.
systemd dan pengatur waktunya menggunakan gaya yang berbeda untuk spesifikasi waktu dan tanggal daripada format yang digunakan di crontab. Ini lebih fleksibel daripada crontab dan memungkinkan tanggal dan waktu fuzzy dengan cara at memerintah. Itu juga harus cukup familiar agar mudah dipahami.
Format dasar untuk pengatur waktu systemd menggunakan OnCalendar= adalah DOW YYYY-MM-DD HH:MM:SS . DOW (hari dalam seminggu) adalah opsional, dan bidang lain dapat menggunakan tanda bintang (*) untuk mencocokkan nilai apa pun untuk posisi itu. Semua formulir waktu kalender dikonversi ke formulir yang dinormalisasi. Jika waktu tidak ditentukan, diasumsikan 00:00:00. Jika tanggal tidak ditentukan tetapi waktunya ditentukan, pertandingan berikutnya mungkin hari ini atau besok, bergantung pada waktu saat ini. Nama atau nomor dapat digunakan untuk bulan dan hari dalam seminggu. Daftar yang dipisahkan koma dari setiap unit dapat ditentukan. Rentang unit dapat ditentukan dengan .. antara nilai awal dan akhir.
Ada beberapa opsi menarik untuk menentukan tanggal. Tilde (~) dapat digunakan untuk menentukan hari terakhir bulan itu atau jumlah hari tertentu sebelum hari terakhir bulan itu. Tanda “/” dapat digunakan untuk menentukan hari dalam seminggu sebagai pengubah.
Berikut adalah beberapa contoh dari beberapa spesifikasi waktu umum yang digunakan di OnCalendar pernyataan.
| Spesifikasi acara Kalender | Deskripsi |
|---|---|
| DOW YYYY-MM-DD HH:MM:SS | |
| *-*-* 00:15:30 | Setiap hari setiap bulan setiap tahun pada 15 menit dan 30 detik setelah tengah malam |
| Mingguan | Setiap Senin pukul 00:00:00 |
| Sen *-*-* 00:00:00 | Sama seperti mingguan |
| Senin | Sama seperti mingguan |
| Rabu 2020-*-* | Setiap Rabu di tahun 2020 pukul 00:00:00 |
| Senin..Jumat 2021-*-* | Setiap hari kerja di tahun 2021 pukul 00:00:00 |
| 2022-6,7,8-1,15 01:15:00 | Tanggal 1 dan 15 Juni, Juli, dan Agustus 2022 pukul 01:15:00 |
| Sen *-05~03 | Kejadian berikutnya dari hari Senin di bulan Mei setiap tahun yang juga merupakan hari ke-3 dari akhir bulan. |
| Sen..Jum *-08~04 | Hari ke-4 sebelum akhir Agustus untuk setiap tahun yang juga jatuh pada hari kerja. |
| *-05~03/2 | Hari ke-3 dari akhir bulan Mei dan kemudian lagi dua hari kemudian. Berulang setiap tahun. Perhatikan bahwa ekspresi ini menggunakan Tilde (~). |
| *-05-03/2 | Hari ketiga bulan Mei dan kemudian setiap hari ke-2 selama sisa bulan Mei. Berulang setiap tahun. Perhatikan bahwa ekspresi ini menggunakan tanda hubung (-). |
Tabel 2:Contoh OnCalendar spesifikasi acara
Uji spesifikasi kalender
systemd menyediakan alat yang sangat baik untuk memvalidasi dan memeriksa spesifikasi acara waktu kalender dalam penghitung waktu. systemd-analyze calendar alat mem-parsing spesifikasi acara waktu kalender dan menyediakan formulir yang dinormalisasi serta informasi menarik lainnya seperti tanggal dan waktu "berlalu" berikutnya, yaitu kecocokan, dan perkiraan jumlah waktu sebelum waktu pemicu tercapai.
Pertama, lihat tanggal di masa depan tanpa waktu (perhatikan bahwa waktu untuk Next elapse dan UTC akan berbeda berdasarkan zona waktu lokal Anda):
[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 tambahkan waktu. Dalam contoh ini, tanggal dan waktu dianalisis secara terpisah sebagai entitas yang tidak terkait:
[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]#
To analyze the date and time as a single unit, enclose them together in quotes. Be sure to remove the quotes when using them in the OnCalendar= event specification in a timer unit or you will get errors:
[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]#
Now test the entries in Table 2. I like the last one, especially:
[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]#
Let’s look at one example in which we list the next five elapses for the timestamp expression.
[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 ~]#
This should give you enough information to start testing your OnCalendar time specifications. The systemd-analyze tool can be used for other interesting analyses, which I will begin to explore in the next article in this series.
Summary
systemd timers can be used to perform the same kinds of tasks as the cron tool but offer more flexibility in terms of the calendar and monotonic time specifications for triggering events.
Even though the service unit you created for this experiment is usually triggered by the timer, you can also use the systemctl start myMonitor.service command to trigger it at any time. Multiple maintenance tasks can be scripted in a single timer; these can be Bash scripts or Linux utility programs. You can run the service triggered by the timer to run all the scripts, or you can run individual scripts as needed.
I will explore systemd's use of time and time specifications in much more detail in the next article.
I have not yet seen any indication that cron and at will be deprecated. I hope that does not happen because at , at least, is much easier to use for one-off task scheduling than systemd timers.
Resources
Ada banyak informasi tentang systemd yang tersedia di internet, tetapi banyak yang singkat, tumpul, atau bahkan menyesatkan. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- Proyek Fedora memiliki panduan praktis yang baik untuk systemd. Ini memiliki hampir semua yang perlu Anda ketahui untuk mengonfigurasi, mengelola, dan memelihara komputer Fedora menggunakan systemd.
- Proyek Fedora juga memiliki lembar contekan bagus yang merujuk silang perintah SystemV lama ke perintah systemd yang sebanding.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- "Lebih banyak sistem menyenangkan" dari Linux.com menawarkan informasi dan tips sistem yang lebih canggih.
Ada juga serangkaian artikel yang sangat teknis untuk sysadmin Linux oleh Lennart Poettering, perancang dan pengembang utama systemd. Artikel-artikel ini ditulis antara April 2010 dan September 2011, tetapi masih relevan sekarang seperti dulu. Banyak hal bagus lainnya yang telah ditulis tentang systemd dan ekosistemnya didasarkan pada makalah ini.
- Memikirkan kembali PID 1
- systemd untuk Administrator, Bagian I
- systemd untuk Administrator, Bagian II
- systemd untuk Administrator, Bagian III
- systemd untuk Administrator, Bagian IV
- systemd untuk Administrator, Bagian V
- systemd untuk Administrator, Bagian VI
- systemd untuk Administrator, Bagian VII
- systemd for Administrators, Part VIII
- systemd untuk Administrator, Bagian IX
- systemd untuk Administrator, Bagian X
- systemd untuk Administrator, Bagian XI