Tag Info

New answers tagged

3

Use this syntax in the cronjob: * * */3 * * root /bin/bash /opt/db_maintain/run.sh You used source. That is a shell builtin command from bash. Therefore it can only be executed inside a bash shell or via a bash shell. The crontab just executes binaries, not shell commands. So you have to call a binary (/bin/bash), preferably by its abolute path.


2

Different environment variables, working directory, ... You need to debug where exactly analyze.rb is bailing out. First, you're only redirecting stdout, not stderr. Errors probably go to the later, so adding a 2>&1 to the end may help a lot. Or setting EMAIL= at the top of your crontab to have them mailed to you. You can confirm that ruby is ...


1

Set up a cron job to run at certain hours; as @Janis mentioned, this might take the form of entries like: 0 9 * * * bin chmod +x /usr/bin/dropbox 0-59/10 * * * * root /usr/local/bin/maybe-stop dropbox Revised: Running it every 10 minutes as I'd initially written is mad overkill, since only a superuser could have changed it back to +x, so a better ...


0

You can also install the at service/daemon which spools jobs based on time features like "now + 7 days". First, launch atd (through the init scripts or systemd or upstart etc). Then queue up your job with at -f /path/to/command now + 7 days to start it 7 days from right now, or at 2am tomorrow and read the commands to be run tomorrow at 2 in the ...


1

Today is Wednesday. If you want cron to execute a command at midnight every Thursday, here's what you put in your crontab: 0 0 * * 4 root /path/to/command


1

*/7 doesn't mean "every 7 days from now". It means "every days that are a multiple of 7". So it runs the command if #day modulo 7 == 0 → 7th, 14th, 21st, 28th of the month. The french wiki page of Cron provides many examples: http://fr.wikipedia.org/wiki/Cron#Exemples You may want to use Fcron: http://fcron.free.fr/


0

Different approach than the others: Run 4 cronjobs, each staggered by 15 seconds: * * * * * sleep 00; some_job * * * * * sleep 15; some_job * * * * * sleep 30; some_job * * * * * sleep 45; some_job


2

Use cron to start the daemon and to kill it. Since dropbox runs as a user, edit your cronjob as your user: crontab -e and in the editor, place: 0 9 * * * $HOME/bin/dropbox-daemon-path 59 16 * * * pkill -u "$LOGNAME" dropbox-daemon-process-name At 9am it starts the dropbox daemon (you should provide the full path here) and at 1 minute till 5pm, it kills it ...


0

One option using cron could be to set up a cronjob at 9:00 and one at 16:00 that creates (or resp. deletes) a flag-file in a certain place. And the wrapper would check the existence of that flag-file to determine whether it will start the application or not. If your application got started before 16:00 and still runs after 16:00, you could of course - ...


1

Why don't you run a shell script which runs your command, like: #!/bin/tcsh -f start: mycommand >> /tmp/output sleep 30 goto start As someone else said, cron has a granularity of 1 minute.


3

You can't exec cron with increment less than minute. You can search for other schedulers. Or consider to create daemon which will have internal scheduler for such interval


0

I was able to split $1 and pull out the hour and day part with awk. As its default delimiter is white space, this splits down the cronjob time value nicely. Example value of $1: 0 19 * * 1-5 CRONJOB_HOUR=$(echo "$1" | awk '{ print $2 }') # Second position: 19 CRONJOB_DAY=$(echo "$1" | awk '{ print $5 }') # Fifth position: 1-5 With these parts in a ...


1

I need advice/best practice on how I can avoid keying in passphrase when I add this crontab to run everyday. Create a new ssh key with an empty password, specially for this task. Save it in a file, say, ~/.ssh/cron. Add its corresponding public key to ~/.ssh/authorized_keys on the remote machine. When you run your scp from cron(8) do it with the new ...


0

@Stéphane Chazelas, Thanks for suggestion. I escaped the % with backslash. now its working. Working crontab command is */5 * * * * [ $(( $(date +\%s) / 60 \% 55 )) -eq 0 ] && wget http://localhost/sandbox/run-cron-job


1

First, note that the current directory in a crontab is your home directory. You should put the full path to the script in the crontab. However, since your script is being executed, this isn't the problem. The likely problem is that your script requires an environment variable that is set in your normal session. Cron jobs run with a minimal environment, your ...


2

Your schedule as given is ambiguous, particularly as there are several different cron implementations available on Unix/Linux systems. I would strongly recommend that you specify two ranges to satisfy the wrap-around over midnight (but note that according to Crontab entry with hour range going over midnight the AT&T/BSD cron implementations can't handle ...


0

dhag was on the right lines. It was squirrelmail wrapping the lines, when I exported the email it had no wrapping. Later I found a setting under options, which when I set really high took away the wrapping for my cron job logs. But this has the side effect that now all your emails are not wrapped up to that limit, unless the sender has manual new lines ...


1

Edit your python program and let it check for a 'do not run' file first. If such file exists, exit your program i.e. import os.path if os.path.isfile('/tmp/disable_mypython'): exit() If you check for a file called for instance /tmp/disable_mypython you can easily 'disable' your program using: touch /tmp/disable_mypython and enable it again using: rm ...


3

Generally, stopping and starting the system cron daemon is a bad idea. Commenting out the line isn't always convenient so here are a couple of related alternatives Use a semaphore One solution to this requirement is to use a semaphore - or flag - to indicate whether or not the script is permitted to run. In this instance the semaphore can be represented by ...


1

The simpliest method I can think of is just to edit crontab and comment out the cronjob. Open crontab with: crontab -e And comment out # the line which is your cronjob.


1

Don't kill the cron daemon as it does a lot of tasks which are necessary to the system. Instead, edit the crontab file and comment out the cron job related to your script. (FYI, you do not need to restart the cron daemon after editing that.)


4

Ranges that wrap around like that are ambiguous. Specify the hours as 23,0-6 instead and avoid future problems. Cron checks every minute the contents of crontab files and if it founds coincidence of the time and the conditions it will run the script indicated on the line. For this case these is the set of coincidences that must be met: From 11 PM to ...


1

This will run your job every minute from 11:00pm to 06:59am on the days 1-5 of the week. Here 1 ==> Monday and 5 ==> Friday. However, cron will check that every condition is satisfied and on Friday, it will stop 12 midnight since Saturday is not included in the days. On all other days, it will work fine.


0

At a guess (I'm not a unix expert, but have had a similar issue with cron jobs not running), what user are you executing the task as? Does that user have all the permissions needed to access everything you need? I suspect not (the error sort of says so! :-D ). If you logout from the working user and log in as a different user, does the bash script work ...


1

Assuming that you want to be editing root's crontab, sudo must give you root authority. After it does so, crontab will invoke ${VISUAL:-${EDITOR:-vi}} (it'll use $VISUAL unless it doesn't exist; in that case it'll use $EDITOR unless it doesn't exist; in that case it'll use vi). You have a few possible solutions. They all subvert the security provided by ...


1

00 09 * * * /home/flexsys/test.sh #!/bin/tcsh cd /home/A/B/C/ @ a = 0 while ( $a != 12 ) sleep 5 touch ABC.txt @ a = $a + 1 end This will run your script only once, but it will touch your file 12 times with a 5 seconds pause between each touch. As long as 12*5 is 60, you'll have ...


3

00-01 09 * * * /home/flexsys/test.sh (the job will start at 9:00 and run upto 9:01) That is not what this means. This means the job will run at 9am and run again at 9:01. Cron has no concept of killing jobs, only starting them. As for the while, you need to run the date command, find the number of minutes, and test if it is or isn't 00. On my system ...


1

This is the default (and the only) behavior. It is not explicitly documented, but is implied by systemd's operation logic. systemd.timer(5) reads: For each timer file, a matching unit file must exist, describing the unit to activate when the timer elapses. systemd(1), in turn, describes the concept of unit states and transitions between them: ...


1

If the first argument to the script is jobname and the second is command1 && command2 && command3 then the command you build up in the joined variable is something like command1 && command2 && command3>> /path/to/cron/log/dir/May_12_2015/jobname_2015-05-12_01-09-25.log 2>&1 You call eval on this string, and ...


0

There are two lists of scheduled tasks (crontabs). Each user (including root) has a per-user crontab which they can list with crontab -l and edit with crontab -e. The usual Linux implementation of cron stores these files in /var/spool/cron/crontabs. You shouldn't modify these files directly (run crontab -e as the user instead), but it's safe to list them to ...


0

Global cron entries are often listed in /etc/crontab. For specifics about crontabs and their file locations try man cron and man crontab.


0

May be the jobs were given by other users Try listing as ls -lR /etc/cron*


0

There don't seem to be any well-supported tools in existence for this. I'd say the right way to do this is to build a daemon. You can build a daemon in almost any language you're comfortable with. In Java, for example, you could use quartz to handle the scheduling aspect, and you can find many examples online of how to write a daemon in Java. Python or Perl ...


0

Have you tried third party cron job service like http://www.cronjobservices.com? It allows setting up cron jobs that run every minute.


0

The problem causing the numerous sendmail and postdrop processes is not that they get started by cron, that is normal behaviour. The problem is that those don't terminate almost immediately as usual but continue to run, or rather hang resulting an enormously long process list: /usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t -f root /usr/sbin/sendmail ...


3

No, this is not true. The minimal step is one minute. But depend of service you want to run. Please share more details


7

There's a package for that ;-). As well as cron-apt, which can be configured to perform certain upgrades automatically, another useful package is unattended-upgrades which is designed to safely apply security updates automatically. Beyond that, as Erathiel says it's not safe to run dist-upgrade automatically, but it's safe enough to run it manually every ...


7

sudo apt-get dist-upgrade is very safe to run as it won't do anything to the system, instead stopping to ask for your confirmation ;) You would have to add a -y switch, which is intended for unattended upgrades and makes apt assume that you always answer 'yes' to questions: sudo apt-get -y dist-upgrade. The man page states that If an undesirable ...


0

I have get the same problem in an Ubuntu 14.04 server. And I find error message in /var/log/mail.err, which said: postfix/sendmail[27115]: fatal: open /etc/postfix/main.cf: No such file or directory Then I just reconfigured postfix and solved this problem. sudo dpkg-reconfigure postfix


1

okay - figured it out. Posting back just incase if someone runs into it someday at sometime. The % sign has a special meaning in crontab. it's changed to newline and any string after the first % will be sent to the command as standard input. To force cron to interpret it literally, you have to escape it: 00 18 * * * rsync -a -v --delete -e ssh ...



Top 50 recent answers are included