Clever Geek Handbook

استخدام مؤقتات systemd بدلاً من وظائف cron

أنا حاليًا بصدد استبدال وظائف cron الخاصة بي بمؤقتات systemd. لقد كنت أستخدم أجهزة ضبط الوقت لعدة سنوات ، لكنني عادةً لم أتعمق في تعقيدات استخدامها ، ولم أكتشف سوى ما هو مطلوب لإكمال المهمة التي تهمني. لقد عملت مؤخرًا على سلسلة من المقالات حول systemd واكتشفت أن مؤقتات systemd لها بعض الميزات المثيرة للاهتمام.







يمكن لهذه العدادات ، مثل وظائف cron ، في وقت معين ، تشغيل إجراءات مختلفة على النظام. على سبيل المثال - تشغيل البرامج النصية أو البرامج شل. يمكن أن تعمل أجهزة ضبط الوقت ، على سبيل المثال ، مرة واحدة في اليوم ، وفي أيام الاثنين فقط. مثال آخر هو المؤقت الذي يعمل كل 15 دقيقة خلال ساعات العمل (من 8 صباحًا إلى 6 مساءً). لكن مؤقتات النظام يمكنها أن تفعل شيئًا لا تستطيع وظائف كرون القيام به. على سبيل المثال ، يمكن للمؤقت استدعاء نص أو برنامج في وقت محدد بعد الحدث. يمكن أن يكون مثل هذا الحدث هو بدء تشغيل النظام أو بدء تشغيل النظام ، أو إكمال مهمة سابقة ، أو حتى إنهاء خدمة تم استدعاؤها مسبقًا بواسطة جهاز ضبط الوقت.



الموقتات المستخدمة لصيانة النظام



عندما يتم تثبيت Fedora أو أي توزيعة Linux أخرى تستند إلى systemd على جهاز كمبيوتر ، يتم إنشاء عدة مؤقتات كجزء من إجراءات صيانة النظام. يتم تنفيذ هذه الإجراءات تلقائيًا على أي نظام Linux. تقوم أجهزة ضبط الوقت المقابلة بتشغيل مهام خدمة متنوعة ، مثل تحديث قواعد بيانات النظام ، ومسح الدلائل المؤقتة ، وتناوب ملفات السجل ، وما إلى ذلك.



على سبيل المثال ، سأقدم هنا معلومات حول المؤقتات المتوفرة على الجهاز الظاهري الذي استخدمته لإجراء التجارب. هنا ، للحصول على قائمة بجميع أجهزة ضبط الوقت ، استخدمت الأمرsystemctl status *timer... يلعب حرف البدل العلامة النجمية نفس الدور هنا كما هو الحال في أوامر أخرى مماثلة. وهي تخبر النظام بأننا مهتمون بجميع أجهزة ضبط الوقت (وحدات المؤقت ، وتسمى أيضًا "ملفات وحدة المؤقت" أو "وحدات المؤقت") من 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.


يرتبط كل عداد بستة أسطر على الأقل تحتوي على معلومات عنها:



  • يحتوي السطر الأول على اسم ملف المؤقت ووصف موجز للغرض من وجود جهاز ضبط الوقت.
  • يعرض السطر الثاني معلومات حول حالة المؤقت. وهي تشير إلى ما إذا كان قد تم تحميله ، أو يعطي المسار الكامل لملف المؤقت ، أو يعرض حالة الإعداد المسبق للمورد (معطل أو ممكّن).
  • يعرض السطر الثالث معلومات حول نشاط المؤقت ، والذي يتضمن معلومات حول وقت تنشيط المؤقت.
  • يحتوي السطر الرابع على تاريخ ووقت البدء التالي للمؤقت والوقت التقريبي المتبقي حتى يبدأ.
  • يعطي السطر الخامس اسم الخدمة أو الحدث الذي تم استدعاؤه بواسطة جهاز ضبط الوقت.
  • تحتوي بعض (وليس كل) ملفات وحدة مؤقت systemd على مؤشرات للتوثيق. هذه المؤشرات ، في مثالي ، في أوصاف ثلاثة مؤقتات.
  • السطر الأخير في وصف عداد الوقت هو إدخال السجل المرتبط بأحدث مثيل للخدمة التي تم استدعاؤها بواسطة المؤقت.


إذا حاولت تنفيذ أمر ما على جهاز الكمبيوتر الخاص بك systemctl status *timer، فقد تختلف مجموعة المؤقتات المقدمة إليه عن تلك الخاصة بي.



إنشاء الموقت



على الرغم من أنه يمكننا معرفة تفاصيل كيفية عمل أجهزة ضبط الوقت من خلال تحليل أي مؤقتات موجودة ، أقترح إنشاء ملف وحدة الخدمة الخاص بك (ملف تكوين الخدمة ، وحدة الخدمة ) وملف المؤقت الذي سيتم من خلاله استدعاء الخدمة المقابلة. نحن هنا ، من أجل عدم تعقيد القصة ، أعط مثالًا بسيطًا إلى حد ما. ولكن بعد أن نتعامل معها ، سيكون من الأسهل عليك فهم عمل أجهزة ضبط الوقت الأخرى.



أولاً ، لنقم بإنشاء ملف تكوين خدمة بسيط يقوم بتشغيل شيء بسيط مثل الأمر free. على سبيل المثال ، قد يكون هذا مطلوبًا إذا احتجنا إلى مراقبة مقدار الذاكرة الخالية بانتظام. لنقم بإنشاء ملف وحدة مسمى myMonitor.serviceفي المجلد /etc/systemd/system. لا يجب أن تكون قابلة للتنفيذ. 



# 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


ربما يكون هذا الملف هو أبسط ملف تكوين خدمة. الآن دعنا نتحقق من حالتها ونختبرها للتأكد من أنها تعمل كما هو متوقع. 



[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]#


لماذا لا يتم إخراج أي شيء إلى وحدة التحكم؟ هذا لأنه ، بشكل افتراضي ، stdoutيتم إعادة توجيه الإخراج القياسي ( ) من البرامج التي بدأها systemd باستخدام ملفات وحدة الخدمة إلى سجل النظام. نتيجة لهذا ، على الأقل طالما أن السجلات المقابلة موجودة ، يمكن تحليل هذه السجلات. دعنا نلقي نظرة في السجل ونبحث عن الإدخالات المتعلقة بخدمتنا واليوم الذي اختبرنا فيه. سيبدو الأمر المقابل هكذا : journalctl -S today -u myMonitor.service. المفتاح -Sهو نسخة مختصرة --since. يسمح لك بتحديد الفترة الزمنية للأداة المساعدةjournalctlأبحث عن السجلات. النقطة ليست أننا لسنا مهتمين بالنتائج السابقة. في حالتنا ، هذه النتائج ببساطة لن تكون كذلك. يُستخدم هذا المفتاح لتقليل الوقت الذي تحتاجه الأداة المساعدة للبحث عن البيانات. إذا كان الكمبيوتر يعمل لفترة طويلة ، يمكن أن تتراكم الكثير من الإدخالات في السجل. 



[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]#


يمكن تمثيل المهمة التي يتم تشغيلها باستخدام ملف تكوين الخدمة كبرنامج واحد أو سلسلة من البرامج أو نص مكتوب بأي لغة برمجة نصية. لنضيف myMonitor.serviceمهمة أخرى إلى ملف الوحدة ، بما في ذلك ما [Service]يلي في نهاية القسم : 



ExecStart=/usr/bin/lsblk


لنبدأ الخدمة مرة أخرى ونتحقق من السجل. يجب أن يكون هناك شيء يشبه ما هو موضح أدناه. وبالتحديد ، يجب أن يتم إخراج البيانات بواسطة كلا الأمرين في السجل: 



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.


الآن ، بعد أن نتأكد من أن كل شيء يعمل بشكل صحيح ، سننشئ ، في المجلد /etc/systemd/system، ملف وحدة المؤقت ، مع إعطائه اسمًا myMonitor.timer. يضاف ما يلي إلى الملف: 



# 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في هذا الملف ، في *-*-* *:*:00أن يقوم المؤقت باستدعاء الوحدة myMonitor.serviceكل دقيقة. OnCalendarسنتحدث أكثر عن ذلك أدناه.



في غضون ذلك ، يمكننا إلقاء نظرة على إدخالات السجل المتعلقة ببدء خدمة المؤقت. يمكننا أيضًا تشغيل وضع ساعة المؤقت. ومع ذلك ، ستتيح لك مراقبة الخدمة رؤية النتائج في الوقت الفعلي تقريبًا. للقيام بذلك ، تحتاج إلى التشغيل journalctlباستخدام المفتاح -f( follow): 



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


ابدأ المؤقت ، لكن لا تقم بتضمينه في تشغيل تلقائي عند تمهيد النظام.  



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


شاهد ما يحدث لبعض الوقت.



تظهر إحدى النتائج على الفور. وسيتم عرض العناصر التالية على فترات تبلغ حوالي دقيقة واحدة. شاهد المجلة لبضع دقائق. 



[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.


تأكد من التحقق من حالة المؤقت وحالة الخدمة.



هل تمكنت من ملاحظة ما لاحظته هنا؟ ربما لاحظت شيئين على الأقل أثناء قراءة المجلة.



أولا - حقيقة أنك لست بحاجة إلى القيام بشيء خاص لتسجيل ذلك ExecStartمن myMonitor.serviceالكتابة في stdout. هذه الميزة هي جزء من وظائف بدء تشغيل النظام القياسية. ولكن هذا يعني أنك ستحتاج على الأرجح إلى توخي الحذر عند تشغيل البرامج النصية من ملفات تكوين الخدمة ، مع الإشارة إلى مقدار البيانات التي يكتبون إليها stdout.



ثانيًا ، ربما لاحظت أن المؤقت لا يبدأ بالضبط عند:00ثواني من كل دقيقة ، ولا حتى دقيقة واحدة بالضبط بعد آخر تشغيل. هذه إحدى ميزات هذه العدادات ، إذا لزم الأمر (أو إذا كان ذلك يضر بمشاعر مسؤول النظام) ، يمكن تغيير سلوك العدادات هذا بجعلها أكثر دقة.



السبب في أن المؤقت لا يبدأ في :00ثوانٍ من كل دقيقة لأن النظام يميل بالتالي إلى منع خدمات متعددة من البدء في وقت واحد. على سبيل المثال ، عند إعداد مؤشر الوقت ، OnCalendarيمكنك استخدام قيم مثل Weekly، Dailyوغيرها. يتم إعداد طرق الاختصار هذه لتسمية الأوقات بحيث تبدأ المؤقتات التي يتم استخدامها فيها00:00:00اليوم المقابل. عندما يتم تكوين العديد من أجهزة ضبط الوقت بهذه الطريقة ، تكون هناك احتمالية كبيرة لإطلاقها جميعًا في نفس الوقت.



هذا هو سبب تصميم مؤقتات systemd بشكل متعمد بحيث لا تبدأ في الوقت المحدد بالضبط ، ولكن مع بعض الانحراف العشوائي عنها. لا يمكن تسمية هذا الانحراف بالصدفة تمامًا. تبدأ المؤقتات في مكان ما في نافذة زمنية تبدأ في اللحظة المحددة وتنتهي في دقيقة واحدة من الأصل. هذه المرة ، وفقًا للوثائق الخاصة بـ systemd.timer، يتم الاحتفاظ بها في حالة مستقرة ، مع مراعاة جميع أجهزة ضبط الوقت الأخرى المعلنة في النظام. في مقتطف السجل أعلاه ، يمكنك أن ترى أنه يتم تشغيل المؤقت فور بدئه ، وبعد ذلك بحوالي 46 أو 47 ثانية بعد بدء كل دقيقة تالية.



في أغلب الأحيان ، مثل هذا النهج الاحتمالي لتحديد التوقيت الدقيق لأجهزة ضبط الوقت يناسب الجميع. عند جدولة المهام مثل عمل نسخة احتياطية من شيء ما طالما يتم تنفيذ هذه المهام خارج ساعات العمل ، فإن هذا لا يسبب أي مشاكل. يمكن لمسؤول النظام ، الذي يقوم بإعداد وظائف cron ، تحديد وقت محدد بوضوح لبدء تشغيلها ، مثل 01:05:00محاولة ضمان عدم تعارض هذه الوظائف مع الآخرين. هناك مجموعة واسعة من الطرق لتحديد الوقت الذي يسمح بذلك. التغييرات العشوائية في وقت بدء مهمة لا تتجاوز الدقيقة عادة لا تلعب دورًا خاصًا.



لكن بالنسبة لبعض المهام ، فإن التوقيت الدقيق للمؤقت مهم للغاية. في مثل هذه الحالات ، عند ضبط المؤقتات ، يمكنك تحديد وقت أكثر دقة لتشغيلها (حتى الدقة ، تُقاس بالميكروثانية). يتم ذلك عن طريق إضافة Timerبنية مشابهة لما يلي إلى ملف وصف المؤقت : 



AccuracySec=1us


يمكنك استخدام كلمات رئيسية خاصة لتحديد الدقة المطلوبة للمؤقت. يمكن أيضًا استخدام هذه الكلمات الأساسية عند إعداد أحداث متكررة ومرة ​​واحدة. يفهم النظام الكلمات الرئيسية التالية:



  • ميكرو ثانية: usec، us، µs.
  • ميلي ثانية: msec، ms.
  • ثانيًا: seconds، second، sec، s.
  • الدقيقة: minutes، minute، min، m.
  • الساعة: hours، hour، hr، h.
  • اليوم: days، day، d.
  • الأسبوع: weeks، week، w.
  • الشهر: months، month، M(يتم تعريف الشهر 30.44 يوما).
  • العام: years، year، y(يتم تعريف السنة كما 365.25 يوما).


/usr/lib/systemd/systemيتم تكوين جميع أجهزة ضبط الوقت القياسية المتوفرة باستخدام نطاقات أطول بكثير تحدد دقة تشغيلها ، لأنه في حالة هذه العدادات ، فإن تشغيلها في وقت محدد بدقة ليس مهمًا بشكل خاص. ألق نظرة على مواصفات بعض أجهزة ضبط الوقت التي تم إنشاؤها بواسطة النظام: 



[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]#


للحصول على فهم أفضل للبنية الداخلية لملفات المؤقت من الدليل /usr/lib/systemd/system، يمكنك عرض محتوياتها.



لا تحتاج إلى تكوين مؤقت التعلم الخاص بنا للتنشيط عند بدء تشغيل نظامك. ومع ذلك ، إذا أردت ، يمكنك استخدام الأمر التالي لهذا: 



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


لا يلزم أن تكون ملفات المؤقت التي ستقوم بإنشائها قابلة للتنفيذ. بالإضافة إلى ذلك ، لا تحتاج ملفات تكوين الخدمة إلى التهيئة لتنشيطها عند التمهيد ، حيث يتم استدعاؤها بواسطة أجهزة ضبط الوقت. إذا لزم الأمر ، يمكن أيضًا استدعاء الخدمة يدويًا من سطر الأوامر. جرب هذا وابحث في سجل النظام.



لمعرفة المزيد حول دقة أجهزة ضبط الوقت ، وكيفية تحديد وقت تشغيل الحدث ، وكيفية تشغيل الأحداث ، راجع وثائق systemd.timerو systemd.time.



أنواع الموقت



تحتوي أجهزة ضبط الوقت Systemd على ميزات أخرى لا تتوفر في وظائف cron ، "لمرة واحدة" أو متكررة ، والتي يتم استدعاؤها فقط مع التواريخ في الوقت الفعلي وفي الوقت الفعلي. يمكن تكوين مؤقتات Systemd ليتم استدعاؤها بناءً على التغييرات في حالة وحدات systemd الأخرى. على سبيل المثال ، يمكن تكوين عداد الوقت بحيث يتم تشغيله بعد وقت محدد بعد بدء تشغيل النظام ، أو بعد تسجيل المستخدم الدخول إليه ، أو بعد وقت محدد بعد تنشيط خدمة معينة. هذه العدادات تسمى رتيبة. يتم إعادة ضبط هذه المؤقتات بعد كل إعادة تشغيل للنظام.



يعرض الجدول التالي قائمة المؤقتات الرتيبة مع وصف موجز لكل منها. يوجد أيضًا وصف للمؤقت.OnCalendar، وهي ليست رتيبة وتستخدم في الحالات التي تحتاج فيها إلى تنظيم إطلاق لمرة واحدة أو متكرر لشيء ما في المستقبل. هذا الجدول يعتمد على الوثائق systemd.timer.

الموقت روتيني وصف 
OnActiveSec=


X يتم ضبط وقت تشغيل المؤقت بالنسبة إلى لحظة تنشيط الموقت. 
OnBootSec=


X يتم ضبط المؤقت بالنسبة إلى لحظة تمهيد النظام. 
OnStartupSec=


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


X , , , . 
OnUnitInactiveSec=


X , , , . 
OnCalendar=


  . systemd.time(7). OnActiveSec=. — systemd, , cron.


عند ضبط مؤقتات رتيبة ، يمكن استخدام الكلمات الرئيسية نفسها كما هو موضح أعلاه عند الحديث عنها AccuracySec. ولكن تجدر الإشارة إلى أن systemd يحول الفترات الزمنية المقابلة إلى ثوانٍ. على سبيل المثال ، قد ترغب في تعيين مؤقت يعمل مرة واحدة ، بعد خمسة أيام من بدء تشغيل النظام. قد تبدو وكأنها وصف مثل هذا: OnBootSec=5d. إذا تم تمهيد الكمبيوتر 2020-06-15عند 09:45:27، سيبدأ المؤقت 2020-06-20في 09:45:27(أو في غضون دقيقة واحدة بعد هذه النقطة الزمنية).



وصف أحداث التقويم



يعد تطبيق أحداث التقويم جزءًا أساسيًا من وصف أجهزة ضبط الوقت التي يتم استدعاؤها على فترات منتظمة. دعونا نفحص بعض ميزات مثل هذه الأحداث المستخدمة عند ضبط مؤشر الوقت OnCalendar.



يستخدم Systemd وأجهزة ضبط الوقت الخاصة به تنسيق وقت وتاريخ مختلفين عن crontab. هذا التنسيق أكثر مرونة من التنسيق المستخدم في crontab. يسمح لك بتحديد التاريخ والوقت بطريقة مبسطة ، بأسلوب الأمر at. لمن هم على دراية به at، يجب أن يكون من السهل فهم إعدادات مؤقت النظام.



عند استخدامه OnCalendar=لإعداد المؤقتات ، يتم استخدام التنسيق الأساسي التالي لتحديد التاريخ والوقت: 



DOW YYYY-MM-DD HH:MM:SS


DOW(يوم من الأسبوع) هو جزء اختياري من البناء أعلاه. في الحقول الأخرى ، يمكنك استخدام رمز العلامة النجمية ( *) لتمثيل أي قيمة قد تكون في الموضع الذي تشغله. يتم تحويل جميع أشكال الإشارة إلى التاريخ والوقت إلى النموذج العادي. إذا لم يتم تحديد وقت ، فمن المفترض أن يكون 00:00:00. إذا لم يتم تحديد التاريخ ، ولكن تم تحديد الوقت ، فسيعمل المؤقت إما في اليوم الذي يبدأ فيه (التحدث نسبيًا ، "اليوم") ، أو في اليوم التالي ("غدًا"). ذلك يعتمد على الوقت الحالي. يمكن تسمية أشهر وأيام الأسبوع باستخدام أسمائها. يمكنك استخدام قوائم القيم المفصولة بفواصل هنا. يمكن فصل نطاقات القيم بثلاث نقاط ( …) بين قيمة البداية والنهاية للنطاق.



عند تحديد التواريخ ، لدينا خياران مثيران للاهتمام تحت تصرفنا. وبالتالي ، يمكن استخدام علامة التلدة (~) للإشارة إلى اليوم الأخير من الشهر ، أو للإشارة إلى تاريخ عدد معين من الأيام قبل اليوم الأخير من الشهر. يمكن استخدام الشرطة المائلة للأمام (/) كمعدِّل للإشارة إلى يوم الأسبوع.



يوضح الجدول التالي بعض الأمثلة النموذجية للتوقيت المستخدم في التعبير OnCalendar.



مثال على تقديم حدث في التقويم DOW YYYY-MM-DD HH:MM:SS

وصف 
*-*-* 00:15:30


كل يوم من كل شهر من كل عام 15 دقيقة و 30 ثانية بعد منتصف الليل. 
Weekly


كل يوم اثنين في 00:00:00. 
Mon *-*-* 00:00:00


نفس Weekly. 
Mon


نفس Weekly. 
Wed 2020-*-*


كل يوم أربعاء 2020 في 00:00:00. 
Mon..Fri 2021-*-*


كل يوم من أيام الأسبوع في 2021 في الساعة 00:00:00. 
2022-6,7,8-1,15 01:15:00


1 و 15 يونيو ، يوليو وأغسطس 2022 01:15:00بعد منتصف الليل. 
Mon *-05~03


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


, 4 , . 
*-05~03/2


3 , , — , . . , ~. 
*-05-03/2


, — . . , (-).


,



Systemd لديه أداة رائعة لفحص وفحص مواصفات أحداث التقويم. نحن نتحدث عن فريق يقوم systemd-analyze calendarبتحليل أوصاف أحداث التقويم وتقديمها في شكل طبيعي. يوفر هذا الأمر أيضًا معلومات أخرى مثيرة للاهتمام ، مثل تاريخ ووقت الحدث التالي من هذا القبيل ، والوقت التقريبي المتبقي حتى تلك اللحظة.



أولا، دعونا نلقي نظرة على المواصفات، والذي يحتوي على التاريخ فقط، لا تحتوي على معلومات حول الوقت (علما بأن مرات في الحقول Next elapseو (in UTC)مختلفة، وهذا الاختلاف يعتمد على المنطقة الزمنية المحلية): 



[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]#


الآن دعنا نضيف معلومات الوقت إلى الوصف. في هذا المثال ، يتم تحليل التاريخ والوقت بشكل منفصل ، ككيانات لا ترتبط ببعضها البعض: 



[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]#


الآن ضع في اعتبارك مثالاً يتم فيه اعتبار التاريخ والوقت معًا. للقيام بذلك ، يجب أن تكون محاطة بعلامات اقتباس. ولكن إذا كنت تستخدم مثل هذا البناء في OnCalendar، فلا تنس إزالة علامات الاقتباس ، وإلا فستواجه أخطاء: 



[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]#


الآن دعنا نتحقق من شيء من الجدول السابق. أنا أحب هذا الوصف منها بشكل خاص: 



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


دعنا نحللها: 



[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]#


الآن دعنا نلقي نظرة على الوصف Mon *-05~3، ولكن هذه المرة سنطلب من البرنامج معلومات حول المرات الخمس التالية من المؤقت ، والذي يستخدم الإعدادات التالية: 



[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 ~]#


أعتقد أننا قمنا بتغطية حالات استخدام كافية systemd-analyze calendarلبدء اختبار أوصاف أحداث التقويم الخاصة بك. ضع في اعتبارك أن الأداة systemd-analyzeبها ميزات أخرى مثيرة للاهتمام.



مواد إضافية



هناك العديد من المنشورات على systemd على الإنترنت ، لكنها غالبًا ما تكون قصيرة جدًا أو مبسطة جدًا أو حتى بها أخطاء. توفر هذه المقالة بعض المصادر الجيدة للمعلومات عن systemd. يوجد أدناه قائمة روابط لبعض المواد الأكثر جودة حول هذا الموضوع. 



  • دليل عملي للنظام بواسطة مشروع Fedora.
  • ورقة غش من مشروع فيدورا ترسم خرائط لأوامر SystemV و systemd القديمة.
  • تفاصيل حول systemd ولماذا تم إنشاؤه.
  • مواد بالمعلومات والمشورة ، مخصصة للنظام د.
  • (Lennart Poettering), systemd. , 2010 2011, . systemd .
  • systemd.
  • systemd.




يمكن استخدام مؤقتات Systemd لإنجاز المهام نفسها التي تقوم بها وظائف cron. لكن systemd يمنحك مزيدًا من المرونة فيما يتعلق بتكوين التقويم والمؤقتات الرتيبة.



على الرغم من أن ملفات تكوين الخدمة التي نقوم بإنشائها أثناء تجاربنا يتم استدعاءها عادةً باستخدام أجهزة ضبط الوقت ، يمكنك استدعائها في أي وقت باستخدام أمر مثل systemctl start myMonitor.service. يمكن لمؤقت واحد بدء عدة مهام. يمكن أن يكون هذا ، على سبيل المثال ، نصوص Bash وأدوات Linux المساعدة. يمكن تكوين ملف تكوين الخدمة بحيث يتم تنفيذ نصوص متعددة عند استدعائه. يمكنك أيضًا تشغيل البرامج النصية بشكل منفصل.



إذا تحدثنا عن التعايش بين systemd و cron و at ، فأنا أريد أن أشير إلى أنني لم أر حتى الآن أي إشارات على أن cron أو at سيتم إهماله. آمل أن يستمر دعمهم ، لأنه على الأقل أسهل بكثير من استخدام systemd لجدولة المهام لمرة واحدة.



ما الذي تستخدمه؟ توقيت النظام أو وظائف كرون؟





More articles:


All Articles