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?

2 Answers 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, 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. May 19, 2017 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? May 19, 2017 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 May 19, 2017 at 13:05
  • And probably there is a new-line before 15 * ..., otherwise it would be commented out... But Chef wouldn't do that. May 19, 2017 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? May 19, 2017 at 14:35

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>
  • OP mentioned the job was in crontab -l. Therefore, there should be nothing wrong with the recipe. :) May 19, 2017 at 13:03
  • I don't see it with crontab -l, just with sudo crontab -u root -l May 19, 2017 at 13:06
  • That's just crontab -l for user root. There it is and there it should be. May 19, 2017 at 14:31
  • Yeah, but I am not logged in as root, so if I do crontab -l I don't see anything May 19, 2017 at 14:34
  • 1
    I only shortened it in a comment as everyone already knew the crontab we were talking about. We are still talking about the same thing. :) May 19, 2017 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.