Perintah itu bekerja di terminal Anda dan tidak menghasilkan apa pun pada pukul tiga pagi. cron tidak rusak. Ia menjalankan perintah Anda di lingkungan yang nyaris sama sekali tak menyerupai cangkang Anda, dan perbedaan itulah seluruh jawabannya.

Lihat apa yang terjadi

grep CRON /var/log/syslog | tail -20

Kalau tugas Anda sama sekali tidak ada di sana, cron memang tidak pernah mencoba. Kalau ada, cron sudah menjalankannya dan yang meleset adalah hal lain.

1. PATH nyaris kosong

Cangkang Anda tahu di mana php berada. cron tidak — PATH-nya biasanya hanya /usr/bin:/bin. Selalu gunakan jalur lengkapnya.

which php
# /usr/bin/php8.3

# in the crontab
0 3 * * * /usr/bin/php8.3 /var/www/site/cron.php

2. Keluarannya tidak ke mana-mana

Tugas tanpa pengalihan mengirim keluarannya ke surat yang belum diatur, sehingga galatnya lenyap. Kirimkan ke sebuah berkas, dan kegagalan berikutnya akan menjelaskan dirinya sendiri.

0 3 * * * /usr/bin/php8.3 /var/www/site/cron.php >> /var/log/site-cron.log 2>&1

3. Pengguna yang keliru

Tugas di crontab milik root menulis berkas yang dimiliki root, dan setelah itu server web tidak bisa mengubahnya. Taruhlah di crontab pengguna yang memiliki situs itu.

crontab -u youruser -l

4. Tanda persen

Di dalam crontab, % berarti baris baru. Format tanggal seperti +%Y-%m-%d diam-diam berubah menjadi tiga baris dan perintahnya patah. Loloskan tandanya: \%.

Ujilah sebagaimana cron akan menjalankannya

env -i /bin/sh -c "/usr/bin/php8.3 /var/www/site/cron.php"

Itu menjalankannya dengan lingkungan kosong, persis seperti yang dilakukan cron. Kalau gagal di sini, ia akan gagal juga pukul tiga.

cron WordPress bukanlah cron: ia berjalan saat halaman dimuat, jadi situs yang sepi tidak pernah menjalankan tugasnya. Matikan WP_CRON dan panggil wp-cron.php dari tugas cron yang sungguhan.