Cronjob cron.daily does not run (debian) - cron

I got a script to run daily at any time. So /etc/cron.daily seems to be an easy solution.
But now I got the problem, the cronjob won't run that script. It seems like the cronjob won't run any of the daily jobs.
So I tried to put it to cron.hourly and everything worked fine.
But I dont want to run the backup script every hour.
/etc/init.d/cron start|stop works without errors.
/etc/crontab looks like default:
m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
As it won't run I tried to install anacron but without any changes.
Why does it run the hourly scripts but not the daily ones?
Many thanks to all of you!

It might be, that one of your daily-scripts is misbehaving. Try running them manually. I removed the logwatch package and the cron.daily job and it worked again.
This is my /etc/crontab
# /etc/crontab: system-wide crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
16 * * * * root cd / && run-parts --report /etc/cron.hourly
12 2 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
41 1 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
9 3 30 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
try running the daily like so
run-parts -v --report /etc/cron.daily
you can also use --list or --test for more output. In my case I removed the misbehaving script and the daily job worked again

I had the same problem with one of my scripts in /etc/cron.daily
The name of the script was backupBugzilla.sh
After renaming the script to backupBugzilla it worked.

Do you have anacron installed?
# dpkg --get-selections | grep anacron
If yes, it doesn't runs the daily, weekly and monthly scripts.

the manpage of run-parts states:
If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of ASCII upper- and lower-case letters, ASCII digits, ASCII underscores, and ASCII minus-hyphens.
I assume it does not like the name of your script. for example it does not like the extension ".sh" as a dot is not allowed.

I had this problem, and it was because the owner of my script in /etc/cron.daily was not root. Make root the owner of all the scripts in /etc/cron.daily:
sudo chown root /etc/cron.daily/*
Also, be sure the scripts are executable:
sudo chmod +x /etc/cron.daily/*

I have a wheezy not start the /etc/init.d/anacron.
My solution:
edit /etc/init.d/anacron
Required-Start: $all
save and run:
update-rc.d /etc/init.d/anacron defaults
now works well when wheezy start.

Related

Cannot make CRON work for user on CentOS 7

This is file /var/spool/cron/[USER]:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
0 */2 * * * /usr/bin/wget -O - http://[WEBSITE]/[STUFF] >/dev/null 2>&1
I made this CRON to visit website every second hour. But it is not working, because when I type command about CRON status, then it says this:
$ systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded ...
Active: active (running) ...
...
crond[6967]: (CRON) bad minute (/var/spool/cron/[USER])
...
It is weird, because when I move it to the /var/spool/cron/root, then it works. This "bad minute" shows only for other users. But why?
CHMOD is 600 and owner is the user I talk about.
I think you shouldn't edit the cron file directly, have you tried editing it when logged in to the correct user with this command:
crontab -e
Also check that your /etc/crontab file is correct
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

How to test command anacron?

uname -r
4.5.5-300.fc24.x86_64
I have appended 0 0 test touch ~/ana.cron to /etc/anacrontab. But there is no effect after rebooting or resuming from sleep or running sudo anacron -f. I can't find the output file ana.cron.
cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job-identifier command
1 5 cron.daily nice run-parts /etc/cron.daily
7 25 cron.weekly nice run-parts /etc/cron.weekly
#monthly 45 cron.monthly nice run-parts /etc/cron.monthly
0 0 test touch ~/ana.cron
How to solve this?
I'm not sure period can be of 0.
1 0 test.daily nice run-parts touch ~/ana.cron
If you want your task to be run at startup, then use #reboot
#reboot test.reboot nice run-parts touch ~/ana.cron

Trouble getting CRON job running on VPS

I have created a 'sh' script on my VPS which makes copies of the filesystem and SQL and saves them to the same folder which I am going to then push to a backup media. I know my script is working for this as when I log in over SSH as root and run the command manually it creates a zip file and the SQL backup fine but the CRONjob I have created to execute this script is not working. I have created the following cron job in '/etc/crontab':
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
4 6 * * * root test -x /usr/sbin/anacron || ( cd / && run- parts --report /etc/cron.daily )
20 1 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
51 5 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
* * * * * root /home/backup/test.sh
The 5th entry is the one I have created to test. The path is correct and I used an absolute path as instructed before. I have written a simple script called test/sh which outputs some text to a file (test.txt) to test the CRON job and it doesn't work. I am using the command 'tail -f' to monitor changes to the text file and it never gets called. The script works when executed manually though.
Here is the simple 'test.sh' file. This works correctly when called manually.
#!/bin/bash
echo "Dumping at: $(date)" >> /home/backup/test.txt
I understand there may be permissions issues but I thought if I was executing this as 'root' this should be fine? Can anyone see where I am going wrong?
Thanks
So, after a few hours of searching I realised something stupid. I had left out the 'bash' command from the crontab file.
I changed my line to this:
root bash /home/backup/test.sh
And it is now running.

starting a python3 script in ubuntu at boot and wont execute properly using cron /etc/init.d rc.local systemd

I've tried 3 methods on starting python scripts at startup:
Adding the script line with full paths to python3 bin and the script to rc.local (verifying permissions are executable)
This option will execute shell scripts and other commands but for some reason it just doesn't execute my python script. Well actually, it looks like it might but it never finishes cause I dont get the output file showing it worked.
adding to /etc/init.d and creating a symlink
Adding a #reboot in cron
Creating a service with systemd that executes it
All of them appear like they might be triggering the script but like on the last one, I have the script being launched by cron, and then the script removes the cron job that started the script. When I execute the script from the command line normally, it works perfectly. However, when cron starts it, it appears to partially execute cause the /etc/crontab file gets deleted.
Does this have something to do with the context of the file being deleted?
I tried tagging 2> to pretty much all other methods above to see if errors occur but I literally get nothing in the stderr file. Also added the stderr/print to rc.local.
Here is my script
#!/usr/bin/env python3
import time
import subprocess
import re
cron = open("/etc/crontab","r")
print("1")
cronText = cron.read()
cron.close
print("2")
cron = open("/etc/crontab","w")
print("3")
cron.write('')
print("4")
cronText = re.sub(r'\* \* \* \* \* root /usr/bin/env python3 /root/Desktop/test\.py 2\> /root/Desktop/err\.log','',cronText)
print("5")
cron.write(cronText)
cron.close
print("6")
subprocess.call("service cron restart",shell=True)
print("7")
file1 = open("thisWORKED.txt","w")
print("8")
file1.write("This totally worked")
file1.close
print("9")
Here is what /etc/crontab looks like
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
* * * * * root /usr/bin/env python3 /root/Desktop/test.py > /root/Desktop/err.log 2>&1
The err.log literally gives nothing in it output. I tried tagging stderr like everywhere when I tried to other methods. Im mostly just trying to figure out why my scripts arent being started.
Ok lol I figured out what I was doing wrong. I feel like a dummy now. Basically, it runs under the context of the root user so the successful log file is being dumped out to /root instead of /home where the script is being run from. Hence, why there were no errors to report or see in the stderr.

EC2 Micro Instance CPU spikes to 100% at regular interval every day

I know Amazon throttles micro instance if it uses up certain number of CPU time, but I don't think this is the case. All the spikes appear at around 6:30 to 6:40 UTC. I checked my cron job and there is nothing scheduled for that time:
#reboot ~/path/to/script1.sh >> ~/log/cron.log
0 13 * * * ~/path/to/script2.sh >> ~/log/cron.log
What else could it be?
PS: Notice the CPU Utilization dropdown is set at "Maximum". The graph looks similar for "Average".
PPS: This instance is part of a 2-instance load-balanced setup.
Here's what's inside my /etc/cron.daily (the other crons are empty):
apport, apt, aptitude, bsdmainutils, dpkg, logrotate, man-db, mlocate, passwd, popularity-contest, standard, update-notifier-common
Usually, Ubuntu AMIs on Amazon have their daily cron jobs under /etc/cron.daily scheduled for morning hours. This schedule is managed using /etc/crontab. Here's how a sample /etc/crontab looks like:
$ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#
Clearly, daily tasks run at 6:25am. You may want to tweak these settings to move daily tasks to some other time if this is impacting direct delivery of your server(s). Further, you could investigate items under /etc/cron.daily. For me, it looks like:
$ ls /etc/cron.daily/
apport apt aptitude bsdmainutils dpkg logrotate man-db mlocate popularity-contest standard
Out of these, typically man-db and logrotate may take up major CPU time for execution. These are standard tasks and can be tweaked for optimum performance. You may want to look into tuning your logrotate and man-db policies.
Hope this helps.

Resources