-2

I've been trying my best to understand how crontab and logrotate work together, and I'm going around in circles.
I have taken the line from /etc/crontab and run: 

$ sudo run-parts --report /etc/cron.hourly
/etc/cron.hourly/logrotate:
run-parts: failed to exec /etc/cron.hourly/logrotate: No such file or directory
run-parts: /etc/cron.hourly/logrotate exited with return code 1

$ run-parts --report /etc/cron.hourly
/etc/cron.hourly/logrotate:
run-parts: failed to exec /etc/cron.hourly/logrotate: No such file or directory
run-parts: /etc/cron.hourly/logrotate exited with return code 1

The file logrotate does exist in /etc/cron.hourly: 

$ ll /etc/cron.hourly/
total 16
drwxr-xr-x  2 root root 4096 Jun 25 15:43 ./
drwxr-xr-x 94 root root 4096 Jun 26 10:20 ../
-rwxrwxr-x  1 root root   98 Jun 26 13:00 logrotate*
-rw-r--r--  1 root root  102 Feb  9  2013 .placeholder

I assume this is why my latest changes to rotate logs hourly is not working.

Oddly, when I run : 

$ sudo run-parts --report /etc/cron.daily

It just hangs until I press ctrl+c to cancel it.

My /etc/cron.hourly/logrotate looks like this:

#!/bin/sh
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate_hourly.conf

If I run the following:

sudo /usr/sbin/logrotate /etc/logrotate_hourly.conf

Then it rotates the logs exactly as it should.

This leads me to assume the error mentioned above is my issue.
Does anyone have any ideas they can give me as to what I've missed? Cheers

Update:
from what was recommended below, I converted my /etc/cron.hours/logrotate to unix line endings.
This meant that running the crontab command manually in the terminal worked. No errors, and logs were rotated correctly.

However crontab is still not running automatically.

datacubed
  • 189
  • 1
  • 10
  • When weird things happen, start by checking your system logs (ironically, in this case). This particular weird thing smells like an access-control issue, and among the few things that can or will deny access to a privileged process, such as one run as root via `sudo`, is mandatory access controls. On Linux, that means SELinux, and in that case your system logs should contain AVC messages about the denial of access. If that's indeed what's happening then fixing it might be as easy as running `sudo restorecon -r /etc`. – John Bollinger Jun 26 '19 at 14:20
  • Second guess: I copied your `/etc/cron.hourly/logrotate` from the question and ran a character count on it. I got 95, not the 98 reported in your directory listing. Do you perhaps have Windows line endings in your local copy? If so, then the `dos2unix` command can fix it (though for a three-line script, it oughtn't to be too hard to fix such an issue by hand). – John Bollinger Jun 26 '19 at 14:39
  • I tried running ```tail -f /var/log/syslog``` but when i ran the daily cron tab command (and it failed with "no files" again), nothing printed in the syslog. Oddly I can see that every hour it has printed ```CRON[2918]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)``` Followed by: ``` CRON[2917]: (CRON) info (No MTA installed, discarding output)``` - I dont think theyre related though. – datacubed Jun 26 '19 at 14:41
  • dos2unix! Jesus why didn't I check that. All the times ive had odd issues with unix based config files. It ran just now manually with no errors. Going to double check everything. Cheers @JohnBollinger – datacubed Jun 26 '19 at 14:43
  • @JohnBollinger so it worked when I ran it manually ```sudo run-parts --report /etc/cron.hourly```. Checked my logs folder and they had rotated. I changed the crontab minutes (for when hourly runs) to 48, and waited. syslog says it ran : ```14:48:01 cron[967]: (*system*) RELOAD (/etc/crontab)```. Followed by: ```(root) CMD ( cd / && run-parts --report /etc/cron.hourly)```. But it didn't run still :S – datacubed Jun 26 '19 at 14:51
  • I've got nothing else at the moment. – John Bollinger Jun 26 '19 at 14:56

1 Answers1

0

The answer here was during my deploy I had missed a file that had Windows line endings. Using dos2unix on the server it fixed everything.

Running:

sudo service cron reload

Was required after editing "/etc/crontab" - thought I had read a few times this shouldn't be needed.

datacubed
  • 189
  • 1
  • 10