تمارين Kata في Linux بثلاثة مستويات مع الحلول

الأوامر والمخرج سوف يكون كما يلي:

$ pwd
/srv/app/releases
$ cd ../logs && pwd
/srv/app/logs
$ cd -
/srv/app/releases
$ cd /srv/app/logs
$ ls -laht
total 20K
drwxr-xr-x 2 root root 4.0K Oct  7 07:45 .
drwxr-xr-x 4 root root 4.0K Oct  7 07:41 ..
-rw-r--r-- 1 root root 1.9K Oct  6 10:06 access.log
-rw-r--r-- 1 root root 1.9K Oct  6 00:00 access.log.1
-rw-r--r-- 1 root root    0 Oct  6 00:00 .last-rotate
-rw-r--r-- 1 root root  394 Oct  5 00:00 access.log.2.gz
$ cd
$ pwd
/root

في الأوامر أعلاه لاحظ التالي:

• ../logs تعني اصعد مجلداً واحداً إلى /srv/app ثم ادخل logs، و&& تشغل pwd فقط إذا نجح الانتقال.
• cd - تطبع المجلد الذي رجعت إليه، وهي مفيدة جداً عندما تتنقل بين مجلد السجلات ومجلد الإعداد عشرات المرات.
• الخيار -a يظهر الملفات التي تبدأ بنقطة مثل .last-rotate، و-h يحول 1900 بايت إلى 1.9K، و-t يرتب بوقت التعديل الأحدث أولاً. وإذا كتبت -A بدل -a فسوف يختفي السطران . و...
• الملف .last-rotate جاء قبل access.log.2.gz لأن تاريخه أحدث، وليس بسبب اسمه.

للتفصيل: المسار المطلق والمسار النسبي والتنقل بين المجلدات في دليل سطر الأوامر.

$ mkdir -p /srv/shop/{src/{api,web},tests,docs}
$ find /srv/shop -type d | sort
/srv/shop
/srv/shop/docs
/srv/shop/src
/srv/shop/src/api
/srv/shop/src/web
/srv/shop/tests
$ echo /srv/shop/{src/{api,web},tests,docs}
/srv/shop/src/api /srv/shop/src/web /srv/shop/tests /srv/shop/docs
$ mkdir /srv/blog/posts
mkdir: cannot create directory ‘/srv/blog/posts’: No such file or directory

في الأوامر أعلاه لاحظ التالي:

• الأمر echo مع نفس الأقواس يريك ما سوف يصل إلى mkdir فعلاً، وهي عادة جيدة قبل أي أمر فيه توسيع، خصوصاً مع rm.
• الخيار -p ينشئ /srv/shop و/srv/shop/src تلقائياً، ولا يعطي خطأ إذا كان المجلد موجوداً، لذلك تجده في كل سكربت تجهيز.
• بدون -p يرفض mkdir إنشاء posts لأن الأب /srv/blog غير موجود، ويخرج برمز خروج 1.

للتفصيل: العمل مع الملفات والمجلدات في دليل سطر الأوامر، وقسم Brace Expansion في دليل bash.

المالك deploy له rwx أي 7، والمجموعة www-data لها r-x أي 5، والآخرون ليس لهم شيء أي 0، فالصلاحيات 750. وهذا يعني أن deploy يقرأ ويعدل ويشغل، وwww-data يقرأ ويشغل ولا يعدل، وpostgres لا يستطيع حتى القراءة. والتحقق كما يلي:

$ ls -l backup.sh
-rwxr-x--- 1 deploy www-data 47 Oct  6 10:00 backup.sh
$ stat -c '%A %a %U %G' backup.sh
-rwxr-x--- 750 deploy www-data
$ su deploy -c ./backup.sh
backup started by deploy
$ su -s /bin/bash www-data -c ./backup.sh
backup started by www-data
$ su -s /bin/bash www-data -c 'echo "# edit" >> backup.sh'
bash: line 1: backup.sh: Permission denied
$ su postgres -c 'cat backup.sh'
cat: backup.sh: Permission denied

في المخرج أعلاه لاحظ التالي:

• الأمر stat -c '%a' يعطيك الرقم مباشرة، فلا تحتاج أن تحسبه في كل مرة على السيرفر، ولكن احسبه بيدك في التمرين.
• السكربت يحتاج r مع x لكي يعمل، لأن bash يقرأ الملف ليشغله، ولذلك صلاحية --x وحدها لا تكفي للسكربت وتكفي للبرنامج المترجم Binary.
• النواة Kernel تفحص جزءاً واحداً فقط: إذا كنت المالك طبقت صلاحيات المالك، وإلا إذا كنت في المجموعة طبقت صلاحيات المجموعة، وإلا طبقت صلاحيات الآخرين.

للتفصيل: قراءة سطر ls -l وترتيب الفحص في النواة في دليل الصلاحيات.

$ wc -l access.log
20 access.log
$ grep -c ' 401 ' access.log
4
$ awk '$9 == 401' access.log | wc -l
4
$ grep -c 'login' access.log
7
$ grep -c '/login ' access.log
6
$ awk '{print $1}' access.log | sort -u | wc -l
4

في المخرج أعلاه لاحظ التالي:

• السؤال الثالث فيه الفخ: grep -c 'login' أعطى 7 لأنه عد أيضاً الطلب إلى /wp-login.php، وهو طلب من برنامج يبحث عن WordPress وليس محاولة دخول إلى تطبيقك. والإجابة الصحيحة 6، وتحصل عليها بنص أدق فيه المسافة بعد المسار، أو بشرط على الحقل نفسه awk '$7 == "/login"'.
• المسافتان حول 401 في ' 401 ' تمنعان أن يطابق grep رقماً مثل 4012 في حقل الحجم، والشرط $9 == 401 في awk أدق لأنه يقارن الحقل التاسع فقط.
• sort -u يرتب ويحذف المكرر في خطوة واحدة، وهو نفس sort | uniq.

للتفصيل: القنوات الثلاث والتوجيه والأنابيب في دليل سطر الأوامر، وإذا أردت التعمق في أنماط البحث فدليل التعبيرات النمطية Regex.

$ ls /srv/app/logs/access.log /srv/app/missing.log > out.txt 2> err.txt
$ cat out.txt
/srv/app/logs/access.log
$ cat err.txt
ls: cannot access '/srv/app/missing.log': No such file or directory
$ ls /srv/app/logs/access.log /srv/app/missing.log > all.txt 2>&1
$ cat all.txt
ls: cannot access '/srv/app/missing.log': No such file or directory
/srv/app/logs/access.log
$ ls /srv/app/logs/access.log /srv/app/missing.log 2>&1 > wrong.txt
ls: cannot access '/srv/app/missing.log': No such file or directory
$ cat wrong.txt
/srv/app/logs/access.log
$ ls /srv/app/missing.log 2> /dev/null; echo "exit=$?"
exit=2

في المخرج أعلاه لاحظ التالي:

• في > all.txt 2>&1 يتوجه 1 إلى الملف أولاً، ثم يتوجه 2 إلى نفس المكان، فيدخل الاثنان في الملف.
• في الترتيب المعكوس 2>&1 > wrong.txt يتوجه 2 إلى حيث كان 1 في تلك اللحظة، أي الشاشة، ثم يتوجه 1 وحده إلى الملف، لذلك ظهر الخطأ على الشاشة وبقي خارج wrong.txt. وهذا خطأ شائع في سطور cron، فتظن أنك تحفظ الأخطاء وهي تضيع.
• سطر الخطأ جاء قبل السطر الناجح في all.txt لأن ls يطبع الأخطاء فوراً ثم يطبع النتائج المرتبة في النهاية.
• إخفاء الخطأ في /dev/null لا يغير رمز الخروج، فما زال 2، والسكربت الذي يفحص $? سوف يعرف أن الأمر فشل.

للتفصيل: القنوات الثلاث والتوجيه والأنابيب في دليل سطر الأوامر، وقسم Redirections في دليل bash الذي يشرح هذا الترتيب بنفس المثال.

$ grep -q '/api/orders' access.log; echo $?
0
$ grep -q '/admin' access.log; echo $?
1
$ grep -q '/admin' access.lg; echo $?
grep: access.lg: No such file or directory
2
$ grep -q ' 504 ' access.log && echo "found 504" || echo "no 504"
found 504
$ grep -q '/admin' access.log && echo "found admin" || echo "no admin"
no admin

تقول صفحة grep في الدليل إن رمز الخروج 0 إذا وجد سطراً، و1 إذا لم يجد، و2 إذا حدث خطأ. والفرق بين 1 و2 مهم في السكربت: «لم أجد كلمة error في السجل» نتيجة جيدة، و«لم أستطع فتح السجل» مشكلة يجب أن توقف السكربت، فإذا عاملت الاثنين على أنهما «ليس صفراً» فسوف تخلط بينهما. ولاحظ أن A && B || C ليست if كاملة، فإذا فشل B نفسه فسوف يعمل C أيضاً، وهي مقبولة هنا لأن echo لا يفشل.

للتفصيل: رمز الخروج Exit Code في دليل سطر الأوامر.

أولاً لنرى ماذا يحدث دون sort، ثم الحل الصحيح:

$ awk '{print $1}' access.log | uniq -c
      1 203.0.113.7
      1 198.51.100.23
      1 203.0.113.7
      1 192.0.2.55
      1 203.0.113.7
      1 192.0.2.55
      3 198.51.100.23
      1 203.0.113.7
      1 192.0.2.55
      2 203.0.113.40
      1 198.51.100.23
      1 192.0.2.55
      1 203.0.113.7
      1 198.51.100.23
      1 203.0.113.40
      1 203.0.113.7
      1 198.51.100.23
$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -3
      7 198.51.100.23
      6 203.0.113.7
      4 192.0.2.55
$ awk '{print $9}' access.log | sort | uniq -c | sort -rn
      7 200
      4 401
      3 500
      2 404
      2 302
      1 504
      1 502

في المخرج أعلاه لاحظ التالي:

• دون sort ظهر العنوان 198.51.100.23 في خمسة أسطر منفصلة، لأن uniq يقارن كل سطر بالسطر الذي قبله فقط، فالرقم 3 الذي ظهر هو الطلبات الثلاثة المتتالية فقط وليس المجموع.
• sort -rn يرتب بالأرقام -n وبالعكس -r، ودون -n سوف يرتب النص حرفاً حرفاً فيضع 10 قبل 9.
• العنوان الأول أرسل 7 طلبات، منها أربع محاولات دخول فاشلة 401 وطلب إلى /.env وطلب إلى /wp-login.php، وهذا شكل من يبحث عن ثغرات أو يجرب كلمات مرور، وهو ما تبحث عنه في السجل الحقيقي.

للتفصيل: الأنابيب Pipes في دليل سطر الأوامر، وأسئلة لا يجيب عنها السجل النصي في دليل السجلات.

$ awk '$9 >= 500 {print $9, $7}' access.log | sort | uniq -c | sort -rn
      3 500 /api/orders
      1 504 /api/reports
      1 502 /api/orders
$ awk '$9 >= 500 {n++} END {printf "%d of %d = %.1f%%\n", n, NR, 100*n/NR}' access.log
5 of 20 = 25.0%
$ awk '{bytes[$1] += $10} END {for (ip in bytes) print bytes[ip], ip}' access.log | sort -rn
51512 203.0.113.40
17408 203.0.113.7
2866 198.51.100.23
941 192.0.2.55
$ awk '$4 >= "[06/Oct/2026:10:01:00" && $4 < "[06/Oct/2026:10:03:00"' access.log | wc -l
6

في الأوامر أعلاه لاحظ التالي:

• المسار /api/orders وحده فيه 4 من 5 أخطاء، وهذا أول مكان تبحث فيه، ولاحظ أن نفس المسار نجح مرة واحدة برمز 200، فالمشكلة ليست أن المسار غير موجود.
• %% في printf تطبع علامة النسبة نفسها، وfor (ip in bytes) لا يضمن أي ترتيب، لذلك رتبنا بعده بالأمر sort -rn.
• مقارنة الوقت كنص تعمل هنا لأن كل الأسطر في نفس اليوم ونفس الشهر، ولكنها تخطئ إذا امتد السجل على أكثر من شهر، لأن Oct تأتي قبل Sep في ترتيب الحروف. وفي هذه الحالة حول الوقت إلى رقم، أو اكتب السجل بصيغة ISO 8601 من البداية كما شرحنا في دليل السجلات.
• هذا التمرين بالضبط هو السبب الذي يجعلنا ننصح بالسجلات المنظمة Structured Logs: كل هذه الأسئلة تصبح استعلاماً واحداً على حقول لها أسماء.

للتفصيل: السجلات المنظمة Structured Logs في دليل السجلات، ودليل gawk الرسمي للغة awk.

الحل البسيط s/8080/8081/ يغير سطرين وليس سطراً واحداً، وهذا ما يكشفه diff قبل أن تكتب على الملف:

$ sed 's/8080/8081/' app.conf | diff app.conf -
2c2
< port=8080
---
> port=8081
5c5
< payments_url=http://127.0.0.1:8080/pay
---
> payments_url=http://127.0.0.1:8081/pay
$ sed -i.bak -e 's/^port=8080$/port=8081/' -e 's/^debug=true$/debug=false/' app.conf
$ diff app.conf.bak app.conf
2,3c2,3
< port=8080
< debug=true
---
> port=8081
> debug=false
$ grep -n '^port=' app.conf
2:port=8081

في الأوامر أعلاه لاحظ التالي:

• النمط ^port=8080$ يطابق السطر كاملاً فقط، فلا يلمس payments_url الذي فيه نفس الرقم، ولا السطر #port=9090 لأنه يبدأ بالعلامة #.
• تشغيل sed دون -i وتمرير مخرجه إلى diff هو طريقة آمنة لترى التغيير قبل تنفيذه، و- في diff تعني اقرأ من الأنبوب.
• -i.bak في GNU sed يكتب النسخة الاحتياطية app.conf.bak، وفي sed الخاص بأنظمة BSD وmacOS تكتب -i '' بصيغة مختلفة، فانتبه إذا نسخت السكربت بين الأنظمة.

للتفصيل: دليل GNU sed الرسمي، ودليل التعبيرات النمطية Regex.

$ ls -ld /srv/reports /srv/reports/today.txt
drwxr--r-- 2 root root 4096 Oct  7 07:48 /srv/reports
-rw-r--r-- 1 root root   12 Oct  7 07:48 /srv/reports/today.txt
$ su postgres -c 'ls /srv/reports'
today.txt
$ su postgres -c 'cat /srv/reports/today.txt'
cat: /srv/reports/today.txt: Permission denied
$ su postgres -c 'ls -l /srv/reports'
ls: cannot access '/srv/reports/today.txt': Permission denied
total 0
-????????? ? ? ? ?            ? today.txt
$ chmod 755 /srv/reports
$ su postgres -c 'cat /srv/reports/today.txt'
orders: 128
$ chmod 711 /srv/reports
$ su postgres -c 'ls /srv/reports'
ls: cannot open directory '/srv/reports': Permission denied
$ su postgres -c 'cat /srv/reports/today.txt'
orders: 128

في المخرج أعلاه لاحظ التالي:

• المجلد drwxr--r-- يعطي الآخرين r فقط، فيقرؤون قائمة الأسماء ولكنهم لا يستطيعون الوصول إلى الملف نفسه ولا إلى معلوماته، لذلك ظهرت علامات الاستفهام في ls -l.
• صلاحية الملف وحدها لا تكفي، فالنواة تفحص x على كل مجلد في المسار من / إلى الملف قبل أن تنظر إلى صلاحية الملف.
• مع 755 يرى postgres الأسماء ويقرأ الملف، ومع 711 يقرأ الملف إذا عرف اسمه ولكنه لا يستطيع أن يعرض محتوى المجلد. والإصلاح الصحيح أن تضيف x فقط chmod o+x أو تختار 755، ولا تقم بتغيير الصلاحيات إلى 777، والسبب أنها تسمح لأي مستخدم بحذف الملفات وإضافة ملفات جديدة في المجلد.

للتفصيل: r وw وx على المجلد ولماذا لا تحل chmod 777 أي مشكلة في دليل الصلاحيات.

$ du -sh /srv/data/* | sort -h
4.0K	/srv/data/vm
4.0M	/srv/data/cache
31M	/srv/data/uploads
201M	/srv/data/backups
$ find /srv/data -type f -size +50M -exec ls -lh {} +
-rw-r--r-- 1 root root 120M Oct  7 07:48 /srv/data/backups/db-2026-10-05.sql.gz
-rw-r--r-- 1 root root  80M Oct  7 07:48 /srv/data/backups/db-2026-10-06.sql.gz
-rw-r--r-- 1 root root 2.0G Oct  7 07:48 /srv/data/vm/disk.img
$ du -h /srv/data/vm/disk.img
0	/srv/data/vm/disk.img
$ du -h --apparent-size /srv/data/vm/disk.img
2.0G	/srv/data/vm/disk.img

في المخرج أعلاه لاحظ التالي:

• النسخ الاحتياطية هي التي تأخذ المساحة، وsort -h رتب 4.0M قبل 31M بشكل صحيح، بينما sort -n كان سيضع 201M قبل 31M لأنه لا يفهم الوحدات.
• truncate -s 2G أنشأ ملفاً متناثراً Sparse File: حجمه الظاهري 2G كما يقول ls وfind، ولكن النواة لم تحجز له أي مساحة على القرص لأنه لم يكتب فيه شيء، لذلك du يقول 0. وهذا شائع في أقراص الآلات الافتراضية وملفات بعض قواعد البيانات.
• الدرس أن ls يجيب عن سؤال «كم حجم الملف؟» وdu يجيب عن سؤال «كم يأخذ من القرص؟»، وعندما يمتلئ القرص فالسؤال الثاني هو المهم. ولكن انتبه إلى أن الملف المتناثر قد يكبر فعلاً على القرص عندما تكتب فيه الآلة الافتراضية، أو عندما تنسخه بأداة لا تحافظ على الفراغات.

للتفصيل: البحث عن الملفات ومعرفة المساحة في دليل سطر الأوامر، والمساحة ممتلئة في دليل أداء السيرفر.

$ pgrep -af 'worker.sh|stuck.sh'
539 /bin/bash ./worker.sh
543 /bin/bash ./stuck.sh
$ pkill -TERM -f worker.sh; sleep 2; cat /tmp/worker.log /tmp/worker.state
08:27:27 worker: started as PID 539
08:27:37 worker: got SIGTERM, saving state
saved
$ pkill -TERM -f stuck.sh; sleep 3; pgrep -af stuck.sh
543 /bin/bash ./stuck.sh
$ pkill -KILL -f stuck.sh; sleep 1; pgrep -af stuck.sh; echo "pgrep exit=$?"
pgrep exit=1

في المخرج أعلاه لاحظ التالي:

• worker.sh استلم SIGTERM فنفذ ال trap: كتب السطر وحفظ الحالة في /tmp/worker.state ثم خرج، وهذا بالضبط ما يفعله أي تطبيق جيد يغلق اتصالاته ويكمل الطلبات الجارية قبل أن يخرج.
• stuck.sh بقي حياً بعد SIGTERM لأنه يتجاهله، فاستخدمنا KILL، ورمز خروج pgrep صار 1 أي لم يجد شيئاً. ولو بدأت ب kill -9 مع worker.sh لما حفظ حالته أبداً، لأن KILL لا يعطي العملية أي فرصة لتنفذ شيئاً.
• انتبه إلى أن -f يطابق أي جزء من سطر الأمر، فإذا كان هناك Shell أو محرر مفتوح وفي سطر أمره نفس الكلمة فسوف يصله نفس الإشارة، لذلك شغل pgrep -af أولاً وانظر إلى القائمة قبل pkill.
• وهذا نفس ما يفعله docker stop: يرسل SIGTERM وينتظر 10 ثوان افتراضياً ثم يرسل SIGKILL.

للتفصيل: الإشارات وإيقاف العمليات بالأمر kill ولماذا لا تبدأ ب kill -9؟ في دليل سطر الأوامر.

$ ./nightly.sh; echo "exit=$?"
cat: /srv/app/data/orders.db: No such file or directory
backup done: -rw-r--r-- 1 root root 20 Oct  7 07:55 orders-2026-10-07.db.gz
exit=0
$ ls -l /srv/backups
total 4
-rw-r--r-- 1 root root 20 Oct  7 07:55 orders-2026-10-07.db.gz
$ false | true; echo "exit=$?"
exit=0
$ cat /nope | gzip > /dev/null; echo "PIPESTATUS=${PIPESTATUS[*]}"
cat: /nope: No such file or directory
PIPESTATUS=1 0
$ sed -i '2i set -euo pipefail' nightly.sh
$ head -3 nightly.sh
#!/bin/bash
set -euo pipefail
BACKUP_DIR=/srv/backups
$ ./nightly.sh; echo "exit=$?"
cat: /srv/app/data/orders.db: No such file or directory
exit=1

في المخرج أعلاه لاحظ التالي:

• cat فشل لأن ملف قاعدة البيانات غير موجود، ولكن gzip نجح في ضغط «لا شيء» وكتب ملفاً حجمه 20 بايت، وهو ملف gzip صالح لا يحتوي شيئاً، ثم طبع echo رسالة النجاح، ورمز خروج السكربت هو رمز آخر أمر فيه أي 0. والنتيجة نسخة احتياطية فارغة كل ليلة والمراقبة خضراء، وأنت تكتشف ذلك يوم تحتاج النسخة.
• pipefail تجعل رمز الأنبوب هو رمز آخر أمر فشل فيه، و-e توقف السكربت عند أول أمر يفشل، و-u تعتبر المتغير غير المعرف خطأ بدل أن يصبح نصاً فارغاً.
• بعد الإصلاح توقف السكربت قبل رسالة النجاح وخرج ب 1، ولكن لاحظ أن الملف الفارغ ما زال يكتب، لأن ال Shell يفتح الملف للتوجيه > قبل أن يبدأ الأمر. والحل الكامل أن تكتب إلى ملف مؤقت ثم تنقله بالأمر mv بعد النجاح، وأن تفحص حجم النسخة أو تختبر استرجاعها.

للتفصيل: رمز الخروج Exit Code وrm مع متغير فارغ في دليل سطر الأوامر، وقسمي Pipelines وThe Set Builtin في دليل bash.

$ ls -lh debug.log
-rw-r--r-- 1 root root 1.0G Oct  7 08:00 debug.log
$ df -m --output=used,avail /
 Used  Avail
88447 890128
$ rm debug.log
$ df -m --output=used,avail /
 Used  Avail
88447 890128
$ du -sh /srv/app/logs
16K	/srv/app/logs
$ find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null
/proc/116/fd/3 -> /srv/app/logs/debug.log (deleted)
/proc/84/fd/3 -> /srv/app/logs/debug.log (deleted)
$ ps -o pid,cmd -p $(pgrep -f app.sh)
  PID CMD
   84 /bin/bash /srv/ops/app.sh
$ : > /proc/$(pgrep -f app.sh)/fd/3
$ df -m --output=used,avail /
 Used  Avail
87425 891149

في المخرج أعلاه لاحظ التالي:

• بعد rm بقي Used كما هو، بينما du يقول إن المجلد فيه 16K فقط، وهذا الفرق بين df وdu هو العلامة المعروفة لملف محذوف ما زال مفتوحاً، لأن du يعد الأسماء الموجودة وdf يعد المساحة المحجوزة في نظام الملفات.
• ظهرت عمليتان: 84 هي السكربت نفسه، و116 هي عملية sleep 1 التي كانت تعمل في تلك اللحظة، لأن العملية الابن Child Process ترث الملفات المفتوحة من أبيها، وهذا سبب آخر لكي تنظر إلى القائمة قبل أن تقرر.
• : > /proc/84/fd/3 يفرغ الملف من خلال الرابط الذي ما زالت العملية تملكه، فرجعت المساحة المستخدمة إلى 87425 أي تحرر قرابة 1G دون أن يتوقف التطبيق. والحل الآخر أن تعيد تشغيل التطبيق فيغلق الملف، والحل الصحيح على المدى الطويل أن تستخدم تدوير السجلات Log Rotation الذي يبلغ التطبيق بإعادة فتح الملف بدل أن تحذف الملف بيدك.
• الأرقام في df هنا من قرص ال VM الخاص ب Docker Desktop، لذلك قد تتغير قليلاً بسبب Containers أخرى، والمهم هو الفرق.

للتفصيل: ملف محذوف ما زال يحجز المساحة في دليل أداء السيرفر، والملفات النصية وأداة التدوير logrotate في دليل السجلات.

بعد دقيقة:

$ cat /tmp/report.log
/bin/sh: 1: report-tool: not found
$ cat /tmp/today.txt
cat: /tmp/today.txt: No such file or directory
$ grep -E '^(PATH|SHELL|HOME)=' /tmp/cron-env.txt
HOME=/home/deploy
PATH=/usr/bin:/bin
SHELL=/bin/sh

السبب الأول أن cron يشغل الأوامر ببيئة صغيرة جداً، فقيمة PATH فيها /usr/bin:/bin فقط، بينما الأداة في /usr/local/bin، والطرفية التي جربت منها لها PATH أطول. والسبب الثاني أن cron يعامل العلامة % معاملة خاصة، فكما تقول صفحة crontab(5) في Debian: علامات النسبة في الأمر تتحول إلى أسطر جديدة إلا إذا سبقتها شرطة مائلة عكسية، وكل ما بعد أول % يرسل إلى الأمر كمدخل stdin. فالأمر الذي وصل إلى ال Shell هو date + وحده بدون التوجيه إلى الملف، ولذلك لم ينشأ الملف ولم تظهر أي رسالة في أي ملف. والإصلاح كما يلي:

$ crontab -l -u deploy
PATH=/usr/local/bin:/usr/bin:/bin
* * * * * report-tool >> /tmp/report.log 2>&1
* * * * * date +\%F > /tmp/today.txt 2>&1
$ cat /tmp/report.log
08:04:01 report generated
$ cat /tmp/today.txt
2026-10-07

في الإصلاح أعلاه لاحظ التالي:

• السطر PATH=… في أول ملف crontab يضبط البيئة لكل المهام بعده، والبديل أن تكتب المسار الكامل /usr/local/bin/report-tool في كل مهمة، وهو الأوضح عندما تقرأ الملف بعد سنة.
• \%F تمنع cron من تحويل العلامة، فتصل %F كما هي إلى date. والأفضل في الأوامر الطويلة أن تضعها في سكربت وتكتب في crontab اسم السكربت فقط.
• أضف دائماً >> ملف 2>&1 لكل مهمة، فلولا التوجيه في المهمة الأولى لما رأينا رسالة not found، لأن cron يرسل المخرج بالبريد، ولا يوجد خادم بريد في أغلب السيرفرات.

للتفصيل: صفحة crontab(5) في Debian، وبطء في نفس الساعة كل يوم في دليل استكشاف الأخطاء.

المحاولة الأولى فيها خطأ صغير متعمد ليرى كيف يحميك visudo:

$ echo 'deploy ALL=(root) NOPASSWD /usr/local/bin/deploy-app' > /tmp/deploy.sudoers
$ visudo -cf /tmp/deploy.sudoers
/tmp/deploy.sudoers:1:53: syntax error
deploy ALL=(root) NOPASSWD /usr/local/bin/deploy-app
                                                    ^
$ echo 'deploy ALL=(root) NOPASSWD: /usr/local/bin/deploy-app' > /tmp/deploy.sudoers
$ visudo -cf /tmp/deploy.sudoers
/tmp/deploy.sudoers: parsed OK
$ install -m 0440 -o root -g root /tmp/deploy.sudoers /etc/sudoers.d/deploy
$ visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/deploy: parsed OK
$ sudo -l -U deploy
Matching Defaults entries for deploy on kata:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User deploy may run the following commands on kata:
    (root) NOPASSWD: /usr/local/bin/deploy-app
$ su deploy -c 'sudo -n /usr/local/bin/deploy-app'
deploying as root
$ su deploy -c 'sudo -n cat /etc/shadow'
sudo: a password is required

في المخرج أعلاه لاحظ التالي:

• نقطتان ناقصتان بعد NOPASSWD كانتا كافيتين لخطأ في الصيغة، ولو كتبت الملف مباشرة في /etc/sudoers.d لتوقف sudo كله على السيرفر حتى تصلحه، وقد لا يكون لديك حساب root آخر تدخل به. لذلك افحص بالأمر visudo -cf أولاً، ثم انسخ الملف بالأمر install بمالك root وصلاحية 0440.
• القاعدة تحدد المسار الكامل للأمر، فلا يستطيع deploy أن يشغل غيره، والرسالة a password is required تعني أن القاعدة لا تغطي cat وأن sudo طلب كلمة مرور، ومع -n فشل بدل أن ينتظر.
• إذا كان deploy مالك السكربت أو يستطيع الكتابة فيه، فسوف يكتب فيه أي أمر ثم يشغله بصلاحيات root، وتصبح القاعدة «أمر واحد» بلا معنى. لذلك الأمر المسموح وكل المجلدات في مساره يجب أن يملكها root ولا يكتب فيها غيره.

للتفصيل: sudo أم الدخول بحساب root؟ في دليل الصلاحيات، وصفحتي sudoers وvisudo الرسميتين.

$ systemd-analyze verify ./shop.service; echo "exit=$?"
/root/units/shop.service:10: Failed to parse Restart=onfailure, ignoring: Invalid argument
shop.service: Command node is not executable: No such file or directory
exit=1
$ sed -i -e 's/^Restart=onfailure$/Restart=on-failure/' -e 's|^ExecStart=node server.js$|ExecStart=/usr/bin/node /srv/shop/server.js|' shop.service
$ grep -E '^(ExecStart|Restart)=' shop.service
ExecStart=/usr/bin/node /srv/shop/server.js
Restart=on-failure
$ systemd-analyze verify ./shop.service; echo "exit=$?"
exit=0

في المخرج أعلاه لاحظ التالي:

• الخطأ الأهم هو Restart=onfailure: القيمة الصحيحة on-failure بشرطة، وsystemd لا يرفض تشغيل الخدمة بسببها، وإنما يكتب تحذيراً و«يتجاهل» السطر، فتعمل الخدمة بالقيمة الافتراضية Restart=no ولا تعود بعد أن تتعطل. وهذا أخطر من الخطأ الذي يوقف كل شيء، لأنك لن تلاحظه حتى أول عطل.
• الخطأ الثاني أن node لم يكن مثبتاً عندما فحصنا أول مرة، فقالت الأداة إنه غير قابل للتشغيل. وتقول صفحة systemd.service إن الأمر الذي ليس مساراً كاملاً يبحث عنه systemd في مسارات ثابتة مثل /usr/local/bin و/usr/bin، ونحن نفضل المسار الكامل لأنه يجعل الملف واضحاً ولا يعتمد على مكان التثبيت. وبعد تثبيت nodejs من Debian وتصحيح السطرين رجع verify بالرمز 0. ولاحظ أن verify لا يفحص وجود /srv/shop/server.js نفسه.

أما الجزء الثاني فلا يعمل داخل Container، لأن systemd ليس العملية رقم 1 فيه، وهذا ما رأيناه عندما جربنا:

$ systemctl status shop
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to system scope bus via local transport: Host is down
$ journalctl -u shop -n 5 --no-pager
No journal files were found.
-- No entries --

لذلك الإجابة التالية من صفحتي journalctl وsystemd-analyze وليست من مختبرنا:

sudo cp shop.service /etc/systemd/system/ && sudo systemctl daemon-reload
sudo systemctl enable --now shop
systemctl status shop
journalctl -u shop -b -n 50 --no-pager
journalctl -u shop -p err --since "1 hour ago"

و-u تحدد الوحدة Unit، و-b تعني منذ آخر إقلاع، و-n 50 آخر 50 سطراً، و-p err الأخطاء وما هو أخطر منها، و--since تقبل وقتاً نسبياً مثل "1 hour ago". ولا تنس daemon-reload بعد كل تعديل على ملف الوحدة، وإلا فسوف يعمل systemd بالنسخة القديمة.

للتفصيل: في systemd: journald في دليل السجلات.