Tag Info

Hot answers tagged

14

heemayl is correct about the location of crontab files on Linux, but it might be different on other operating systems and "theoretically" is could also be in a different location on Linux. Essentially, when a special interface is provided to access the files, you should use it. This will ensure that cron gets to check the files before installing them, makes ...


7

No, cron only knows about the day of the week, the day of the month and the month. Running a command twice a month on fixed days (e.g. the 1st and the 16th) is easy: 42 4 1,16 * * do_stuff Running a command every other week is another matter. The best you can do is to run a command every week, and make it do nothing every other week. On Linux, you can ...


5

The location of cron files for individual users is /var/spool/cron/crontabs/. From man crontab : Each user can have their own crontab, and though these are files in /var/spool/cron/crontabs, they are not intended to be edited directly.


5

This will likely depend on your OS and it's implementation of cron. This is not possible in the most popular cron implementation, vixie/isc cron. From the crontab(5) manpage: LIMITATIONS The cron daemon runs with a defined timezone. It currently does not support per-user timezones. All the tasks: system's and user's will be run ...


5

No, you don't have to be logged in to run tasks in cron. Its whole idea is to keep track of scheduled tasks without any need of user interaction. You just set up a crontab and forget about it, no hassle with logging in is needed. Additional tip: you can run programs in the background easily by launching <command> & or, if for some reason you ...


4

cron runs whether you are logged-in or not. It's a daemon that checks items in the crontab (cron table) and runs them at the appointed time(s). If you had to be logged-in to do it, it would be pretty unhelpful - more like running a process in the background after a sleep, or in a loop.


4

crontab -e opens a file in /tmp instead of the actual crontab so that it can check your new crontab for errors and prevent you from overwriting your actual crontab with those errors. If there are no errors, then your actual crontab will be updated. If crontab -e just wrote straight to your actual crontab, then you would risk blowing away your entire ...


4

To have something execute only on the second Monday of a month the day of week value needs to be 1 and the day of month value has to be 8-14, the hour has to be 2,6,10,14,18,22 and the minute 0. However as dhag correctly commented and provided a solution for, when you specify both the day of week and the day of month (i.e. not as *), the program is executed ...


3

OK, so glenn jackman's answer works and it also answered my bonus question but I have since figured out another and what I believe to be more elegant way of making sure the cronjob runs in the directory in which the scripts are located. Simply by replacing */10 * * * * ~/mydirectory/myscript.sh with */10 * * * * cd ~/mydirectory && ...


2

You are calling the script incorrectly. It should be: #! /bin/bash do-something do-something-else ./myotherscript.sh;


2

The format is minute / hour / day of month / month / day of week So that would make 0 4 9-15 * 2 /opt/bin/cleanup.sh and 15 18 3 8-14 * /opt/bin/verrrrrrrry.sh


2

Actually, cron is production-ready. It's been battle-tested so many times it's hard to accuse it of malfunctioning. What you might be experiencing is issues resulting from simple errors. It would help a lot if you specified what your problems with cron are, exactly. As already pointed out by gaueth, you can append >> /tmp/somefile 2>&1 to you ...


2

The current (working) directory is probably not set to /opt/www when the cronjob is started. You can set it in your script backup.sh before the tar... line by: cd /opt/www or you can use the full path in the tar line by: tar zcf backups/$FILENAME /opt/www/f I can also advise to use a full path for backups/$FILENAME


2

Move your cronjob to 8:00 and sleep one hour if you are in GMT+1 0 8 * * * [ "$(date +\%z)" = "+0100" ] && sleep 3600; place_your_command_here


1

You cannot directly have cron run a job fortnightly (every two weeks). However, it is reasonably straightforward to ensure that the main part of the job runs only every other week. @Gilles has offered one solution; here's another: 42 4 * * 1 test 1 -eq $(($(date +\%g) & 1)) && do_stuff... The date +%g command returns the current week number ...


1

Take a look at tmpreaper: it allows you to clean up files within certain directories based on their inactivity. It provides a large number of options to control what it cleans up (or leaves untouched) in detail.


1

From the manual page: The daemon will use, if present, the definition from /etc/timezone for the timezone. The environment can be redefined in user's crontab definitions but cron will only handle tasks in a single time‐ zone.


1

You need to put a backspace in front of the * so it's not used as a wildcard. VAR1="\*/1 \* \* \* \* /usr/bin/wget -O /var/tmp/output-folder-path https://my.server.com:12000/cron/push >> /dev/null 2>&1" EDIT I was wrong. The * doesn't escape when you do it like I posted above. Instead use single quotes. ...


1

The production-ready scheduling facility on Unix systems is cron. Logging issues Cron logs what it does to the system logs. It sends the output of jobs, if any, over email. retrying tasks on failure Cron doesn't do that, for good reason. Retrying tasks on failure is business logic. How would the system know which failures should lead to retrying ...


1

You can use > /tmp/logfile 2>&1 after your crontab scheduled command to redirect output from the commands to a log file. Also check out gnome-schedule for a graphical UI to play around with crontab and at.


1

If the PHP script creates the file in the current directory, change to the desired output directory: */45 * * * * cd /path/where/file/to/save && /path/to/php /path/to/file.php If the PHP script creates the file in your home directory, you might be able to pretend your home directory is elsewhere — but if it also tries to read other files from your ...


1

myscript should have: cd "$(dirname "$0")" . ./myotherscript.sh When cron launches your script, the $PWD might be / so you should go to where your script is located if you want to use relative paths. You may find it useful to log your script's output: */10 * * * * ~/mydirectory/myscript.sh 2>&1 | /usr/bin/ts '[%FT%T]' >> ...


1

You might consider 3 ways to reduce your proces impact on system load/CPU time: Use the nice command to manually lower the task's priority. Use the cpulimit command to repeatedly pause the process so that it doesn’t exceed a certain limit. Use Linux’s built-in control groups, a mechanism which tells the scheduler to limit the amount of resources available ...



Only top voted, non community-wiki answers of a minimum length are eligible