Cron/ja

このガイドでは、Gentoo Linuxにおけるcronデーモンのセットアップと利用方法を説明しています.

cronとは何か
cronはcrontabコマンドからの入力に基づいてスケジュールされたタスクを起動するためのデーモンです. このタスクは１分毎に起床し、ユーザのcrontabに実行すべきcronジョブがあるかどうかチェックします.

デファクトのcron
Portageにはいくつかのcron実装があります. これらは全てよく似たインタフェースを持っています. つまりcrontabもしくはそれに類似したコマンドを使用します. また、連続動作しないシステムのcronと協調して動作することを意図したanacronと呼ばれる関連ユーティリティもあります.

また、現在利用可能な全てのcronパッケージがに依存していることは協調すべきです. どのcronパッケージも技術的にはこのパッケージには依存していません. しかし、このパッケージは大部分のユーザに有益なcronに似た機能を提供します.

cronを動作させる前に、適切なcron実装が選択されていなければなりません. このガイドでは、Gentoo Linuxで利用可能なcron実装を説明します.

vixie-cron
vixie-cronは、SysV cronベースで全ての機能を実装したcronです. ユーザ毎にcrontabを持ち、その中で環境変数を指定することが可能です. その他のcronと異なり、vixie-cronはSELinuxとPAMをサポートします. サポートするアーキテクチャはdcronよりは少ないですが、fcronよりは多いです.

の特徴


 * SELinuxのサポート
 * PAMのサポート
 * crontabで環境変数を設定可 (PATH、SHELL、HOME等)
 * ユーザ独自のcrontabを持つことが可能. とによるアクセス制御.

cronie
cronie はvixie-cron のフォークで、Fedora で開発されました. そのためオリジナルのvixie-cronと同様の特徴を持ちます. さらに、cronie は anacron 機能も実装しています. この機能を利用するには USEフラグを有効にする必要があります.

dcron (Dillonのcron)
dcronは単純でエレガントでセキュアな実装を目指しています. crontabでの環境変数の設定はできません. すべてのcronジョブをから実行します. vixie-cronと同じように、それぞれのユーザがそれぞれのcrontabを設定可能です.

の特徴


 * 速い、単純、不要な仕様がない.
 * crontab へのアクセスを、例えば cron グループに所属するユーザだけに制限することができる. つまり、外部機能に依存しない.

fcron
fcronはvixie-cronとanacronの置き換えを意図しています. 連続動作しないシステムで動作できるよう設計されていて、いくつかの外部機能を持っています. それは「ジョブがスタートするための条件設定」、「ジョブのシリアライゼーションの制御」、「ジョブにnice値を付与する機能」、「システム起動時に動作するジョブのスケジュール」です. さらに詳細な情報についてはfcron's home pageを参照してください.

の特徴


 * 連続動作しないシステムで動作するようデザインされています. つまり、システム停止中に動作できなかったジョブは、再起動後に実行可能です.
 * 環境変数やその他多くのオプションをcrontabで設定できます.
 * 多くの新機能と共に拡張されたcrontab記述をサポートします.
 * 各ユーザーはそれぞれ、とでアクセス制御可能なcrontabを持つことができます.

bcron
bronはセキュアなオペレーションを念頭に置いて設計された新しいcronシステムです. これを実現するため、cronシステムはいくつかのプログラムに分割され、分割されたタスクそれぞれが役割をもちました. また、それらプログラムおよびタスク間のコミュニケーションは厳格に制御されました. ユーザインターフェースは、よく似たシステム（例 vixie-cron）の単純な置き換えですが、内部の実装は大きく異なっています. より詳細な情報についてはbcronのホームページhttp://untroubled.org/bcronを参照ください.

の特徴


 * vixie-cronの単純置き換え
 * マルチプロセス設計
 * 地域毎の夏時間サポート

anacron
anacronはcronデーモンそのものではなく、cronデーモンと組み合わせて動作するものです. anacronは指定された間隔でコマンドを実行し、システムが連続的に稼働することを前提とせず、シャットダウンの間に実行されるべきだったジョブを改めて実行します. 通常、anacronはそれぞれの日に動作するcronデーモンに依存しています.

インストール
目的にあった適切なcronを選択し、emergeしてください.

選択されたcronデーモンがシステムのinitプロセスに追加されたことを確認してください. これを実行しないとcronデーモンはジョブを開始しません.

オプションとして、fcronがインストールしていなければ、cronデーモンのヘルパーとしてanacronをインストールすることは良い選択です.

再度、anacronをシステムのinitプロセスに確実に加えてください.

システムcrontab
これらcronパッケージをインストールした後のメッセージにおいて、ユーザーはcrontab /etc/crontabを実行するよう促されるでしょう. このファイルがシステムcrontabです. cronのインストールはに記載されたスクリプトを実行するために、システムcrontabをと共に使用します. ここでvixie-cronとcronieだけがに記述するだけで自動的にジョブを実行することに留意してください. dcronとfcronのユーザーは、を変更するたびにcrontab /etc/crontabを実行する必要があります.

さらにシステムcrontabで予約されたジョブは、crontab -lで示されるcronジョブのリストにおそらく現れないことを記載しておきます.

もちろん、ユーザはシステムcrontabをまったく使用しない選択をすることも可能です. システムcrontabを使用しない場合、かつdcronかfcronを使用している場合は、crontab /etc/crontabを実行してはいけません. vixie-cron、cronie、bcronを使っている場合はの全ての行をコメントアウトして下さい.

このコメントアウトを最も簡単に実施する方法は、以下のsedコマンドをファイルの全ての行に適用することです. 次のコマンドでの全ての行をコメントアウトして下さい.

信頼できるユーザーにcronへのアクセス権を与える
root以外でcronデーモンにアクセスしたいユーザーはこのセクションを参考にしてください. そうでない場合は次のセクションScheduling cron-jobsに進んで下さい.

選択したcronパッケージに関わらず、あるユーザーにcrontabへのアクセスを許可する場合、そのユーザはcronグループに所属しなければなりません. 例としてユーザ"wepy"をグループに追加するコマンドは以下となります.

When using dcron, the above step is all that is needed to give a user access to crontab. Dcron users may proceed to the next section Scheduling cron-jobs, all others need to keep reading.

When using fcron, edit the and  files. The most secure way to run a system is to first deny all users in, and then explicitly allow users in.

If a user (wepy again for this example) should be able to schedule his own cron-jobs, then add him to as follows:

If vixie-cron or cronie has been chosen, then simply edit the file.

For example, to allow access to the user wepy, add him to as follows:

Scheduling cron-jobs
The process of editing crontabs is different for each package, but they all support the same basic set of commands: adding and replacing crontabs, editing crontabs, deleting crontabs, and listing cron-jobs in crontabs. The following list shows how to run various commands for each package.

Before any of these commands can be used, first understanding of the crontab itself is needed. Each line in a crontab specifies five time fields in the following order: the minutes (0-59), hours (0-23), days of the month (1-31), months (1-12), and days of the week (0-7, Monday is day 1, Sunday is day 0 and day 7). The days of the week and months can be specified by three-letter abbreviations like mon, tue, jan, feb, etc. Each field can also specify a range of values (e.g. 1-5 or mon-fri), a comma separated list of values (e.g. 1,2,3 or mon,tue,wed) or a range of values with a step (e.g. 1-6/2 as 1,3,5).

That sounds a little confusing, but with a few examples it is easy to see it is not as complicated as it sounds.

To test what was just covered go through the steps of actually inputting a few cron-jobs. First, create a file called and make it look like the this:

Now add that crontab to the system with the "new command" from the table above.

To verify the scheduled cron-jobs, use the proper list command from the table above.

A list resembling should be displayed; if not maybe the wrong command was issued to input the crontab.

This crontab should echo "I really like cron" every minute of every hour of every day every other month. Obviously a user would only do that if they really liked cron. The crontab will also echo "I like cron a little" at 16:30 every day in January and February. It will also echo "I don't really like cron" at 3:10 on the January 1st.

If using anacron keep reading this section. Otherwise, proceed to the next section on Editing crontabs.

Anacron users will want to edit. This file has four fields: the number of days between each run, the delay in minutes after which it runs, the name of the job, and the command to run.

For example, to have it run echo "I like anacron" every 5 days, 10 minutes after anacron is started, enter the following:

Anacron exits after all of the jobs in anacrontab have finished. To check to see if these jobs should be performed every day, a cron daemon will be used. The instructions at the end of the next section explain how this should be handled.

Editing crontabs
Being realistic, no user would want their system telling them how much they like cron every minute. As a step forward, remove the previous example crontab using the corresponding remove command from the table above. Use the corresponding list command to view the cron-jobs afterward to make sure it worked.

No cron-jobs should be displayed in the output from crontab -l</tt>. If cron jobs are listed, then the remove command failed to remove the crontab; verify the correct remove command for the system's cron package.

Now that we have a clean state, let's put something useful into the root crontab. Most people will want to run updatedb</tt> on a weekly basis to make sure that mlocate works properly. To add that to the system's crontab, first edit again so that it looks like the following:

That would make cron run updatedb at 2:22 A.M. on Monday morning every week. Now input the crontab with the proper new command from the table above, and check the list again.

Now let's say emerge --sync</tt> should be ran on a daily schedule in order to keep the Portage tree up to date. This could be done by first editing and then using crontab crons.cron</tt> as was done in the example above, or by using the proper edit command from the table above. This provides a way to edit the user's crontab in situ, without depending on external files like.

The above command should open the user's crontab with an editor. For example, if emerge --sync</tt> is to be run every day at 6:30 A.M., make the crontab look something like this:

Again, check the cron-jobs list as done in the previous examples to make sure the jobs are scheduled. If they are all there, then the system is ready to rock and roll.

Using cronbase
As mentioned earlier, all of the available cron packages depend on. The cronbase package creates, and a script called. Notice the default file contains something like this:

To avoid going into much detail, assume these commands will effectively run hourly, daily, weekly and monthly scripts. This method of scheduling cron-jobs has some important advantages:


 * They will run even if the computer was off when they were scheduled to run;
 * It is easy for package maintainers to place scripts in those well defined places;
 * The administrators know exactly where the cron-jobs and crontab are stored, making it easy to backup and restore these parts of their systems.

Using anacron
As mentioned earlier, anacron is used on systems not meant to be run continuously (like most of the desktop installations). Its default configuration file,, is usually similar to the following:

The main difference between this and other common crontabs is that with anacron there is no fixed date/hour for the job scheduling, but only the period between every run. When anacron is started, it will check the contents of a set of files in and calculate if the corresponding entry in the configuration file has expired since the last run. If it has, then the command is invoked again.

As a final note, it is important to comment out any overlapping entry in any other cron installed in the system, such as in the following vixie-cron crontab example:

Without doing this, the daily, weekly and monthly parts will be executed - at different times - by both the cron daemon and anacron, leading to possible double job executions.

Final Notes
Remember, each cron package is different and the range of features varies greatly. Be sure to consult the man pages for crontab, fcrontab or anacrontab, depending on which cron daemon has been used.

Good luck!

トラブルシューティング
When having problems getting cron to work properly, this quick checklist might be helpful.

Is cron running?
To verify that cron is running, see if it shows up in the process list:

Is cron working?
Try the following:

Then check if is modified periodically.

Is the command working?
Same as before, but perhaps redirect the standard error output as well:

Can cron run the job?
Check the cron log, usually or  for errors.

Are there any s?
cron usually sends mail when there is a problem; check for mail and look for the creation of a file.

Cronの代替
Some hosting companies do not allow access to cron, but many cron jobs alternatives can be found which are free or commercially available:


 * EasyCron