1 Topic by zacek

  • zacek
  • Member
  • Offline
  • From: Czech Republic
  • Registered: 2014-02-08
  • Posts: 19

Topic: root cron vs. cron.d

======== Required information ====
- iRedMail version:  1.8.2 iRedAdmin-Pro-MySQL
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):  1.8.2 iRedAdmin-Pro-MySQL
- Linux/BSD distribution name and version: Debian 7 stable  (7.6)
- Related log if you're reporting an issue:
====

Hi Zhang,
I have read closed topics "iRedAdmin very slow after upgrade to iRedAdmin-PRO version" http://www.iredmail.org/forum/topic7931 … rsion.html and I found probably the same problem in our instalation - the root cron doesn't start regularly.

There is probably any problem with run of root crontab. I have to find the cause.

I'm not sure why, but I prefer directories "/etc/crontab.*" for system scripts. In my own opinion, it is much more clear to store system scripts here, instead of using root crontab.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,788

Re: root cron vs. cron.d

This is a bug in Debian (and probably in Ubuntu too), you can find info about this bug in manual page of 'crontab':

Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear load normally. However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end.

I checked iRedMail source code moment ago to make sure they will end with a blank line for each cron job. Hope it will work in upcoming iRedMail release.

Personally, i don't think it's a good idea to mess up /etc/cron*.