Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to run a pretty simple script (is there a dir with name x in dir y if so move it to dir z–and x will only be there about once a day) every 15 seconds or so (one minute divided into 4*15 seconds). Does running cron jobs like that (where the scripts they run are not resource intensive) have a non-neglible negative impact on performance, stability or anything else?

share|improve this question
up vote 4 down vote accepted

To answer the question in the title, no, most system do not experience much of a burden from running cron jobs. Much of the automated tasks that occur on a modern Unix system are kicked off by cron jobs.

Things such as rotating logs, and regenerating index files used by man are all kicked off via cron jobs.

If you're curious take a look in any of the directories under /etc/cron*. There are bound to be examples there which will shed light on how these things are accomplished on your system.

share|improve this answer
thanks for your thorough answer! – user36719 Nov 3 '13 at 18:22
@TorThommesen - you're welcome, thanks for the Q. – slm Nov 3 '13 at 18:22

First the minimum resolution for cron is 1 minute. So every 15 seconds isn't going to happen. If you really need every 15 seconds then you need to re-think your strategy.

Next, cron just runs tasks at a certain time. If the task is resource intensive then it will be in cron as well. If it's not then it won't be. cron adds (almost) NO overhead what so ever, because of the way it hands off the command to be run.

Finally running a task via cron every 1 minute is rather silly. Anacron (which runs back log cron tasks from when your computer is down, or sleeping) will run all the tasks in sequence when it thinks it needs to.

You will be much better served by running that task every 1 minute around the time the file should show up. Or even once ever 10 mins.

There is no need to run the task 1,440 times just to catch a file that you know is only going to be there once a day.

If your task is so critical that it sees that file instantly then use something else. Otherwise I advise slowing down the task frequency to something more tuned to your needs.

That being said, if you really want to use cron for this, it won't add any more overhead then just running it via command line, but man will your email box be full.

share|improve this answer

The correct tool to use in this case is called inotify. It is a part of the linux kernel, and its purpose is to notify programs of changes to filesystems. It can be configured in a number of different ways, and is almost certainly suitable for what you are trying to do.

share|improve this answer
And of course there is incron, which is a cron-like daemon which uses inotify. – derobert Nov 4 '13 at 16:11
I will probably use this instead. :) – user36719 Nov 4 '13 at 21:34

Often-spawned processes are always a risk of resources starving for the system, but precautions measures (such as limits) can be put as well.

P. S. In case you're really keen on efficiency for this very task you can use inotify approach instead.

share|improve this answer
inotify seems intereting, thanks! – user36719 Nov 3 '13 at 18:19
@TorThommesen - search within this site for examples: unix.stackexchange.com/search?q=inotify – slm Nov 3 '13 at 18:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.