1

I have added, and successfully setup and deploy an instance with this recipe:

cron "haproxy_log" do command "logrotate /etc/logrotate.d/haproxy" minute '15' end

But when I look at /etc/crontab I don't see it being there. Where does the cron chef puts its cron jobs?

When I do sudo crontab -u root -l I see my job. But how come I can't see it in /etc/crontab?

The cron doesn't run, but I am able to run the command manually by doing: sudo logrotate /etc/logrotate.d/haproxy - Why is that happening?

Hommer Smith
  • 263
  • 1
  • 2
  • 6

2 Answers2

2

The crontab you see with sudo crontab -u root -l is a normal user crontab for user root, located in:

  • /var/spool/cron/crontabs/root (Debian, Ubuntu, HP-UX, SGI IRIX)
  • /var/spool/cron/root (CentOS, RedHat, RHEL, Fedora, IBM AIX and company)
  • /var/cron/tabs/root (FreeBSD, OpenBSD, NetBSD)
  • /usr/lib/cron/tabs/root (Mac OS X)

These files should not be edited directly, but always with the crontab command.

The commands on root's crontab are also always run as root, i.e.

  • they have the normal m h dom mon dow command syntax

  • while in the system-wide /etc/crontab and in /etc/cron.d/* you must also specify the user: 

    # /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.

# m h dom mon dow user  command

A hint towards this is also hidden inside Chef's Cookbook Reference, Resource cron:

The cron resource requires access to a crontab program, typically cron.

Warning: The cron resource should only be used to modify an entry in a crontab file. Use the cookbook_file or template resources to add a crontab file to the cron.d directory. The cron_d lightweight resource (found in the cron cookbook) is another option for managing crontab files.

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • Esa, thanks a lot for the answer. It's still not clear to me. The command didn't run through the cron, but I am able to manually run `sudo logrotate /etc/logrotate.d/haproxy`. What do you think is going on? I basically want to run that command on an hourly basis, using a chef recipe to set it in the instance. – Hommer Smith May 19 '17 at 12:58
  • If you saw your cronjob on `crontab -l`, it should be in place despite it's not on system-wide cron. Could you add the output of your `contab -u root -l`? – Esa Jokinen May 19 '17 at 13:02
  • When running `crontab -l` as my user, I don't see any. When running `sudo crontab -u root -l` I see: `# Chef Name: haproxy_log 15 * * * * logrotate /etc/logrotate.d/haproxy` – Hommer Smith May 19 '17 at 13:05
  • And probably there is a new-line before `15 * ...`, otherwise it would be commented out... But Chef wouldn't do that. – Esa Jokinen May 19 '17 at 14:33
  • Sorry Esa, I don't understand. I think it's added properly into root's crontab, but I don't know why is not running. How can I triage this? – Hommer Smith May 19 '17 at 14:35
  • See from your syslog whether the command gets run or not. You could also add your address in `MAIL=` in the beginning of the crontab to get command output mailed to you for further debug. – Esa Jokinen May 19 '17 at 14:42
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/59013/discussion-between-hommer-smith-and-esa-jokinen). – Hommer Smith May 19 '17 at 14:44
1

On Unix platforms excluding AIX and Solaris, Chef creates a tempfile using the typical crontab syntax, then feeding it to the /usr/bin/crontab command (Source).

Depending on your OS/distribution, the location varies by the cron implementation. On Debian/Ubuntu for example (man 8 cron):

cron searches its spool area (/var/spool/cron/crontabs) for crontab files (which are named after accounts in /etc/passwd); crontabs found are loaded into memory. Note that crontabs in this directory should not be accessed directly - the crontab command should be used to access and update them.

cron also reads /etc/crontab, which is in a slightly different format (see crontab(5)). In Debian, the content of /etc/crontab is predefined to run programs under /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. This configuration is spe‐ cific to Debian, see the note under DEBIAN SPECIFIC below.

Additionally, in Debian, cron reads the files in the /etc/cron.d directory. cron treats the files in /etc/cron.d as in the same way as the /etc/crontab file (they follow the special format of that file, i.e. they include the user field). However, they are independent of /etc/crontab: they do not, for example, inherit environment variable settings from it. This change is specific to Debian see the note under DEBIAN SPECIFIC below.

Like /etc/crontab, the files in the /etc/cron.d directory are monitored for changes. In general, the system administrator should not use /etc/cron.d/, but use the standard system crontab /etc/crontab.

Long story short:

  1. The destination is managed by crontab not chef
  2. typical defaults for recent Debian/Ubuntu crons in 2017 are /etc/cron.d/<filename>
Roland
  • 359
  • 3
  • 9