0

I have read a number of posts on SE.com regarding cronjobs, crontab, and how to reschedule cron jobs. But it seems that, in my Debian environment, a session cleanup job schedule simply called "php", that is present in /etc/cron.d, specifying root as the user, and currently running every 30 minutes, cannot be rescheduled, unless a reboot occurs.

cat /etc/cron.d/php

returns:

9,39 8-20     * * *     root   [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean 2>>/dev/null; fi

Whatever hour/minute changes I do will not be taken into account, despite /etc/init.d/cron restart . It is on a production server, therefore the host can't be restarted easily, or as an experiment.

Is there a command I can issue to tell crond to take into account any rescheduling?

  • for the title question: you can check cron is scheduled with something like this (for Debian): grep CRON /var/log/syslog. If there are entries showing your script's name, this isn't a cron problem anymore – A.B Apr 17 '18 at 10:38
  • As rightly suggested by Stephen, I split the set of two questions into two separate posts. – Fabien Haddadi Apr 19 '18 at 3:53
3

Welcome to Debian; you no longer use cron.

M. Kitt is right that Stack Exchange prefers one question per question, but in this case both questions stem from a fundamental mistake that you are making: You are erroneously assuming that you are running cron jobs.

As you can see in the very cron job description that is in front of you, your cron jobs are disabling themselves because they see systemd running on your system:

… && if [ ! -d /run/systemd/system ]; then … ; fi

/etc/cron.d/php is not unofficial, by the way. It is installed by the Debian php-common package. Also installed from that very same package are the things that run instead of that cron job:

This is a pattern that one can find in an increasing number of such Debian packages nowadays: the cron jobs are supplanted by systemd units, and self-disable when (only) systemd is running.

So adjusting the scheduling in the cron table will achieve nothing (apart from changing when a shell command that does nothing is scheduled). Similarly, setting environment variables in the cron table will achieve nothing. You need to change the scheduling in the timer unit, and change the environment variables in the service unit.

The details of that are beyond the scope of this answer, but very briefly you need to learn about systemd units, unit override files, and the systemctl cat, systemctl status, and systemctl edit commands.

Further reading

  • Thank you JdeBP, it is an exhaustive answer, well documented with the references. After checking, indeed /run/systemd/system is a directory here, therefore sessionclean is not called here like I thought. What got me in what the fact that the warnings exactly occur at the same minutes as the ones scheduled in that /etc/cron.d/php file! Minutes 09 and 39, hence my initial belief. – Fabien Haddadi Apr 19 '18 at 4:01
  • Confirmation, cat /lib/systemd/system/phpsessionclean.timer shows the [Timer] section has got 09 and 39 minutes programmed too, hence my observations. – Fabien Haddadi Apr 19 '18 at 4:25

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.