0

If I execute the following in the terminal it works:

screen -dmS tt-rss-daemon sudo -u www-data /usr/bin/php /usr/share/nginx/www/tt-rss/update.php --feeds --daemon

If I write the following in a Crontab (crontab -e) and restart the machine nothing happens.

@reboot screen -dmS tt-rss-daemon sudo -u www-data /usr/bin/php /usr/share/nginx/www/tt-rss/update.php --feeds --daemon

Have anyone an idea how to correct this?

3
  • Work your way through serverfault.com/questions/449651/… is will help ypu solve your problem or at least help you gather information that will help us help you.
    – user9517
    Jan 11, 2014 at 20:59
  • rather than a cron problem, it might just be a problem of requiring some enviroment variables that aren't set up in a non interactive shell. What is suggest you is to first add a line to your crontab that will just create a file with random content. This was you'll know if your cronjobs start correctly. Second thing, redirect the script's output to a file, so you'll see if anything happens. Also check the mail spoor for your user and for root, most systems send a mail to the user if a programs outputs something in stderr.
    – stoned
    Jan 11, 2014 at 21:25
  • I suspect screen might be failing due to the lack of a TTY. Jan 13, 2014 at 3:29

2 Answers 2

0

is cron set to run when the system boots? Try setting it to run at a specific time, and see if it runs. If not, then odds are cron isnt running and you will need to add cron to start on the relevant run-level

in Redhat:

chkconfig cron on

in Gentoo:

rc-update add cron default

in Debian/Ubuntu

update-rc.d cron defaults

Failing that, most distributions have a script that is run on boot. In Redhat distributions its in

/etc/rc.d/rc.local

In Gentoo

/etc/local.d/anyfilename.start

In Debian I believe you have to create your own init script.

0

Check your sudoers file and make sure you do not have requiretty enabled (look for a line like Defaults requiretty). requiretty prevents sudo from being used in cron and other non-interactive situations. It isn't the default in Debian. I am fairly certain cron should be emailing your user with the error message if that's the case (unless it's configured not to, or you sent the output to /dev/null).

Another option is if your user does not have permission to have a personal crontab. In that case, cron would just ignore your entry completely. If /etc/cron.allow exists your user must be listed in it. If /etc/cron.deny exists, your user must not be listed in it.

Not the answer you're looking for? Browse other questions tagged .