Why is my cron job not scheduled?

Question

I am trying to set up a cron job, by creating a file /etc/cron.d/myjob:

55 * * * * t echo hello > /tmp/cron.log  && cd /tmp/test/ && pwd > /tmp/cron.log

I tried to verify if the job is scheduled successfully, by using the redirections. I created the file at 21:50, and when 5 minutes later i.e. it is 21:55, there is still no /tmp/cron.log created. I was wondering why?

I specify the user to be t for the job in /etc/cron.d/myjob. But whose is the cron job? I am not sure about it, so I tried the two commands below. Neither shows the job I created.

$ crontab -l
no crontab for t
$ sudo crontab -l
[sudo] password for t: 
no crontab for root

My /etc/crontab doesn't explicitly read from the files under /etc/cron.d/. See below. Can that be the reason that my cron job isn't running? Thanks.

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

---

Update:

Thanks to Jeff. change permission on /etc/cron.d/myjob to rw-r--r-- solves the problem. Why does the original rw-rw-r-- permission of my job file not work, but rw-r--r-- is required? Do the files under /etc/cron.d/ and /etc/cron.daily/ must have the same permissions rw-r--r--?

Why does /etc/crontab not need to explicitly read the files under /etc/cron.d/?

Answer 1

Q1

Why does the original rw-rw-r-- permission of my job file not work

From man cron:

/etc/crontab and the files in /etc/cron.d must be owned by root, and must not be group- or other-writable.

So, the files inside /etc/cron.d should be:

chown root:root /etc/cron.d/*
chmod go-wx /etc/cron.d/*
chmod -x /etc/cron.d/*

Q2

Why does /etc/crontab not need to explicitly read the files under /etc/cron.d/?

No, that is not what it says. What man 5 crontab says is:

/etc/crontab: system-wide crontab Unlike any other crontab you don't have to run the `crontab' command to install the new version when you edit this file and files in /etc/cron.d. These files also have username fields, that none of the other crontabs do.

What that means is that there is no need to run crontab -e to edit and install a new cron job. That the files under /etc/cron.d/ are read and interpreted by cron as soon as edited. And the jobs defined within are executed as scheduled without calling the crontab executable.

Warning

But you should also read from man cron:

In general, the system administrator should not use /etc/cron.d/, but use the standard system crontab /etc/crontab.

That means to execute a crontab -e to create cron jobs.

Editing /etc/crontab (or /etc/cron.d files) directly is a bad idea in general and for new users specially. Get used to manage cron jobs with crontab -e and crontab -l, then, after some (long) time, you may try to understand what /etc/crontab does.

Related

---

edit

Since you are asking:

Can crontab -e create cron jobs in /etc/cron.d/?

No, that is not what I meant. Cron jobs (for users) live in /var/spool/cron/crontabs (in debian-like distros). That is where the command crontab -e edits them.

What usually got edited (before) in /etc/crontab are the system jobs, the jobs that installed packages (like anacron) use to schedule their own jobs. That is not a file that users should edit. In debian, there is a directory to add new jobs that avoids the problem of making mistakes in the edited file (/etc/crontab). That directory is /etc/cron.d/. But still, that is not a directory meant for users (even the administrator) to edit manually.

That is similar as asking why a user should not edit the /etc/sudoers file.

Of course that a user (as root) could execute nano /etc/sudoers and change the file. The system will not block root. But that is a "bad idea".

The manual for crontab is misleading in the sense that it was written to talk to developers (not users). It explains what a developer should do in those files.

Why

About: Why do you think that you need to add to /etc/crontab (or /etc/cron.d) ?

Files in those two places contain "lines", each line is a job.
Exactly the same is a line that is edited with crontab -e. Each line is a job to be executed by cron. The only difference is that in those two places, the job line contains an additional field for "user". But:

crontab -u user1 -e

Will also add new lines (jobs) (if the user running that command has the right privileges) that will be executed as "user1". The only (practical) difference is that a user could edit those jobs but not the ones inside /etc/crontab or /etc/cron.d/. That seems like a good idea IMO to avoid users from editing jobs of other users.

In short: to add jobs: Use crontab -e.