[SOLVED] Cron jobs

PolePosition · 2014-01-03 10:29:41

Hello everybody,

If you have a few minutes, I would have three questions for you.

Question number 1:

I have configured a couple of month ago a fstrim job:

[root@zoulou cron.hourly]# pwd
/etc/cron.hourly
[root@zoulou cron.hourly]# ls
0anacron  fstrim
[root@zoulou cron.hourly]# cat fstrim 
fstrim /
fstrim /home/bastien/DOCUMENTS
fstrim /boot
[root@zoulou cron.hourly]#

I was not quite sure whether this job was running as planned or not.
And I had the feeling that it was not running at all. I think I found why:

[root@zoulou cron.daily]# systemctl enable cronie
[root@zoulou cron.daily]# systemctl start cronie

I had to activate CRON ! Could you please confirm?

Question number 2:

I can see that in the folder /etc/cron.daily there are some default files:

[root@zoulou cron.daily]# pwd
/etc/cron.daily
[root@zoulou cron.daily]# ls
atop  logrotate  man-db  shadow
[root@zoulou cron.daily]#

Do you think that with CRON now activated, there will be some problems/confilts between systemd <=> cron ?

Question number 3:

All I have to do to launch the command automaticaly, is as following, right?

[root@zoulou cron.hourly]# pwd
/etc/cron.hourly
[root@zoulou cron.hourly]# ls
0anacron  backup  fstrim
[root@zoulou cron.hourly]# cat backup 

/usr/local/bin/backup_OS_incr.sh
[root@zoulou cron.hourly]# cat fstrim 
fstrim /
fstrim /home/bastien/DOCUMENTS
fstrim /boot
[root@zoulou cron.hourly]#

Regards and happy new year!
Bastien

Last edited by PolePosition (2014-01-03 17:27:05)

PolePosition · 2014-01-03 11:44:13

Hi,

Okay now I have confirmation that it does not work.
For instance, the backup script should have run at midday (12:00) but obviously it didn't :

[bastien@zoulou ~]$ su
Password: 
[root@zoulou bastien]# cd /media/RAID_5/
[root@zoulou RAID_5]# rdiff-backup -l BACKUP_OS_INCR/
Found 9 increments:
    increments.2014-01-02T11:19:18+01:00.dir   Thu Jan  2 11:19:18 2014
    increments.2014-01-02T11:28:13+01:00.dir   Thu Jan  2 11:28:13 2014
    increments.2014-01-02T11:30:09+01:00.dir   Thu Jan  2 11:30:09 2014
    increments.2014-01-02T11:34:50+01:00.dir   Thu Jan  2 11:34:50 2014
    increments.2014-01-02T12:16:19+01:00.dir   Thu Jan  2 12:16:19 2014
    increments.2014-01-02T12:21:45+01:00.dir   Thu Jan  2 12:21:45 2014
    increments.2014-01-02T13:50:37+01:00.dir   Thu Jan  2 13:50:37 2014
    increments.2014-01-02T13:57:16+01:00.dir   Thu Jan  2 13:57:16 2014
    increments.2014-01-02T23:40:29+01:00.dir   Thu Jan  2 23:40:29 2014
Current mirror: Fri Jan  3 10:16:35 2014
[root@zoulou RAID_5]#

Do you have an idea? :-/

Thanks,
Bastien

ewaller · 2014-01-03 15:41:59

Moving to Newbie forum.

ewaller · 2014-01-03 15:46:28

Does your journal provide any insight?
Are those scripts executable? By root?
What happens if you run those scripts by hand?

Andreaskem · 2014-01-03 15:48:54

How did you configure it? Crontab?

PolePosition · 2014-01-03 16:16:35

Hi,

Thanks for your answers.

I think I thound the problem: crontab was empty. I though that if you put the script in /etc/cron.hourly then it is not necessary to create a crontab...

I'll see whether it works at 6PM!

[root@zoulou cron.hourly]# crontab -l
#minute	hour	day_of_month	month	day_of_week	command
0	*	*		*	*		/usr/local/bin/backup_OS_incr.sh
[root@zoulou cron.hourly]#

Last edited by PolePosition (2014-01-03 16:30:30)

PolePosition · 2014-01-03 17:13:44

Hi,

Ahahaha now it works fine!

[...]
    increments.2014-01-03T13:27:13+01:00.dir   Fri Jan  3 13:27:13 2014
    increments.2014-01-03T17:01:40+01:00.dir   Fri Jan  3 17:01:40 2014
Current mirror: Fri Jan  3 18:00:01 2014
[root@zoulou RAID_5]#

Thx !
Bastien

Andreaskem · 2014-01-03 17:17:21

You should put [SOLVED] in front of your thread title (I think by editing your first post).

Neitsab · 2014-01-08 00:33:30

PolePosition wrote:

I was not quite sure whether this job was running as planned or not.
And I had the feeling that it was not running at all. I think I found why:
[root@zoulou cron.daily]# systemctl enable cronie
[root@zoulou cron.daily]# systemctl start cronie
I had to activate CRON ! Could you please confirm?

I was going through the wiki about cron and came to the forum to ask the same question : is cronie.service indeed NOT enabled by default?

It sure seems so as

$ systemctl | grep cronie.service
$ systemctl | grep cron

don't return anything and

$ sudo systemctl is-enabled cronie
$ systemctl is-enabled cronie

both returned "disabled" (never know, could have been a sudo thing). And of course:

$ systemctl status cronie
cronie.service - Periodic Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cronie.service; disabled)
   Active: inactive (dead)

How can it be so? Aren't logrotate, man-db and shadow important system tasks?
I just installed pkgstats: nowhere in its wiki page is mentionned the fact that users should enable cronie.service for this package to actually have an effect.

Cron#users and autostart is kind of milseading too, stating:

cron should be working upon login on a new system to run root scripts.

Checking /var/log/ manually and via

$ {sudo} journalctl -u

on my newly (couple of weeks) installed system didn't return anything concerning cron.

Can somebody answer that newbie's question: why isn't cronie autostarted by default, would it be only for provided cron.daily scripts?

I'll update the wiki page with the answer for that to be a bit clearer, and (maybe) a mention somewhere around the Beginner's guide could help if logrotate, man-db and shadow are supposed to be activated.

Edit: updated commands and checks after reading https://raspberrypi.stackexchange.com/q … ty-on-arch. Still no trace of cronie/anacron's executions in logs. Could it be something's wrong with my system?

Last edited by Neitsab (2014-01-08 00:59:09)

WonderWoofy · 2014-01-08 01:08:14

I kind of recall at some point cronie was enabled in a new install. But I know for certain that this is not longer the case. I think it is just a case of the wiki having not caught up with the state of a new installation. Those of us who would actually care to edit the wiki are also ones who are not likely to be dealing with a fresh installation. So I think that this was a case of just having no wiki editors actually know the current state.

Whether it is or isn't enabled by default doesn't really matter in my opinion. Arch is a DIY distribution and as such tries not to make too many decisions for you about what is and is not started/enabled. Other distributions actually enable services upon package installation, which drives me bonkers and leads to all kinds of crazy split packages.

I do agree though that this should be changed in the wiki. Maybe that could be your first wiki contribution.

Neitsab · 2014-01-08 02:36:10

Thanks for your confirmation Although

Arch is a DIY distribution and as such tries not to make too many decisions for you about what is and is not started/enabled

doesn't really stand up to me, as Arch's default install makes quite a few of decisions on behalf of its users: many services are started by defaut, a precise list of packages are included in base...
(I guess only Linux From Scratch doesn't really make any decisions on behalf of its users, and still you have to follow a book )

So my question was rather: are those cron jobs (and therefore enbling cronie.service) unimportant enough not to be part of them? I see

/etc/cron.daily/logrotate
/etc/cron.daily/man-db
/etc/cron.daily/shadow

are not part of cronie's default files, and only logrotate relies upon cronie for some optional task. But then why include cronie in base if it isn't to enable it? If you don't enable cronie.service, logrotate is useless (as it is only optionnally required by syslog-ng, which itself is in [extra]), and therefore it's difficult to see why they are both included in base...

Other packages that depends on a cron's implementation are (as per cronie's package page):

gnome-schedule (requires cron)
logwatch (requires cron)
pkgstats (requires cron)
pppusage (requires cron)
squid (requires cron)

I guess it's just a legacy thing (or a "devs' preference"), and I'm really okay with that. I just wanted to 1) confirm my discrepant finding about cronie's inactivation, and 2) question a little bit the reasoning behind But as your underlined, the wiki only waits to be edited!

(Speaking of what, you can track my contributions here. I sure hope to build upon this small debut, I took profit of my first real (understand: not quick 'n dirty) Arch install on a new laptop in a SSD/HDD + LUKS + LVM + ext4 setup to learn a lot, thanks to the great Arch ecosystem, and to add some small stuff that I found were missing or unclear. And so will I do with cronie's and pkgstat's pages, besides preparing larger edits in the SSD#TRIM section (quite a mess, plus I stumbled upon new info from ext4 dev Theodore Ts'o about discard), as well as dm-crypt (although this one has been through a complete overhaul as I could see).

As you said, taking profit of a fresh install to update what needs, and probaby never come back to it until the next machine

Edit : PS, do you think this question might deserve devs' attention via a bug report or a message on arch-devel ML ? I think updating the wiki will suffice, but on the other hand it may make up for an interesting debate

Last edited by Neitsab (2014-01-08 02:39:22)

Arch Linux

#1 2014-01-03 10:29:41

[SOLVED] Cron jobs

Question number 1:

Question number 2:

Question number 3:

#2 2014-01-03 11:44:13

Re: [SOLVED] Cron jobs

#3 2014-01-03 15:41:59

Re: [SOLVED] Cron jobs

#4 2014-01-03 15:46:28

Re: [SOLVED] Cron jobs

#5 2014-01-03 15:48:54

Re: [SOLVED] Cron jobs

#6 2014-01-03 16:16:35

Re: [SOLVED] Cron jobs

#7 2014-01-03 17:13:44

Re: [SOLVED] Cron jobs

#8 2014-01-03 17:17:21

Re: [SOLVED] Cron jobs

#9 2014-01-08 00:33:30

Re: [SOLVED] Cron jobs

#10 2014-01-08 01:08:14

Re: [SOLVED] Cron jobs

#11 2014-01-08 02:36:10

Re: [SOLVED] Cron jobs

Board footer