• We had to restore from a backup today after a failed software update. Backup was from 0000 EDT and restored it at 0800 EDT so we lost about 8hrs. Today is 07/20/2024. More info here.

Solved Crontab vs /etc/cron.x directories

Solved issue

banderas20

Active Member
Joined
Aug 1, 2018
Messages
102
Reaction score
42
Credits
799
Hi.

I have been working with crontab to schedule jobs. I usually run crontab -l (to list the jobs) or crontab -e (to edit them). Always bearing in mind each user.

I also have found the following directories:

/etc/anacrontab
/etc/cron.d
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/crontab
/etc/cron.weekly

¿What is the difference between the 2 approaches?

Thanks!
 


I think for most stuff, it doesn't matter that much.

I work for a company that writes their own .rpm and .deb applications.
Sometimes the config files would conflict with the default httpd.conf or nginx.conf or tomcat.conf or whatever.
So we started using the /etc/httpd/conf.d directory instead. No conflict of ownership, no getting overwritten
when you update the package, and you always know where to look. You don't have to guess which user owns it.

It's similar with cron.d, I always know where to look, things in here don't get over-written by RPMs that contain
cron jobs, and I don't have to be the user that the crontab runs as. I know I can login as a specific user
and do a crontab -e, but it's a lot lot easier to install it as root, and then assign the user in the cronjob
under cron.d

daily, monthly and weekly.. I never use them, and it doesn't make much sense to me. I can run
any cron job, daily, weekly, monthly... so why?
 
Hi.

I have been working with crontab to schedule jobs. I usually run crontab -l (to list the jobs) or crontab -e (to edit them). Always bearing in mind each user.

I also have found the following directories:

/etc/anacrontab
/etc/cron.d
/etc/cron.daily
/etc/cron.hourly
/etc/cron.monthly
/etc/crontab
/etc/cron.weekly

¿What is the difference between the 2 approaches?

Thanks!
The cron jobs already in the /etc/cron* directories are run by root, and usually installed with the initial installation, or when some application is installed later which uses cron. When a user writes a cron job it's run by cron for the user, unless the user writes it from root.

If your system runs systemd, it's likely all cron is run by systemd. Note the "active" indication in the following output:
Code:
[flip@flop ~]$ systemctl status cron.service
● cron.service - Regular background program processing daemon
     Loaded: loaded (/lib/systemd/system/cron.service; enabled; preset: enabled)
     Active: active (running) since Wed 2023-08-30 06:38:35 AEST; 4h 43min ago
       Docs: man:cron(8)
   Main PID: 653 (cron)
      Tasks: 1 (limit: 9415)
     Memory: 1.6M
        CPU: 795ms
     CGroup: /system.slice/cron.service
             └─653 /usr/sbin/cron -f
<snip>

To move from writing cron jobs to writing them directly to systemd is possible by writing a systemd service file which includes the executable to the job itself (in the required format), and then a systemd timer file to control when it's run. It's fairly straight forward, has more flexibility in the timing aspects, and removes that extra level of systemd running cron as opposed to running itself. YMMV.
 
I think I have it clearer now. I guess if I have to analyze an unknown server, it's better to take a look both at /etc/cron* and also to crontab for all users.

Am I correct?

Thanks!
 
I think I have it clearer now. I guess if I have to analyze an unknown server, it's better to take a look both at /etc/cron* and also to crontab for all users.

Am I correct?

Thanks!
It may be simplest to write the crontab rules you design as root so that they will have root access to whatever processes or jobs you wish to have accomplished. It's more standard to create crontab processes that way than to write them and place them into the /etc/cron* directories which are more used by the system. By all means inspect the files in /etc/cron* to see examples of cron working. With your own root created crontabs though, it becomes straight forward to access the crontabs you've written then with crontab -l, as you mentioned in post #1. YMMV.
 
It may be simplest to write the crontab rules you design as root so that they will have root access to whatever processes or jobs you wish to have accomplished. It's more standard to create crontab processes that way than to write them and place them into the /etc/cron* directories which are more used by the system. By all means inspect the files in /etc/cron* to see examples of cron working. With your own root created crontabs though, it becomes straight forward to access the crontabs you've written then with crontab -l, as you mentioned in post #1. YMMV.
Understood. Thanks!
 

Members online


Top