Do you need cron installed for the files in /etc/cron.daily/ to execute? Did a CentOS 6.x minimal openvz install and noticed cron is not installed by default and after installing mlocate cant help but wander if it will be updated without it.
14 thoughts on - Cron
Hello Matt,
For this you need cronie (the cron daemon) and crontabs (user bindings, including root), see `yum info`:
Installed Packages Name : cronie Arch : x86_64
Version : 1.4.4
Release : 12.el6
Size : 174 k Repo : installed From repo : base Summary : Cron daemon for executing programs at set times URL : https://fedorahosted.org/cronie License : MIT and BSD and ISC and GPLv2
Description : Cronie contains the standard UNIX daemon crond that runs specified programs at
: scheduled times and related tools. It is a fork of the original vixie-cron and
: has security and configuration enhancements like the ability to use pam and
: SELinux.
Name : crontabs Arch : noarch Version : 1.10
Release : 33.el6
Size : 2.4 k Repo : installed From repo : anaconda-CentOS-201303020151.x86_64
Summary : Root crontab files used to schedule the execution of programs License : Public Domain and GPLv2
Description : The crontabs package contains root crontab files and directories.
: You will need to install cron daemon to run the jobs from the crontabs.
: The cron daemon such as cronie or fcron checks the crontab files to
: see when particular commands are scheduled to be executed. If commands
: are scheduled, it executes them.
:
: Crontabs handles a basic system function, so it should be installed on
: your system.
Why bother with */1? Wouldn’t that be the same as just *?
I had the same question. Plus, the man page says “‘/‘ specifies skips of the number’s value through the range.” That could be interpreted to be skip each minute.
That’s for debugging. It’ll be */5 for production purposes.
Anyway. It still doesn’t work. Why?
Anything interesting in the logs?
sudo journalctl -xf _SYSTEMD_UNIT=crond.service
Seemed strange is all. Can the nobody user read down into
/var/www/html/osticket/api? If it works in tmp, maybe permissions are the issue.
Don’t know.
[root@kohrin cron.d]# sudo journalctl -xf _SYSTEMD_UNIT=crond.service
— Logs begin at
As i said. sudo works as a charm. Cron rebels…
remember that cron doesnt run any user profile or login scripts, so it starts with no environment variables set. fully specify any paths in the commands run by cron..
_maybe_ makes sense with ‘*/1’.
So nothing wrong with you cron line, so its probably something in your environment.
If your script is failing, I would normally expect it to output some error messages. Cron will email this to root by default. Maybe check
/var/spool/mail/root? Or set MAILTO=”youremail address” at the top of your cron script.
After many hours of struggling with it, i did “crontab -u nobody -e” and put the same line in private nobody’s crontab. Looks like it’s working. Don’t know why and how.
14 thoughts on - Cron
Hello Matt,
For this you need cronie (the cron daemon) and crontabs (user bindings, including root), see `yum info`:
Installed Packages Name : cronie Arch : x86_64
Version : 1.4.4
Release : 12.el6
Size : 174 k Repo : installed From repo : base Summary : Cron daemon for executing programs at set times URL : https://fedorahosted.org/cronie License : MIT and BSD and ISC and GPLv2
Description : Cronie contains the standard UNIX daemon crond that runs specified programs at
: scheduled times and related tools. It is a fork of the original vixie-cron and
: has security and configuration enhancements like the ability to use pam and
: SELinux.
Name : crontabs Arch : noarch Version : 1.10
Release : 33.el6
Size : 2.4 k Repo : installed From repo : anaconda-CentOS-201303020151.x86_64
Summary : Root crontab files used to schedule the execution of programs License : Public Domain and GPLv2
Description : The crontabs package contains root crontab files and directories.
: You will need to install cron daemon to run the jobs from the crontabs.
: The cron daemon such as cronie or fcron checks the crontab files to
: see when particular commands are scheduled to be executed. If commands
: are scheduled, it executes them.
:
: Crontabs handles a basic system function, so it should be installed on
: your system.
Regards,
What the heck is wrong with cron?
*/1 * * * * nobody /usr/bin/php /var/www/html/osticket/api/cron.php
in /etc/cron.d doesn’t get executed at all (ran from console works of course!). But the SAME file in /tmp runs flawlessly:
*/1 * * * * nobody /usr/bin/php /tmp/cron.php
It’s CentOS7 on VPS with no SELinux.
I’ve noticed similiar behavior before (on bare metal server with SELinux).
Just to be clear:
[root@kohrin cron.d]# sudo -u nobody /usr/bin/php /var/www/html/osticket/api/cron.php
Works as expected.
Why bother with */1? Wouldn’t that be the same as just *?
I had the same question. Plus, the man page says “‘/‘ specifies skips of the number’s value through the range.” That could be interpreted to be skip each minute.
That’s for debugging. It’ll be */5 for production purposes.
Anyway. It still doesn’t work. Why?
Anything interesting in the logs?
sudo journalctl -xf _SYSTEMD_UNIT=crond.service
Seemed strange is all. Can the nobody user read down into
/var/www/html/osticket/api? If it works in tmp, maybe permissions are the issue.
Don’t know.
[root@kohrin cron.d]# sudo journalctl -xf _SYSTEMD_UNIT=crond.service
— Logs begin at
As i said. sudo works as a charm. Cron rebels…
remember that cron doesnt run any user profile or login scripts, so it starts with no environment variables set. fully specify any paths in the commands run by cron..
_maybe_ makes sense with ‘*/1’.
So nothing wrong with you cron line, so its probably something in your environment.
If your script is failing, I would normally expect it to output some error messages. Cron will email this to root by default. Maybe check
/var/spool/mail/root? Or set MAILTO=”youremail address” at the top of your cron script.
After many hours of struggling with it, i did “crontab -u nobody -e” and put the same line in private nobody’s crontab. Looks like it’s working. Don’t know why and how.