I’ve installed Mautic (email program). It needs 3 cronjobs to run properly.

  • php /var/www/mydomainname/htdocs/app/console mautic:segments:update
  • php /var/www/mydomainname/htdocs/app/console mautic:campaigns:update
  • php /var/www/mydomainname/htdocs/app/console mautic:campaigns:trigger

I am on Ubuntu 18.04 and am using PHP 7.0x.

When I do sudo php /var/www/mydomainname/htdocs/app/console mautic:campaigns:trigger, or any other of the 3 listed above, they work without problem. I get the correct output and it’s executed.

However, when I put the same commands in a crontab, nothing happens.

I’ve tried everything. In the root crontab, in the www-data crontab, in my user crontab, with absolute paths to the PHP7.0 command (in /usr/bin/php7.0). Even tried first changing to the php directory and whatnot.

For example:

* * * * * /usr/bin/php7.0 /var/www/mydomainname/htdocs/app/console mautic:segments:update


* * * * * sudo /usr/bin/php7.0 /var/www/mydomainname/htdocs/app/console mautic:segments:update


* * * * * cd /usr/bin sudo php7.0 /var/www/mydomainname/htdocs/app/console mautic:segments:update

Nothing does the trick when using crontab.

Anyone know why?

  • 1
    Your timespec doesn't appear to have the right number of fields. You can get more diagnostic information by grepping /var/log/syslog (or perhaps journalctl -eu cron.service). – steeldriver Nov 9 '19 at 13:59
  • @steeldriver Can you change that into an answer please? :) – Friederike Nov 9 '19 at 22:18
  • Actually the timespec thing is my fault .. there are 5 stars there in reality ... I didn't copy paste it right into the post ... – Lex Nov 10 '19 at 9:24

From Jens A. Koch's answer to CronJob not running (by ROB) on Stack Overflow:

Here's a checklist guide to debug not running cronjobs:

  1. Is the Cron daemon running?
    • Run ps ax | grep cron and look for cron.
    • Debian: service cron start or service cron restart
  2. Is cron working?
    • * * * * * /bin/echo "cron works" >> /tmp/file
    • Syntax correct? See below.
    • You obviously need to have write access to the file you are redirecting the output to. A unique file name in /tmp which does not currently exist should always be writable.
  3. Is the command working standalone?
    • Check if the script has an error, by doing a dry run on the CLI
    • when testing your command, test as the user whose crontab you are editing, which might not be your login or root
  4. Can cron run your job?
    • Check /var/log/cron.log or /var/log/messages for errors.
    • Ubuntu: grep CRON /var/log/syslog
    • Redhat: /var/log/cron
  5. Check permissions
    • set executable flag on the command: chmod +x /var/www/app/cron/do-stuff.php
    • if you redirect the output of your command to a file, verify you have permission to write to that file/directory
  6. Check paths
    • check she-bangs / hashbangs line
    • do not rely on environment variables like PATH, as their value will likely not be the same under cron as under an interactive session
  7. Don't suppress output while debugging
    • commonly used is this suppression: 30 1 * * * command > /dev/null 2>&1
    • re-enable the standard output or standard error message output by removing >/dev/null 2>&1 altogether; or perhaps redirect to a file in a location where you have write access: >>cron.out 2>&1 will append standard output and standard error to cron.out in the invoking user's home directory.

Still not working? Yikes!

  1. Raise the cron debug level
    • Debian
      • in /etc/default/cron
      • set EXTRA_OPTS="-L 2"
      • service cron restart
      • tail -f /var/log/syslog to see the scripts executed
    • Ubuntu
      • in /etc/rsyslog.d/50-default.conf
      • add or comment out line cron.crit /var/log/cron.log
      • reload logger sudo /etc/init.d/rsyslog reload
      • re-run cron
      • open /var/log/cron.log and look for detailed error output
    • Reminder: deactivate log level, when you are done with debugging
  2. Run cron and check log files again

Cronjob Syntax

# Minute  Hour  Day of Month      Month         Day of Week    User Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  

    0       2       *             *                *          root /usr/bin/find

This syntax is only correct for the root user. Regular user crontab syntax doesn't have the User field (regular users aren't allowed to run code as any other user);

# Minute  Hour  Day of Month      Month         Day of Week    Command    
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)  

    0       2       *             *                *          /usr/bin/find

Crontab Commands

  1. crontab -l
    • Lists all the user's cron tasks.
  2. crontab -e, for a specific user: crontab -e -u agentsmith
    • Starts edit session of your crontab file.
    • When you exit the editor, the modified crontab is installed automatically.
  3. crontab -r
    • Removes your crontab entry from the cron spooler, but not from crontab file.

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.