Tag Info

New answers tagged

0

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

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.


0

If this is an application that you wrote/can modify, I would recommend using register_shutdown_function at the time you create the temporary file. That way you can unlink even if your script is interrupted.


0

Sounds like a task for 'find': find /tmp -mtime +30 -delete (with the side effect that deleting a file from within a directory changes its mtime, so the counter resets on that directory)


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.


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 ...


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.


0

Check your setting in /etc/timezone. In the question you mentioned you are in "GMT+1", if that is what your timezone is set to, your script will always execute at UTC plus one hour. If you set it to e.g. "Europe/Paris", the time of execution will change with the daylight savings time.


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

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.


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 ...


0

When corntab runs code, its running it from relative path starting from your home directory. Easy fix : You can use absolute directory path (starting from /) in your script. Other method: use 'path_dir' in your code for portability. path=$(readlink -f $0) path_dir=${path%/*}


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


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 ...


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 ...


0

I have grown quite fond of Jenkins CI for all kinds of 'cron on steroids' tasks. I use it to make and restore backups, clean up stale files/dirs, custom routines involving multiple steps etc... Basically anything that can be automated. The logging is great and the features you seem to need are either in there by default or easily added with one of the many ...


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.


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 ...


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


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 ...


0

I am writing my answer below ; Q1: What is the key differences between the two? Apart from the differences mentioned by other users above, I would like to highlight the point that @reboot is dependent on crond daemon. You are dependent on the order in which crond starts. Although most of the cases, crond starts fine but it may fail sometime to ...


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 ...


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 && ...


0

Defining a PATH and MAILTO within the crontab should help.


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]' >> ...


2

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


0

JosephR explained the logic better than I can. I suggest removing the cd /home/poppetapp && and just use the following to get your desired result. */5 * * * * pgrep -f test_java_10.jar || /home/poppetapp/test_java.sh > /home/poppetapp/test_java.out


0

I think this may be a grouping issue. I replaced your call to pgrep with a simple true or false: If the process isn't running, pgrep will fail: $ false || echo cd && echo run cd run If the process is running, pgrep will be successful: $ true || echo cd && echo run run In this case, you would want nothing at all to be executed! Running ...


0

The advantage of something like || is it allows you to run something based on a return code. E.g. if the left hand side is false then it evaluates the right hand side, but otherwise it doesn't bother. Here's the problem though - look at the man page for pgrep: The pgrep and pkill utilities return one of the following values upon exit: 0 One or more ...


0

It's seems to be a typo mistake. In the first script you use /var/log but in the new one it's /var/logs. Log is the standard directory but you seems to use logs



Top 50 recent answers are included