Mengapa skrip crontab tidak berfungsi?

Seringkali, crontabskrip tidak dieksekusi sesuai jadwal atau seperti yang diharapkan. Ada banyak alasan untuk itu:

1. notasi crontab yang salah
2. masalah izin
3. variabel lingkungan

Wiki komunitas ini bertujuan untuk mengumpulkan alasan utama agar crontabskrip tidak dieksekusi seperti yang diharapkan. Tuliskan setiap alasan dalam jawaban yang terpisah.

Harap sertakan satu alasan per jawaban - detail tentang mengapa itu tidak dijalankan - dan perbaiki karena satu alasan itu.

Harap tulis hanya masalah spesifik-cron, mis. Perintah yang dijalankan seperti yang diharapkan dari shell tetapi dieksekusi secara keliru oleh cron.

Lingkungan yang berbeda

Cron melewati serangkaian variabel lingkungan minimal ke pekerjaan Anda. Untuk melihat perbedaannya, tambahkan pekerjaan tiruan seperti ini:

* * * * * env> /tmp/env.output

Tunggu /tmp/env.outputhingga dibuat, lalu hapus pekerjaan itu lagi. Sekarang bandingkan konten /tmp/env.outputdengan output envrun di terminal reguler Anda.

"Gotcha" yang umum di sini adalah PATHvariabel lingkungan yang berbeda. Mungkin skrip cron Anda menggunakan perintah somecommandditemukan di /opt/someApp/bin, yang telah Anda tambahkan ke PATHdalam /etc/environment? cron mengabaikan PATHdari file itu, jadi runnning somecommanddari skrip Anda akan gagal ketika dijalankan dengan cron, tetapi bekerja ketika dijalankan di terminal. Ini perlu dicatat bahwa variabel dari /etc/environmentakan diteruskan ke pekerjaan cron, hanya saja tidak variabel cron khusus set sendiri, seperti PATH.

Untuk menyiasatinya, cukup atur PATHvariabel Anda sendiri di bagian atas skrip. Misalnya

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Beberapa lebih suka menggunakan jalur absolut untuk semua perintah saja. Saya merekomendasikan hal itu. Pertimbangkan apa yang terjadi jika Anda ingin menjalankan skrip Anda pada sistem yang berbeda, dan pada sistem itu, perintahnya ada /opt/someAppv2.2/bin. Anda harus membaca seluruh skrip untuk menggantikannya, alih /opt/someApp/bin- /opt/someAppv2.2/binalih hanya melakukan edit kecil pada baris pertama skrip.

Anda juga dapat mengatur variabel PATH dalam file crontab, yang akan berlaku untuk semua pekerjaan cron. Misalnya

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

Gotcha teratas saya: Jika Anda lupa menambahkan baris baru di akhir crontabfile. Dengan kata lain, file crontab harus diakhiri dengan baris kosong.

Di bawah ini adalah bagian yang relevan di halaman manual untuk masalah ini ( man crontabkemudian lewati sampai akhir):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Daemon Cron tidak berjalan. Saya benar-benar mengacaukan ini beberapa bulan yang lalu.

Tipe:

pgrep cron 

Jika Anda tidak melihat nomor, maka cron tidak berjalan. sudo /etc/init.d/cron startdapat digunakan untuk memulai cron.

EDIT: Daripada menggunakan skrip init melalui /etc/init.d, gunakan utilitas layanan, mis

sudo service cron start

EDIT: Anda juga dapat menggunakan systemctl di Linux modern, mis

sudo systemctl start cron

Script nama file di cron.d/, cron.daily/, cron.hourly/, dll, harus tidak mengandung titik ( .), jika tidak menjalankan-bagian akan melewatkan mereka.

Lihat run-parts (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Jadi, jika Anda memiliki skrip cron backup.sh, analyze-logs.pldalam cron.daily/direktori, sebaiknya hapus nama ekstensi.

Dalam banyak lingkungan cron mengeksekusi perintah menggunakan sh, sementara banyak orang menganggap itu akan digunakan bash.

Saran untuk menguji atau memperbaiki ini untuk perintah yang gagal:

• Coba jalankan perintah shuntuk melihat apakah itu berfungsi:

  sh -c "mycommand"
  

• Bungkus perintah dalam subshell bash untuk memastikan itu dijalankan di bash:

  bash -c "mybashcommand"
  

• Beri tahu cron untuk menjalankan semua perintah dalam bash dengan mengatur shell di bagian atas crontab Anda:

  SHELL=/bin/bash
  

• Jika perintahnya adalah skrip, pastikan skrip berisi shebang:

  #!/bin/bash
  

Saya memiliki beberapa masalah dengan zona waktu. Cron berjalan dengan zona waktu instalasi baru. Solusinya adalah me-restart cron:

sudo service cron restart

Path absolut harus digunakan untuk skrip:

Misalnya, /bin/grepharus digunakan daripada grep:

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Dari pada:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Ini sangat sulit, karena perintah yang sama akan berfungsi ketika dijalankan dari shell. Alasannya adalah bahwa crontidak memiliki PATHvariabel lingkungan yang sama dengan pengguna.

Jika perintah crontab Anda memiliki %simbol di dalamnya, cron mencoba menafsirkannya. Jadi, jika Anda menggunakan perintah dengan %di dalamnya (seperti spesifikasi format ke perintah tanggal), Anda harus menghindarinya.

Itu dan Gotcha baik lainnya di sini:
http://www.pantz.org/software/cron/croninfo.html

Cron memanggil skrip yang tidak dapat dieksekusi.

Dengan menjalankan chmod +x /path/to/scripskrip menjadi executable dan harus menyelesaikan masalah ini.

Mungkin juga kata sandi pengguna telah kedaluwarsa. Bahkan kata sandi root dapat kedaluwarsa. Anda dapat tail -f /var/log/cron.logdan Anda akan melihat cron gagal dengan kata sandi kedaluwarsa. Anda dapat mengatur kata sandi agar tidak pernah kedaluwarsa dengan melakukan ini:passwd -x -1 <username>

Di beberapa sistem (Debian, Ubuntu) logging untuk cron tidak diaktifkan secara default. Di /etc/rsyslog.conf atau /etc/rsyslog.d/50-default.conf baris:

# cron.*                          /var/log/cron.log

harus diedit ( sudo nano /etc/rsyslog.conf) dihapus komentarnya untuk:

cron.*                          /var/log/cron.log

Setelah itu, Anda harus memulai ulang rsyslog via

/etc/init.d/rsyslog restart

atau

service rsyslog restart 

Sumber: Aktifkan pencatatan crontab di Debian Linux

Dalam beberapa sistem (Ubuntu) file logging yang terpisah untuk cron tidak diaktifkan secara default, tetapi cron log terkait muncul dalam file syslog. Seseorang dapat menggunakan

cat /var/log/syslog | grep cron -i

untuk melihat pesan terkait cron.

Jika cronjob Anda memanggil aplikasi GUI, Anda perlu memberi tahu mereka TAMPILAN apa yang harus mereka gunakan.

Contoh: Peluncuran Firefox dengan cron.

Script Anda harus mengandung export DISPLAY=:0suatu tempat.

Masalah izin cukup umum, saya khawatir.

Perhatikan bahwa solusi umum adalah untuk mengeksekusi semuanya menggunakan crontab root, yang terkadang merupakan Ide yang Benar-benar Buruk. Menetapkan izin yang tepat jelas merupakan masalah yang sebagian besar diabaikan.

Izin tabel cron tidak aman

Tabel cron ditolak jika izinnya tidak aman

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

Masalahnya diselesaikan dengan

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

Skrip peka terhadap lokasi. Ini terkait dengan selalu menggunakan jalur absolut dalam skrip, tetapi tidak persis sama. Pekerjaan cron Anda mungkin perlu ke cddirektori tertentu sebelum menjalankan, mis. Tugas rake pada aplikasi Rails mungkin perlu berada di root aplikasi agar Rake menemukan tugas yang benar, belum lagi konfigurasi database yang sesuai, dll.

Jadi entri crontab dari

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

akan lebih baik

23 3 * * * cd / var / www / produksi / saat ini && / usr / bin / rake db: session_purge RAILS_ENV = produksi

Atau, untuk membuat entri crontab lebih sederhana dan tidak rapuh:

23 3 * * * /home/<user>/scripts/session-purge.sh

dengan kode berikut di /home/<user>/scripts/session-purge.sh:

cd / var / www / produksi / saat ini
/ usr / bin / rake db: session_purge RAILS_ENV = produksi

Spesifikasi Crontab yang berfungsi di masa lalu dapat rusak ketika dipindahkan dari satu file crontab ke yang lain. Terkadang alasannya adalah Anda telah memindahkan spek dari file sistem crontab ke file pengguna crontab atau sebaliknya.

Format spesifikasi pekerjaan cron berbeda antara file crontab pengguna (/ var / spool / cron / nama pengguna atau / var / spool / cron / crontab / nama pengguna) dan crontab sistem ( /etc/crontabdan file-file di dalamnya /etc/cron.d).

Sistem crontab memiliki bidang 'pengguna' tambahan tepat sebelum perintah dijalankan.

Ini akan menyebabkan kesalahan yang menyatakan hal-hal seperti george; command not foundketika Anda memindahkan perintah /etc/crontabatau file /etc/cron.dke dalam file crontab pengguna.

Sebaliknya, cron akan menghasilkan kesalahan seperti /usr/bin/restartxyz is not a valid usernameatau serupa ketika terjadi kebalikannya.

skrip cron menjalankan perintah dengan opsi --verbose

Saya mengalami gagal pada skrip cron karena saya menggunakan autopilot saat mengetik skrip dan saya menyertakan opsi --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

Script berjalan dengan baik ketika mengeksekusi dari shell, tetapi gagal ketika menjalankan dari crontab karena output verbose pergi ke stdout ketika dijalankan dari shell, tetapi tidak ketika dijalankan dari crontab. Perbaikan mudah untuk menghapus 'v':

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

Alasan paling sering saya melihat cron gagal dalam jadwal yang salah. Dibutuhkan latihan untuk menentukan pekerjaan yang dijadwalkan pukul 11:15 malam sebagai 15 23 * * *ganti * * 11 15 *atau 11 15 * * *. Hari dalam seminggu untuk pekerjaan setelah tengah malam juga menjadi bingung MF adalah 2-6setelah tengah malam, bukan 1-5. Tanggal spesifik biasanya menjadi masalah karena kita jarang menggunakannya * * 3 1 *bukan tanggal 3 Maret. Jika Anda tidak yakin, periksa jadwal cron Anda secara online di https://crontab.guru/ .

Jika pekerjaan Anda dengan platform berbeda menggunakan opsi yang tidak didukung seperti 2/3dalam spesifikasi waktu juga dapat menyebabkan kegagalan. Ini adalah opsi yang sangat berguna tetapi tidak tersedia secara universal. Saya juga mengalami masalah dengan daftar seperti 1-5atau 1,3,5.

Menggunakan jalur yang tidak memenuhi syarat juga menyebabkan masalah. Path default biasanya /bin:/usr/binjadi hanya perintah standar yang akan berjalan. Direktori ini biasanya tidak memiliki perintah yang diinginkan. Ini juga mempengaruhi skrip yang menggunakan perintah non-standar. Variabel lingkungan lainnya juga bisa hilang.

Memukul crontab yang ada sepenuhnya telah menyebabkan masalah bagi saya. Saya sekarang memuat dari salinan file. Ini dapat dipulihkan dari crontab yang ada menggunakan crontab -ljika akan musnah. Saya menyimpan salinan crontab di ~ / bin. Itu dikomentari sepanjang dan berakhir dengan garis # EOF. Ini dimuat ulang setiap hari dari entri crontab seperti:

#! / usr / bin / crontab
# Muat ulang crontab ini
#
54 12 * * * $ {HOME} / bin / crontab

Perintah reload di atas bergantung pada crontab yang dapat dieksekusi dengan bang path menjalankan crontab. Beberapa sistem membutuhkan crontab yang sedang berjalan dalam perintah dan menentukan file. Jika direktori tersebut dibagi-pakai oleh jaringan, maka saya sering menggunakan crontab.$(hostname)sebagai nama file. Ini pada akhirnya akan memperbaiki kasus di mana crontab yang salah dimuat pada server yang salah.

Menggunakan file menyediakan cadangan apa yang seharusnya crontab, dan memungkinkan pengeditan sementara (satu-satunya waktu saya gunakan crontab -e) untuk mundur secara otomatis. Ada tajuk yang tersedia yang membantu mengatur parameter penjadwalan dengan benar. Saya telah menambahkan mereka ketika pengguna yang tidak berpengalaman akan mengedit crontab.

Jarang, saya telah menjalankan perintah yang membutuhkan input pengguna. Ini gagal di bawah crontab, meskipun beberapa akan bekerja dengan pengalihan input.

Jika Anda mengakses akun melalui kunci SSH dimungkinkan untuk masuk ke akun tetapi tidak melihat bahwa kata sandi pada akun tersebut terkunci (mis. Karena upaya kata sandi yang kedaluwarsa atau tidak valid)

Jika sistem menggunakan PAM dan akun terkunci, ini dapat menghentikan cronjobnya agar tidak berjalan. (Saya sudah menguji ini pada Solaris, tetapi tidak pada Ubuntu)

Anda dapat menemukan pesan seperti ini di / var / adm / messages:

24 Okt 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron berusaha memvalidasi myuser akun yang dikunci dari host lokal
24 Okt 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron berusaha memvalidasi myuser akun yang dikunci dari host lokal
24 Okt 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: cron berusaha memvalidasi myuser akun terkunci dari host lokal
24 Okt 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron berusaha memvalidasi myuser akun terkunci dari host lokal

Yang harus Anda lakukan adalah menjalankan:

# passwd -u <USERNAME>

sebagai root untuk membuka kunci akun, dan crontab akan bekerja lagi.

Jika Anda memiliki perintah seperti ini:

* * * * * /path/to/script >> /tmp/output

dan itu tidak bekerja dan Anda tidak dapat melihat output apa pun, itu mungkin tidak berarti cron tidak berfungsi. Script bisa rusak dan output akan stderr yang tidak diteruskan ke / tmp / output. Periksa ini bukan masalahnya, dengan menangkap output ini juga:

* * * * * /path/to/script >> /tmp/output 2>&1

untuk melihat apakah ini membantu Anda menangkap masalah Anda.

=== Peringatan Docker ===

Jika Anda menggunakan buruh pelabuhan,

Saya pikir pantas untuk menambahkan bahwa saya tidak bisa membuat cron berjalan di latar belakang.

Untuk menjalankan pekerjaan cron di dalam wadah, saya menggunakan penyelia dan berlari cron -f , bersama dengan proses lainnya.

Sunting: Masalah lain - Saya juga tidak berhasil membuatnya bekerja saat menjalankan wadah dengan jaringan HOST. Lihat masalah ini di sini juga: https://github.com/phusion/baseimage-docker/issues/144

Saya sedang menulis skrip instalasi shell yang membuat skrip lain untuk membersihkan data transaksi lama dari database. Sebagai bagian dari tugas itu harus mengkonfigurasi cronpekerjaan harian untuk dijalankan pada waktu yang sewenang-wenang, ketika beban basis data rendah.

Saya membuat file mycronjobdengan jadwal cron, nama pengguna & perintah dan menyalinnya ke /etc/cron.ddirektori. Dua gotcha saya:

1. mycronjob file harus dimiliki oleh root untuk menjalankan
2. Saya harus mengatur izin file ke 644 - 664 tidak akan berjalan.

Masalah izin akan muncul /var/log/syslogsebagai sesuatu yang mirip dengan:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

Baris pertama merujuk ke /etc/crontabfile dan kemudian ke file yang saya tempatkan di bawah /etc/cront.d.

Baris yang ditulis dengan cara crontab tidak mengerti. Itu harus ditulis dengan benar. Inilah CrontabHowTo .

Cron daemon bisa berjalan, tetapi tidak benar-benar berfungsi. Coba mulai ulang cron:

sudo /etc/init.d/cron restart

Menulis ke cron melalui "crontab -e" dengan argumen nama pengguna dalam satu baris. Saya telah melihat contoh pengguna (atau sysadmin) menulis skrip shell mereka dan tidak mengerti mengapa mereka tidak mengotomatisasi. Argumen "pengguna" ada di / etc / crontab, tetapi bukan file yang ditentukan pengguna. jadi, misalnya, file pribadi Anda akan menjadi seperti:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

sedangkan / etc / crontab adalah:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Jadi, mengapa Anda melakukan yang terakhir? Nah, tergantung pada bagaimana Anda ingin mengatur izin Anda, ini bisa menjadi sangat berbelit-belit. Saya telah menulis skrip untuk mengotomatisasi tugas-tugas bagi pengguna yang tidak memahami seluk-beluknya, atau tidak ingin repot dengan pekerjaan yang membosankan. Dengan mengatur izin --x------, saya dapat membuat skrip dapat dieksekusi tanpa mereka dapat membacanya (dan mungkin tanpa sengaja mengubahnya). Namun, saya mungkin ingin menjalankan perintah ini dengan beberapa orang lain dari satu file (sehingga membuatnya lebih mudah untuk dipelihara) tetapi pastikan output file ditentukan oleh pemilik yang tepat. Melakukannya (setidaknya di Ubuntu 10.10) memecah kedua ketidakmampuan untuk membaca file serta mengeksekusi, ditambah masalah yang disebutkan sebelumnya dengan meletakkan periode di / etc / crontab (yang, anehnya, tidak menyebabkan kesalahan saat melaluicrontab -e ) .

Sebagai contoh, saya telah melihat contoh sudo crontab -edigunakan untuk menjalankan skrip dengan izin root, dengan yang sesuai chown username file_outputdalam skrip shell. Ceroboh, tetapi berhasil. IMHO, Pilihan yang lebih anggun adalah memasukkannya /etc/crontabdengan nama pengguna dinyatakan dan izin yang tepat, jadi file_outputpergi ke tempat dan pemilik yang tepat.

Membangun apa yang Aaron Peart sebutkan tentang mode verbose, kadang-kadang skrip yang tidak dalam mode verbose akan menginisialisasi tetapi tidak selesai jika perilaku default dari perintah yang disertakan adalah untuk menampilkan baris atau lebih ke layar setelah proc dimulai. Sebagai contoh, saya menulis skrip cadangan untuk intranet kami yang menggunakan curl, sebuah utilitas yang mengunduh atau mengunggah file ke server jarak jauh, dan sangat berguna jika Anda hanya dapat mengakses file jarak jauh tersebut melalui HTTP. Menggunakan 'curl http://something.com/somefile.xls ' menyebabkan skrip yang saya tulis hang dan tidak pernah selesai karena meludahkan baris baru diikuti oleh garis kemajuan. Saya harus menggunakan flag bisu (-s) untuk mengatakannya agar tidak menampilkan informasi apa pun, dan menulis dalam kode saya sendiri untuk menangani jika file gagal diunduh.

Meskipun Anda dapat mendefinisikan variabel lingkungan di crontable Anda, Anda tidak berada dalam skrip shell. Jadi konstruksi seperti berikut ini tidak akan berfungsi:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Ini karena variabel tidak diinterpretasikan dalam crontable: semua nilai diambil secara litteral. Dan ini sama jika Anda menghilangkan tanda kurung. Jadi perintah Anda tidak akan berjalan, dan file log Anda tidak akan ditulis ...

Alih-alih, Anda harus mendefinisikan semua variabel lingkungan Anda secara langsung:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Ketika tugas dijalankan dalam cron, stdin ditutup. Program yang bertindak berbeda berdasarkan apakah stdin tersedia atau tidak akan berperilaku berbeda antara sesi shell dan dalam cron.

Contohnya adalah program goaccessuntuk menganalisis file log server web. Ini TIDAK berfungsi di cron:

goaccess -a -f /var/log/nginx/access.log > output.html

dan goaccessmenunjukkan halaman bantuan alih-alih membuat laporan. Dalam shell ini dapat direproduksi dengan

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

Cara mengatasinya goaccessadalah membuatnya membaca log dari stdin alih-alih membaca dari file, jadi solusinya adalah mengubah entri crontab menjadi

cat /var/log/nginx/access.log | goaccess -a > output.html

Dalam kasus saya cron dan crontab memiliki pemilik berbeda.

TIDAK berfungsi, saya punya ini:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Pada dasarnya saya harus menjalankan cron-config dan menjawab pertanyaan dengan benar. Ada titik di mana saya diminta untuk memasukkan kata sandi pengguna Win7 untuk akun 'Pengguna' saya. Dari membaca yang saya lakukan, sepertinya ini adalah masalah keamanan potensial tetapi saya satu-satunya administrator di satu jaringan rumah jadi saya memutuskan tidak apa-apa.

Berikut adalah urutan perintah yang membuat saya aktif:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to [email protected].
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

Di server RHEL7 saya, pekerjaan root cron akan berjalan, tetapi pekerjaan pengguna tidak. Saya menemukan bahwa tanpa direktori home, pekerjaan tidak akan berjalan (tetapi Anda akan melihat kesalahan yang baik di / var / log / cron). Ketika saya membuat direktori home, masalahnya terpecahkan.

Jika Anda mengedit file crontab Anda menggunakan editor windows (melalui samba atau sesuatu) dan itu menggantikan baris baru dengan \ n \ r atau hanya \ r, cron tidak akan berjalan.

Juga, jika Anda menggunakan /etc/cron.d/* dan salah satu dari file-file itu memiliki \ r di dalamnya, cron akan bergerak di seluruh file dan berhenti ketika menyentuh file yang buruk. Tidak yakin apakah itu masalahnya?

Menggunakan:

od -c /etc/cron.d/* | grep \r