When your computer is shut down (or the cron daemon is otherwise not running), cron jobs will not be started.
If you have jobs that you would like to run after the fact during those times when the computer is shut down, use anacron. Installed by default, see "man anacron", "man anacrontab", or the file /etc/anacrontab for more info.
Ubuntu uses anacron by default for crontab entries in:
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
leaving the remaining crontabs to be handled by the main cron daemon, specifically:
/etc/crontab
/etc/cron.d
/var/spool/cron
NOTES
Anacron itself does not run as a daemon, but relies on system startup scripts and cron itself to run.
On the Ubuntu 8.04 box I'm looking at, /etc/init.d/anacron is run at boot, and again by cron each morning at 07:30.
The README at /usr/share/doc/anacron/README.gz has a slight bit more info than is contained in the manpages.
EXAMPLES
For simple "daily", "weekly", "monthly" jobs, put a copy of or a symlink to the script in one of the /etc/cron.{daily|weekly|monthly} directories above. Anacron will take care of running it daily/weekly/monthly, and if your computer is off on the day the "weekly" scripts would normally run, it'll run them the next time the computer is on.
As another example, assuming you have a script here: /usr/local/sbin/maint.sh
And you wish to run it every three days, the standard entry in /etc/crontab would look like this:
# m h dom mon dow user command
0 0 */3 * * root /usr/local/sbin/maint.sh
If your computer was not on at 00:00 on the 3rd of the month, the job would not run until the 6th.
To have the job instead run on the 4th when the computer is off and "misses" the run on the 3rd, you'd use this in /etc/anacrontab (don't forget to remove the line from /etc/crontab):
# period delay job-identifier command
3 5 maint-job /usr/local/sbin/maint.sh
The "delay" of "5" above means that anacron will wait for 5 minutes before it runs this job. The idea is to prevent anacron from firing things off immediately at boot time.
(1) I see that each of the running processes occupies a very small percentage of memory (%MEM no more than 0.2%, and most just 0.0%), but how the total memory is almost used as in the fourth line of output ("Mem: 130766620k total, 130161072k used, 605548k free, 919300k buffers")? The sum of used percentage of memory over all processes seems unlikely to achieve almost 100%, doesn't it?
To see how much memory you are currently using, run free -m
. It will provide output like:
total used free shared buffers cached
Mem: 2012 1923 88 0 91 515
-/+ buffers/cache: 1316 695
Swap: 3153 256 2896
The top row 'used' (1923) value will almost always nearly match the top row mem value (2012). Since Linux likes to use any spare memory to cache disk blocks (515).
The key used figure to look at is the buffers/cache row used value (1316). This is how much space your applications are currently using. For best performance, this number should be less than your total (2012) memory. To prevent out of memory errors, it needs to be less than the total memory (2012) and swap space (3153).
If you wish to quickly see how much memory is free look at the buffers/cache row free value (695). This is the total memory (2012)- the actual used (1316). (2012 - 1316 = 696, not 695, this will just be a rounding issue)
(2) how to understand the load average on the first line ("load average: 14.04, 14.02, 14.00")?
This article on load average uses a nice traffic analogy and is the best one I've found so far: Understanding Linux CPU Load - when should you be worried?. In your case, as people pointed out:
On multi-processor system, the load is relative to the number of processor cores available. The "100% utilization" mark is 1.00 on a single-core system, 2.00, on a dual-core, 4.00 on a quad-core, etc.
So, with a load average of 14.00 and 24 cores, your server is far from being overloaded.
Best Answer
The primary problem is that there is no proper
$PATH
defined in the run environment of cron, so you need to use the full path toservice
for this to work.You can find out this path with the command
which service
, which should print something like/usr/sbin/service
.The secondary problem: I wouldn't do that, just blindly restarting services on a production system is never a good idea. Do you have an actual memory/performance problem or might it be that your RAM is just used up by buffers and the like (see http://www.linuxatemyram.com/)?
Please add the output of
free -m
after a few hours to your question.