4

What can I do to make this script run daily?

If I manually run the script, it works. I can see that it did what it's supposed to do. (backup files) However, it will not run as a cron.daily script. I've let it go for days without touching it -- and it never runs.

The actual script is here /var/www/myapp/backup.sh

There is a symlink to it here /etc/cron.daily/myapp_backup.sh -> /var/www/myapp/backup.sh

The cron log at /var/log/cron shows anacron running this script:

Aug 19 03:09:01 ip-123-456-78-90 anacron[31537]: Job `cron.daily' started
Aug 19 03:09:01 ip-123-456-78-90 run-parts(/etc/cron.daily)[31545]: starting myapp_backup.sh
Aug 19 03:09:01 ip-123-456-78-90 run-parts(/etc/cron.daily)[31559]: finished myapp_backup.sh

Yet there is no evidence that the script actually did anything.

Here is the security info on these files:

ls -la /var/cron.daily

<snip>
lrwxrwxrwx  1 root root   25 Aug 12 21:18 myapp_backup.sh -> /var/www/myapp/backup.sh
</snip>

ls -la /var/www/myapp

<snip>
drwxr-xr-x  2 root root 4096 Aug 13 13:55 .
drwxr-xr-x 10 root root 4096 Jul 12 01:00 ..
-rwxr-xr-x  1 root root  407 Aug 12 23:37 backup.sh
-rw-r--r--  1 root root   33 Aug 12 21:13 list.txt
</snip>

The file called list.txt is used by backup.sh.

The script just runs tar to create an archive.

101010
  • 14,866
  • 30
  • 95
  • 172
  • Most likely this is "path to program" problems. Most certain solution is to hard-code paths to all cmds in your script. If you do that and it works, then you know what the problem is, and it will be easier to get advice on how to fix it. Good luck. – shellter Aug 22 '13 at 17:40
  • Can you show the contents of `backup.sh`? Running a symlink from the `cron.daily` should work. – lurker Aug 22 '13 at 17:44
  • @010110110101 - You might check if SELinux is enabled and possibly blocking the job from running - use 'sestatus' and see if it is enforcing. Also, check in /var/log/audit for potential clues. – Emo Mosley Aug 22 '13 at 19:46
  • I've noticed that some versions of anacron/cron (on debian specifically) don't like extensions (such as .sh) and are very picky about the filenames. Probably not your problem as your output shows anacron starting the job, but it might help someone else in the future. Check [this answer](http://stackoverflow.com/questions/5486601/linux-debian-crontab-job-not-executed) for more. – Daniel Kinsman Oct 23 '13 at 23:29
  • Does your script starts with #!/bin/bash as the first line? – nicky_zs Feb 28 '14 at 02:54

2 Answers2

11

From the cron manpage of a debian/ubuntu system:

the files under these directories have to be pass some sanity checks including the following: be executable, be owned by root, not be writable by group or other and, if symlinks, point to files owned by root. Additionally, the file names must conform to the filename requirements of run-parts: they must be entirely made up of letters, digits and can only contain the special signs underscores ('_') and hyphens ('-'). Any file that does not conform to these requirements will not be executed by run-parts. For example, any file containing dots will be ignored.

So:

  • file need to be owned by root
  • if symlink, the source file need to be owned by root
  • if symlink, the link name should NOT contain dots
Yusef Maali
  • 2,201
  • 2
  • 23
  • 29
  • 1
    This fixed it! You can test that your scripts execute via cron (daily, for instance) by running: `# run-parts -v --report /etc/cron.daily` – Cole Sep 09 '18 at 20:18
1

I had a similar situation with cron.hourly and awstats processing.

I THINK it is related to SELinux and anacron not having the same powers/permissions as cron. The ACTUAL solution defeated me (so far).

MY WORKAROUND SOLUTION: Run the job via root's cron entries (crontab -e ) and simply schedule it hourly.

Craig Campbell
  • 11
  • 1