cron.daily symlink (double) does not seem to be executing?
 

Hello,

I cannot understand why the symlink I have put in /etc/cront.daily won't work. It is very possible I am wrong, but my understanding is that cront.{daily,weekly,monthly} works fine with symlinks.

Basically it is double symlink-ed. ls -la on /etc/cron.daily looks like this:

Now, ls -la on /home/myuser/scripts looks like this:

I couldn't see anything suspicious in syslog, so I installed postfix in the hope that I will get some sort of information there. Nothing... I also redirected the output of the script to a file in /home/myuser/log.txt but nothing there. The file was not even created.

I am not doing anything mad in the script, I am just synchronising a local directory with a remote one like this:

As other people suggested in similar threads, I have verified that
is false, which will result in the execution of the second part of the entry in /etc/crontab:

Any input will be much appreciated. I know I am doing something wrong, but I just cannot see it right now... How can I gather more debugging which will help me understand what's going wrong?

Thanks!

I forgot to say, it isn't just cron.daily. I have exactly the same issue when using cron.hourly. I also tried using the actual path of the script rather than double symlink-ing it. Same problem. The weird thing is that when I switch user to root and I execute the script, it's OK... What am I missing?

Thanks!

Filesystems under /media are commonly mounted with the "noexec" option, though that should prevent root from running the script too, unless you actually ran a shell and gave it the file name as a parameter ("bash /home/myuser/scripts/bash/rsync_mysql_backups.sh"). Also, you never showed the permissions on the rsync_mysql_backups.sh file itself. And, does that file start with the necessary "#!/bin/bash" or "#!/bin/sh" line?

Thanks for your input. Here is how fstab looks like:

The file starts with "#!/bin/bash", I just have loads of unnecessary comments as I'm testing it, and I thought I wouldn't bother you with 10 useless lines, when there is only one line that matters.

The permissions of the actual file look like this:
Is fstab enough to check the noexec flag you pointed out as a potential problem? If not, what's the best way to check it?

Thanks!

Since you have that mount listed explicitly in /etc/fstab, the options there would be what is applied, and there is no "noexec". /media is mostly used for automatic mounts when USB flash drives, CD-ROMs, etc., are inserted, and it is for that that options like "noexec" and "nodev" are the default. The definitive answer is just to run the "mount" command with no arguments and see what options it shows for /media/md1_storage.

Another possibility would be a jobs.allow file in the /etc/cron.{daily,hourly} directory, but that is not common.

What Linux distribution are you running? Is it using a /usr/bin/run-parts script to run the jobs in those directories? If so, you could look at that script and see if any problem is apparent, or even execute "run-parts /etc/cron.hourly" as root and see if any relevant messages show up in the terminal. Heck, run it with "bash -x run-parts /etc/cron.hourly" and get a trace of what goes on.

OK, thank you very much for your suggestion, it did not solve the problem directly but it put me down a logical path which actually helped A LOT!

The short answer: it would appear that you cannot have a file name put in cron.{hourly,daily,weekly} which contains a "." (dot). Creating a symlink with the ".sh" extension removed did the job.

As suggested I switched user to root, went to "/" (not "/home/root"...) and ran:
That would list all files in /etc/cron.daily directory (including non executable files), but will not actually run anything (see man page: http://manpages.debian.org/cgi-bin/man.cgi?query=run-parts). The output was suspicious, because it listed everything apart from my script. While looking at the output of the above command, it occurred to me that there was no file listed there (including other scripts that were put there before) which had an extension (".sh", ".php", ".pl" or whatever).

So, I deleted the symlink and I created it again, with the only difference that I didn't include the "." (dot)! To test my assumption I ran:
which worked fine! I admit I will have to wait until tomorrow to find out if the cron.daily will do its thing at the scheduled time, but after running it manually I am relatively confident that it will work. I'll update the thread if that's not the case anyway.

By the way, I am running Debian 7 (I should have said that earlier really). Do you know if this is normal behaviour for cron? I might have missed it, but I couldn't find this documented anywhere. Searching the web I found other people experiencing the same behaviour, but I am not sure if that's normal?

Thanks again for all your help!

It would be something in run-parts, not cron. My run-parts in CentOS 6 is a fairly simple shell script which would not have rejected a ".sh" suffix. Yours is apparently quite different. If it's a script, you can look at it and see what it does.

Sorry for the delay, yes, you are right, it is going to be run-parts that's doing it. In Debian run-parts is compiled. Even then though, I am sure I can have a look into the code and see what it does. The important thing for this thread is that '.' + run-parts = problems apparently. Thanks again for all your help! I hope other people will find this thread useful/helpful.