Cron と Anacron の違い
- 2014/02/17
- 20:03
日医標準レセプトソフト (ORCA) という日医総研が作ったレセプトソフトがあります。
僕が務める病院でも ORCA を使っており、このサーバは Ubuntu OS (Ubuntu 12.04) 上で動作します。このレセコン、個人的には安定性が高いと思っていましたが、ここ連日 「定期的 （早朝） に ORCA サーバとの通信が途絶える」 という現象が発生していました。
結論からいうと、これは 「anacron」 という仕組みが関係していました。
その後、anacron の設定を変更してからというもの、前述のような現象は起こらなくなりました。しかし anacron ってナンジャラホイ、cron とは違うの？ それよりも anaconda （Red Hat 系のインストーラ） と読み間違えて混乱しちゃったじゃないか。。。
ということから、今回は cron と anacron についてのメモでございます。
ORCA の暫定処置
cron や anacron の調査を始める前に、冒頭の 「定期的 （早朝） に ORCA サーバとの通信が途絶える」 の解決方法の詳細を以下にメモします。
現象：
毎朝の決まった時間帯に、日レセクライアントと ORCA サーバの接続が切れてしまう。しかし、それ以降は翌朝まで ORCA サーバとの切断が切れることはない。
↑図1：通常の ORCA 業務
原因：
主従構成時に anacron がログローテートを行うと、スクリプトの記述により ORCA サーバを再起動される。このとき日レセクライアントから ORCA サーバに接続していると、ORCA サーバとの通信が切断されえてしまう。
↑図2：ログローテート時に ORCA Server が再起動して切断される
解決法：
/etc/cron.d/anacron ファイルのタスク開始時間を2時間ずらした （医事課職員が ORCA サーバに接続しない時間帯にログローテートさせるため）。
変更前：30 7 * * * root start -q anacron || :
変更後：30 5 * * * root start -q anacron || :
↑図3：ORCA Server に接続しないタイミングにログローテートさせる
上記の設定を施してからかれこれ1か月以上が経ちますが、今のところ接続が切断されるような問題は再発していません。ただし、この設定を施した当時は 暫定的 でしたので、この設定が果たして正しいのかは分からずにいました。
そして今回、ようやく cron / anacron をメモする機会が訪れましたので、上記の設定が正しいか否かを判断しながらメモしていこうと思います。
Cron とは
まず cron （なんと“クーロン” と読みます） についてメモしていきます。
cron とは、ユーザが記述したコマンドやシェルを あらかじめ決められた時間に自動実行してくれるプログラム です。Windows でいう 「タスクスケジューラ」 をイメージして頂けると分かりやすいと思います。
このプログラム、例えばこんなときに役立ちます。
「毎週金曜の深夜0時にデータベースのバックアップを取得する」 といった業務を任命された、会社に花金を奪われてしまった とてつもなく不幸なエンジニアがいたとします。可哀相なことに、そのエンジニアは DB のバックアップを取得するためだけに、金曜の夜遅くまでサーバの前に張りついておらねばなりません（もちろん DB バックアップは大切ですが…）。
そんなエンジニアを救ってくれるのが、この cron (を含むタスクスケジューラ系プログラム） です。
cron は 「指定した時間に、指定したコマンドを実行」 してくれるプログラムですので、cron に対して 「毎週金曜の00時00分に DB バックアップを取得しろ」 と記述するだけで、エンジニアの代わりに cron が DB バックアップを取得してくれます。素晴らしいことに、このエンジニアは cron のおかげで 失った花金を取り戻せるのです。
↑図4：この気持ち、わかりません？ (´・ω・｀)
「いつの時代だ」 というツッコミは無用でございます （笑）。
このように cron やタスクスケジューラは、サーバ管理者にとって心強い味方です。残念ながら今の僕は cron を扱う業務に携わっていないので、cron をまだまだ使いこなせていません。ですが、いつか cron を使うだろう日のために、今のうちから簡単に触っておこうと思います。
crontab の記述
さっそく cron を触っていきます。
まず crond にジョブを処理させるには、「crontab -e」 コマンドから crontab ファイルを編集します。この crontab には 「ジョブを実行させる時間 ＋ ジョブ内容」 という形式で記述し、時間は最小 分単位 の詳細な指定ができます。
上記の例では 「15 20 * * *」 と表記していますが、これは左から順に 「分、時、日、月、曜日」 を意味しています。
分 … 0～59 （n 分に実行）
時 … 0～23 （n 時に実行）
日 … 1～31 （n 日に実行）
月 … 1～12 （n 月に実行）
曜日 … 0～6 （0=日曜日、1=月曜日 … 6=土曜日）
これら数字と順番を組み合わせることで、ジョブを処理する時間を選びます。また 「*」 は 全て を意味しますので、上記のコマンド 15 20 * * * shutdown -h now は 「毎日、20時15分に PC をシャットダウンする」 という意味になりますね。
では問題ですが、以下のようなコマンドを crontab に記述したら、どういう動きになるでしょうか？
………。
これは 「毎分、パソコンを再起動する」 という意味で、PC 再起動の無限ループ を表しています。
普通の人ならこういったコマンドは打たないでしょうけど、僕は見事に打ちました。 初めて cron の動作確認をしたとき、「cron の動作を一目でわかるコマンドは……そうだ reboot だ！」 と思いつき、何も考えずに上記のジョブを記述。気づいたときには時すでに遅しでした。。
crontab の記述を削除するには 「crontab -r」 ですから、上記の再起動ループにハマっていたときは 「PC 起動 → root ログイン → crontab -r コマンドをタイプ」 を一分一秒でも早く打たなければなりませんでした。このときほど （もっとタイピング速度が早ければ…） と悔いたことはありませんでした。。
↓crontab を削除するコマンド
↓crontab の内容を表示させるコマンド
基本的な crontab の記述方法は、たったのこれだけです。もっと厳密に書くとするなら、以下のような 「範囲指定、連続指定、間隔指定」 などもできますが、基本的には 「実行する時間 ＋ 実行するコマンド」 という形式で記述します。
もっと気の利いた例 （コマンド） を書ければよかったのですが、恥ずかしながらコマンドに関しても未熟者なので、大目に見てやってくださいまし…ｗ (///)
↓毎月5日、15日、25日の 21時05分 にテキストファイルを生成 （カンマで間隔指定）
↓12時30分～35分に1分ごとにスクリプトを実行する （ハイフンで範囲指定）
さて、上記のジョブはそれぞれ間隔指定と範囲指定を記述したものですが、実はそれ以外にも注目すべきところがあります。それは 「実行ユーザー」 です。間隔指定した上の例では プロンプトが # ですから root ユーザの実行だということが分かりますが、範囲指定した下の例では プロンプトが $ なので、一般ユーザ （genchan ユーザ） の実行です。
ここは結構重要です。なぜなら crontab は1つではなく、ユーザ毎に用意されているからです。
root ユーザが 「# crontab -e」 を実行すれば、root ユーザ用の crontab が作成され、genchan ユーザが 「$ crontab -e」 を実行すれば、genchan ユーザ用の crontab が生成されます。なお、これらユーザ毎の crontab ファイルは 「/var/spool/cron/」 ディレクトリの配下にユーザ名で保存されます。
なお crontab -r は crontab を削除するコマンドですが、これは crontab ファイルの実体が削除されるようですね。
↑図5：ユーザ毎に crontab が存在する
一般的に crontab の編集は、その crontab の所有権を持つユーザが行うようですが、その都度ユーザを切り替えるのは手間なので、「# crontab -u genchan」 といった -u オプションを用いることで、他ユーザの crontab を扱えます。
ただ root ユーザで genchan ユーザの crontab を生成した場合の 所有権とグループ が root のままになっていました。僕自身まだ 「アクセス権、所有権やグループ」 のことを理解しきれていないので、これは今後の課題となりそうです。
/etc/crontab
/var/spool/cron ディレクトリに、ユーザ毎の crontab ファイルがあることをメモしました。
しかし、ややこしいことに crontab ファイルはもう一つありました。それは 「/etc/crontab」 です。なんで2つあんのさ……と crontab ファイルを覗いてみたところ、そこには system-wide crontab という文字が…。
ということは、システム全体に影響するジョブ に関しては /etc/crontab で指定し、それ以外のユーザ毎に影響するジョブは /var/spool/cron/ の crontab に指定する、ということですね （と信じたい）。
↑図6：Ubuntu 12.04 の /etc/crontab
↑図7：CentOS 6.3 の /etc/crontab。記述例があってわかりやすい。
※ちなみに今回の記事では Ubuntu Desktop 12.04 と CentOS 6.3 の 2つの cron を触りながらメモしております。今回の目的は 「cron のイメージを掴むこと」 ですので、細かな相違点 （ディレクトリ構成など） はガン無視しています。 今回のメモはコマンドリファレンスとしては 全く参考にならない ことを自負しておりますので、ご注意くださいまし （手抜きｗ）。
それでは /etc/crontab について話を戻します。
ユーザごとの crontab は crontab -e あるいは vi /var/spool/cron/root コマンドで編集できましたが、/etc/crontab の場合は 「vi /etc/crontab」 で編集します。なおシステム全体を影響する crontab なので、編集できるユーザは root ユーザのみに限られます。
このことが関係して /etc/crontab は crontab -e とは記述方式が若干ことなります。crontab -e では 「時刻 ＋ コマンド」 の形式でジョブを指定しますが、/etc/crontab では 「時刻 ＋ ユーザ ＋ コマンド」 という形式で記述します。
↓/var/spool/cron/root
↓/etc/crontab
では、ここで Ubuntu Desktop 12.04 の /etc/crontab にデフォルトで記述されているジョブの動きをトレースしてみます。 図6 でいう 11 行目が簡単そうなので、そこを見てみましょう。
まず 図6 の 11 行目には、以下の一行が記載されています。
「17 * * * * root」 までは前述したとおりで、「毎時17分に root ユーザでコマンドを実行する」 という意味になります。ではどんなコマンドを実行するのかというと、「cd / && run-parts --report /etc/cron.hourly」 というコマンドを実行します。
この run-parts コマンドは 「指定したディレクトリ配下のプログラムを全て実行する」 というコマンドのため、動作としては 「ルートディレクトリに移動したのち、/etc/cron.hourly ディレクトリ配下に保存されたプログラムを実行」 という流れになりますね。もし毎時実行させたいプログラムがあったなら、そのプログラムを実行させるスクリプトを記述し、この /etc/cron.hourly ディレクトリに保存することで、対象のプログラムを毎時実行させることができます。
あと /etc ディレクトリには、他にも以下のような cron 関連のディレクトリが存在します。用途と実行時間に応じて、好きなディレクトリにスクリプトを入れると良さそうです。
/etc/cron.hourly/ … 毎時実行のスクリプト保存場所
/etc/cron.daily/ … 毎日実行のスクリプト(ry
/etc/cron.weekly/ … 毎週実行の(ry
/etc/cron.monthly … 毎月(ry
↑図8：run-parts コマンドによってディレクトリ配下のスクリプトが実行
Ubuntu や CentOS では、/etc/cron.hourly ディレクトリは空っぽのようです。確かに1時間おきに実行するジョブって、あまり思い浮かばないですね。
さてさて、ここで 1行 ほど下の 12行目 に目をやると、何やら新しいキーワードが……。
ここでついに来ました。。
「anacron」 という輝か……しくないこのキーワード。このキーワードのおかげで、ワタクシはどれだけ頭を抱え、そして OSC （ORCA サポートセンター） に迷惑をかけたことか。。…とはいっても、anacron という存在を僕が最初から知っていれば、こんなに苦労することは無かったですよね。そういう意味でも、anacron について次項メモしていきます。
Anacron とは
cron と anacron の 違いが分かる男 になるためにも、以下メモしていきます。
まず cron はジョブをスケジュール通りに実行するのが特徴ですが anacron は少し違います。anacron では指定したスケジュール時間に加え、「ランダム時間」 をプラスしてジョブを実行します。また cron では1日に何回でもジョブを実行させられますが、anacron では1日に 最高でも1回 しかジョブを実行させられません。
こうみると anacron のメリットを感じられないかもしれませんが、こういった仕組みによって cron では実現できない 「ジョブを実行し損ねた際のジョブ再実行」 が可能になります （cron でも厳密には実現できるでしょうが、余計なスクリプトを組む手間を省くといった意味が含まれます）。
cron 特徴
・指定したスケジュール時間通りにジョブを実行する
・1日に何回でもジョブを実行できる
・ユーザごとにスケジュール登録が可能
→いわゆるマニュアル人間ｗ
anacron 特徴
・指定したスケジュール時間にランダム時間をプラスしてジョブを実行する
・1日に最高1回しかジョブを実行できない
・管理者のみスケジュール登録が可能
→融通の利く人 （僕はどっちだろう…）
「ジョブを実行し損ねたときのジョブ再実行」 について、図4 を参考にもう少し詳しくメモします。図4 では 「土曜（金曜深夜）の 0:00 に DB をバックアップする」 といった業務が発生しています。
cron でこの業務を行ないますと /etc/crontab に 「0 0 * * 6 root "DB バックアップ処理"」 を記述することで、金曜深夜 0:00 に DB バックアップを取得してくれます。エンジニアはサーバの前に張りついていなくとも、思う存分に花金を楽しんでいられます。
ところが、もしジョブを実行する時間に crond が起動していなかった場合があったとします。
たとえば 0:00 にジョブを実行するはずが、23:55 になんらかの原因 （瞬停など） により サーバに予期せぬ再起動処理 が走ってしまい、再びサーバが起動したのが翌 0:05 だとすると、ジョブが実行されるはずの 0:00 には crond が立ち上がっていません ので、DB バックアップ （ジョブ） が取得できていないことになります。しかも cron はスケジュール通りにしかジョブを実行しないことから、DB バックアップの取得成功の有無にかかわらず、次のジョブ開始時間まで DB バックアップを再実行することはありません。
↑図9：バックアップの未取得に気づかず翌日泣くパターン
もちろん実際には DB バックアップが取得できなかったことをエンジニアが気づくでしょうから、その都度バックアップすれば多少の問題はないでしょう。けれどもこういった定期的な自動バックアップ処理って、（まぁバックアップ取れてるから大丈夫っしょ…） とチェックが甘くなるんですよねぇ…。少なくとも僕の性格ではチェックが甘くなっていました。。。
そこで役立つのが anacron です。
同じシチュエーションで cron がジョブを実行するはずの 0:00 に crond が停止しており、0:05 には crond が立ち上がったとします。cron ではスケジュールが過ぎていますからジョブを再実行できませんが、ここで anacron が有効になっていると、cron が実行し損ねた DB バックアップ処理を anacron が代わりに走らせてくれます。動きとして、anacron には ジョブの実行履歴を確認するといった特性がありますので、そこからジョブの実行有無を確認できるようです。
↑図10：anacron によって cron が実行し損ねたジョブを再実行してくれる
なお cron にスケジュールを登録するには /etc/crontab ファイルを編集する必要がありますが、anacron は /etc/anacrontab を編集します。次は anacrontab の記述方法と、その流れについて追っていきましょう。
/etc/anacrontab
/etc/crontab と同様 /etc/anacrontab は root 権限のみ編集が可能です。そういったことから anacron はシステム全体に影響するジョブを担当することがわかりますね。
↑図11：CentOS 6.3 の /etc/anacrontab
上図は CentOS 6 の anacrontab の記述内容です。こう見ると crontab（図7） と記述方式が全く異なることが見て取れると思いますね。では、以下から一行ずつ紐解いていきます。
↓/etc/anacrontab
左から順に 「1 5 cron.daily nice run-parts /etc/cron.daily」 と記述されています。一番右側の 「nice run-parts /etc/cron.daily」 は、なんとなく分かりますね。これがスケジュールの条件に合致したとき anacron が実行するジョブのコマンドです。
これらは左から 「period in days」 「delay in minutes」 「job-identifier」 「command」 を意味しています。図11の /etc/anacrontab の画像を見て頂けると分かります。
period in days … ジョブの実行頻度
delay in minutes … ジョブ実行の遅延時間
job-identifier … ジョブの実行時間 （タイムスタンプ） を記録するファイル名
Commando … シュワルツェネッガーの映画 (///)
period in days は、ジョブの実行頻度を表しています。anacron は1日1回以上のジョブを実行できないので、ここに指定した数字がそのまま日数になります。1 なら1日おき、7 なら1週間おき、といった具合です。「@」 を付け足して @daily や @weekly といった記述も可能です。@monthly を使えばうるう年対策にもなりそうですね。
job-identifier は、ジョブを実行した時間を記録するファイル名を表しています。たとえば 2014年3月4日 にジョブが実行されると、anacron はこのファイルに実行した日付を YYYYMMDD 形式で書き込みます。後述もしますが anacron は このファイルに書かれた日付を参照してジョブの再実行を判断します。
Commando に関しては……まぁいいですよね。あえて触れません (//ω//)
Delay in minutes は、ランダム時間を表しています。
anacron ではジョブを実行するの時間を迎えたとき delay in minutes に記述した分数が経過して、ようやくジョブを実行する仕組みになっています。例えば 0:00 をスケジュールしたとして、delay in minutes に5分を設定していれば 0:05 にジョブを実行するといったイメージです。
しかしジョブ実行のタイミングは delay in minutes の記述だけでは決まらず、「RANDOM_DELAY」 と 「START_HOURS_RANGE」 の2つの変数が大きく影響してきます。（……頭の回転が遅いぼかぁ、この二つの理解にとんでもなく時間を喰いました。。。）
RANDOM_DELAY … ランダム時間の上限値
START_HOURS_RANGE … ジョブの実行を許可する時間範囲
デフォルト （図11） では RANDOM_DELAY=45 が設定されています。これはランダム時間の上限値の分数を意味しており、一方の下限値はデフォルトで6分です。ここでは 45 が記述されていますので、6分～45分のランダム時間内にジョブが実行されることになります。
先ほどの例 （0:00にジョブ実行＋delay in minutes が 5 ） で RANDOM_DELAY=45 を設定されていた場合、ジョブを実行するランダム時間は delay in minutes （5分） ＋ RANDOM_DELAY のデフォルト下限値 （6分） を足し合わせた11分 （0:11） から RANDOM_DELAY の上限値 （45分） の 0:50 までということですね。
↑図12：ランダム時間をおいての実行
次に START_HOURS_RANGE ですが、これはジョブが実行できる時間帯を意味しています。同じく図11の例では、この変数に 3-22 が設定されており、意味としては 「3時～22時の間にジョブの実行ができる」 ということです。前述の例では 0:00 がジョブを実行する時間でしたが、 START_HOURS_RANGE が 3-22 となっていると 0:00 は範囲外ということになりますので、実際の実行時間は 3:11 ～ 3:50 となります。
↑図13：ジョブを実行する期間
cron のときはピンポイントなスケジュールを組めましたが、anacron では以上のようなランダム時間を持たせたスケジュールを組むことができます。……まとめているのに、まだ頭が混乱している。。。
↓とっても参考になったサイト様 (めもめも様)
http://d.hatena.ne.jp/enakai00/20111004/1317718773
anacrontab の実行
anacron が実行されるまでの流れを書きます。
まず crond は 1秒毎に crontab にジョブの有無を確認しに行きます。このとき crond が参照する crontab は、システム全体に影響する /etc/crontab とユーザ毎の /var/spool/cron の2種類がありますが、もう一つ /etc/cron.d/ ディレクトリ配下にも crontab が存在します。
/etc/cron.d/ 配下を見てみると、そこには 0hourly といった crontab がありました。
その 0houry スクリプトの中身を覗いてみると、以下のような一行が記載されています。
上記の内容は 「毎時1分に /etc/cron.hourly ディレクトリ配下にあるスクリプトを全て実行する」 といった意味となります。ここの指定によって /etc/cron.hourly ディレクトリのスクリプトが毎時実行されるのですね。
次に /etc/cron.hourly ディレクトリですが、そこには 0anacron というスクリプトファイルが存在します。
このスクリプトファイルには以下のような記述がされています。
↑図14：anacron を実行するスクリプト
このスクリプトを順に読んでいきます。
「if test -r /var/spool/anacron/cron.daily」 の条件式があります。これは対象のファイルが存在して、かつ読み込める場合は true という意味です。この /var/spool/anacron/cron.daily ファイルには、anacron が最後に実行された日が YYYYMMDD 形式で記録されています。動きとしては、cron.daily ファイルが存在する場合は、その中に記述された最終実行日を day 変数に代入しているイメージですね。
次に、以下の行です。
「`date +%Y%m%d`」 は、今現在の日付を YYYYMMDD 形式で抽出することを意味しており、それと cron.daily ファイルのジョブ最終実行日を比較しています。ということは anacron が実行されていれば exit 0 で処理を終え、まだ実行されていなければ else で次の処理へ進むということになります。
次は以下のこの行ですが、こちらはあまり意味がないらしいです。よってスキップさせて下さい。
本来ならしっかりとスクリプトを読んで意味を把握するべきなのですが、ぼかぁ コードリーディングアレルギー なので、大目に見て下さいまし。。
そして最後の一行です。
この一行で anacron が実行されます。
これが実行されたとき、前項でメモしたスケジュールに従ってランダム時間後にジョブが実行されます。
以上が anacron 実行までの道のりです。
自分なりのメモなのでとっても分かりづらく書いてしまいましたが、以下のサイト様ではフローチャート形式で本項を解説しています。もっと詳細に知りたい方は、ぜひともご覧になって下さい。僕の書いた文章とは比べ物にならないくらい、メッチャ見やすいっすｗ
↓とっても参考になったサイト様 (OSSはアルミニウムの翼で飛ぶ 様)
http://aikotobaha.blogspot.jp/2011/02/rhel6-7cronanacron.html
ORCA 再起動のネタ晴らし
最後に、本メモを書くきっかけとなった ORCA のログローテートについて追ってみます。
冒頭にも書きましたが、その場しのぎの解決策として 「/etc/cron.d/anacron ファイルのタスク開始時間を2時間ずらした」 と書きました。さて、果たしてこれが正しいのか、そこを意識して以下をメモしていきます。
まず Ubuntu Desktop 12.04 /etc/cron.d/ ディレクトリ配下を覗いてみると、anacron という名の crontab がおりました。
この anacron を開いてみると、以下のような一行がありました。
「30 7」 がデフォルトのスケジュールですが、僕はここの数値を 「30 5」 に変更しています。7:30 に実行するものを、5:30 にジョブを実行する、という意味になりますね。5:30 を迎えたときに anacron の処理が実行されます。
そのとき crond が実行する （であろう） コマンドが /etc/anacrontab の 9行目 に記載されていました。
「/etc/anacrontab」 のメモ （前々項） にも書きましたが、ここではランダム時間が経過した後に /etc/cron.daily ディレクトリ配下のスクリプトを実行する動きになります。
/etc/cron.daily ディレクトリを覗いてみると、いくつかのファイルが存在していますが、その中のひとつに logrotate というスクリプトファイルが存在しました （ls の結果は省略しています）。
この logrotate スクリプトファイルをリーディングし………たいのはヤマヤマなのですが、前述したとおり僕はコードリーディングアレルギーなので、ここに関しては 「とりあえずログローテートが動く」 と妥協させて下さいまし。。。(´；ω；`)
ログローテートが動きますと /etc/logrotate.d ディレクトリ配下のスクリプトファイルが実行されますが、このディレクトリを ls してみると、jma-receipt というスクリプトファイルが出てきます （ls の結果は省略しています）。
なにやら近づいてきましたゾ…。
そしてこの jma-receipt スクリプトファイルを開いてみた結果が、以下でございます。
こやつか！！
……と、いう感じでございます （笑）。
以上のことから、今回 ORCA のログローテート時にサービスが再起動してしまう件については、 「/etc/cron.d/anacron ファイルのタスク開始時間を2時間ずらした」 という適当に施した設定が あながち間違いではない ということのようです。
うむ、奇跡じゃｗ ヽ(^ω^ )ノ
最後に
この日医標準レセプトソフト (ORCA) ですが、実はこのソフトには 資格 があります。
その名も 「日医総研日医IT認定制度」 というモノで、以下の 2種類 の試験が年に1回開催されています。
・日医認定システム主任者 （主に Linux の知識を問う資格）
・日医認定インストラクター （主に ORCA や医療知識を問う資格）
インストラクター試験に関してはよく分かりませんが、僕が勤務する病院の医事課さんたちが取得しています。一方でシステム主任者試験に関しては……なにを隠そう僕は コノ試験の合格者でございます。
すげぇじゃん！
――と思うでしょうが、これには驚愕の裏話があります。
この試験、「午前の筆記試験」 と 「午後の実技試験」 があるのですが……。
なんとワタクシ、午後の実技試験の ある操作方法をド忘れする というあり得ないボンミスを発動。
その結果、 午後試験 0点 （回答用紙未提出、途中退席）。
でも、合格しました。
たぶん、大人の事情 があるのでしょうね。。。
しかしながら、ORCA は今後どんどん市場に出てくると思います。
今はこんなノリで合格できた試験ですが、ORCA の知名度が上がればもっと難易度が高くなるでしょう。
そういう意味では、今のうちに取得しておくべき資格ですね。機会があれば、みな様もぜひ！！
僕が務める病院でも ORCA を使っており、このサーバは Ubuntu OS (Ubuntu 12.04) 上で動作します。このレセコン、個人的には安定性が高いと思っていましたが、ここ連日 「定期的 （早朝） に ORCA サーバとの通信が途絶える」 という現象が発生していました。
結論からいうと、これは 「anacron」 という仕組みが関係していました。
その後、anacron の設定を変更してからというもの、前述のような現象は起こらなくなりました。しかし anacron ってナンジャラホイ、cron とは違うの？ それよりも anaconda （Red Hat 系のインストーラ） と読み間違えて混乱しちゃったじゃないか。。。
ということから、今回は cron と anacron についてのメモでございます。
ORCA の暫定処置
cron や anacron の調査を始める前に、冒頭の 「定期的 （早朝） に ORCA サーバとの通信が途絶える」 の解決方法の詳細を以下にメモします。
現象：
毎朝の決まった時間帯に、日レセクライアントと ORCA サーバの接続が切れてしまう。しかし、それ以降は翌朝まで ORCA サーバとの切断が切れることはない。
↑図1：通常の ORCA 業務
原因：
主従構成時に anacron がログローテートを行うと、スクリプトの記述により ORCA サーバを再起動される。このとき日レセクライアントから ORCA サーバに接続していると、ORCA サーバとの通信が切断されえてしまう。
↑図2：ログローテート時に ORCA Server が再起動して切断される
解決法：
/etc/cron.d/anacron ファイルのタスク開始時間を2時間ずらした （医事課職員が ORCA サーバに接続しない時間帯にログローテートさせるため）。
変更前：30 7 * * * root start -q anacron || :
変更後：30 5 * * * root start -q anacron || :
↑図3：ORCA Server に接続しないタイミングにログローテートさせる
上記の設定を施してからかれこれ1か月以上が経ちますが、今のところ接続が切断されるような問題は再発していません。ただし、この設定を施した当時は 暫定的 でしたので、この設定が果たして正しいのかは分からずにいました。
そして今回、ようやく cron / anacron をメモする機会が訪れましたので、上記の設定が正しいか否かを判断しながらメモしていこうと思います。
Cron とは
まず cron （なんと“クーロン” と読みます） についてメモしていきます。
cron とは、ユーザが記述したコマンドやシェルを あらかじめ決められた時間に自動実行してくれるプログラム です。Windows でいう 「タスクスケジューラ」 をイメージして頂けると分かりやすいと思います。
このプログラム、例えばこんなときに役立ちます。
「毎週金曜の深夜0時にデータベースのバックアップを取得する」 といった業務を任命された、会社に花金を奪われてしまった とてつもなく不幸なエンジニアがいたとします。可哀相なことに、そのエンジニアは DB のバックアップを取得するためだけに、金曜の夜遅くまでサーバの前に張りついておらねばなりません（もちろん DB バックアップは大切ですが…）。
そんなエンジニアを救ってくれるのが、この cron (を含むタスクスケジューラ系プログラム） です。
cron は 「指定した時間に、指定したコマンドを実行」 してくれるプログラムですので、cron に対して 「毎週金曜の00時00分に DB バックアップを取得しろ」 と記述するだけで、エンジニアの代わりに cron が DB バックアップを取得してくれます。素晴らしいことに、このエンジニアは cron のおかげで 失った花金を取り戻せるのです。
↑図4：この気持ち、わかりません？ (´・ω・｀)
「いつの時代だ」 というツッコミは無用でございます （笑）。
このように cron やタスクスケジューラは、サーバ管理者にとって心強い味方です。残念ながら今の僕は cron を扱う業務に携わっていないので、cron をまだまだ使いこなせていません。ですが、いつか cron を使うだろう日のために、今のうちから簡単に触っておこうと思います。
crontab の記述
さっそく cron を触っていきます。
まず crond にジョブを処理させるには、「crontab -e」 コマンドから crontab ファイルを編集します。この crontab には 「ジョブを実行させる時間 ＋ ジョブ内容」 という形式で記述し、時間は最小 分単位 の詳細な指定ができます。
| # crontab -e 15 20 * * * shutdown -h now |
上記の例では 「15 20 * * *」 と表記していますが、これは左から順に 「分、時、日、月、曜日」 を意味しています。
分 … 0～59 （n 分に実行）
時 … 0～23 （n 時に実行）
日 … 1～31 （n 日に実行）
月 … 1～12 （n 月に実行）
曜日 … 0～6 （0=日曜日、1=月曜日 … 6=土曜日）
これら数字と順番を組み合わせることで、ジョブを処理する時間を選びます。また 「*」 は 全て を意味しますので、上記のコマンド 15 20 * * * shutdown -h now は 「毎日、20時15分に PC をシャットダウンする」 という意味になりますね。
では問題ですが、以下のようなコマンドを crontab に記述したら、どういう動きになるでしょうか？
| # crontab -e * * * * * reboot |
………。
これは 「毎分、パソコンを再起動する」 という意味で、PC 再起動の無限ループ を表しています。
普通の人ならこういったコマンドは打たないでしょうけど、僕は見事に打ちました。 初めて cron の動作確認をしたとき、「cron の動作を一目でわかるコマンドは……そうだ reboot だ！」 と思いつき、何も考えずに上記のジョブを記述。気づいたときには時すでに遅しでした。。
crontab の記述を削除するには 「crontab -r」 ですから、上記の再起動ループにハマっていたときは 「PC 起動 → root ログイン → crontab -r コマンドをタイプ」 を一分一秒でも早く打たなければなりませんでした。このときほど （もっとタイピング速度が早ければ…） と悔いたことはありませんでした。。
↓crontab を削除するコマンド
| # crontab -r |
↓crontab の内容を表示させるコマンド
| # crontab -l |
基本的な crontab の記述方法は、たったのこれだけです。もっと厳密に書くとするなら、以下のような 「範囲指定、連続指定、間隔指定」 などもできますが、基本的には 「実行する時間 ＋ 実行するコマンド」 という形式で記述します。
もっと気の利いた例 （コマンド） を書ければよかったのですが、恥ずかしながらコマンドに関しても未熟者なので、大目に見てやってくださいまし…ｗ (///)
↓毎月5日、15日、25日の 21時05分 にテキストファイルを生成 （カンマで間隔指定）
| # 05 21 5,15,25 * * touch /root/test.txt |
↓12時30分～35分に1分ごとにスクリプトを実行する （ハイフンで範囲指定）
| $ 30-35 12 * * * /home/genchan/db_backup.sh |
さて、上記のジョブはそれぞれ間隔指定と範囲指定を記述したものですが、実はそれ以外にも注目すべきところがあります。それは 「実行ユーザー」 です。間隔指定した上の例では プロンプトが # ですから root ユーザの実行だということが分かりますが、範囲指定した下の例では プロンプトが $ なので、一般ユーザ （genchan ユーザ） の実行です。
ここは結構重要です。なぜなら crontab は1つではなく、ユーザ毎に用意されているからです。
root ユーザが 「# crontab -e」 を実行すれば、root ユーザ用の crontab が作成され、genchan ユーザが 「$ crontab -e」 を実行すれば、genchan ユーザ用の crontab が生成されます。なお、これらユーザ毎の crontab ファイルは 「/var/spool/cron/」 ディレクトリの配下にユーザ名で保存されます。
なお crontab -r は crontab を削除するコマンドですが、これは crontab ファイルの実体が削除されるようですね。
↑図5：ユーザ毎に crontab が存在する
一般的に crontab の編集は、その crontab の所有権を持つユーザが行うようですが、その都度ユーザを切り替えるのは手間なので、「# crontab -u genchan」 といった -u オプションを用いることで、他ユーザの crontab を扱えます。
ただ root ユーザで genchan ユーザの crontab を生成した場合の 所有権とグループ が root のままになっていました。僕自身まだ 「アクセス権、所有権やグループ」 のことを理解しきれていないので、これは今後の課題となりそうです。
/etc/crontab
/var/spool/cron ディレクトリに、ユーザ毎の crontab ファイルがあることをメモしました。
しかし、ややこしいことに crontab ファイルはもう一つありました。それは 「/etc/crontab」 です。なんで2つあんのさ……と crontab ファイルを覗いてみたところ、そこには system-wide crontab という文字が…。
ということは、システム全体に影響するジョブ に関しては /etc/crontab で指定し、それ以外のユーザ毎に影響するジョブは /var/spool/cron/ の crontab に指定する、ということですね （と信じたい）。
↑図6：Ubuntu 12.04 の /etc/crontab
↑図7：CentOS 6.3 の /etc/crontab。記述例があってわかりやすい。
※ちなみに今回の記事では Ubuntu Desktop 12.04 と CentOS 6.3 の 2つの cron を触りながらメモしております。今回の目的は 「cron のイメージを掴むこと」 ですので、細かな相違点 （ディレクトリ構成など） はガン無視しています。 今回のメモはコマンドリファレンスとしては 全く参考にならない ことを自負しておりますので、ご注意くださいまし （手抜きｗ）。
それでは /etc/crontab について話を戻します。
ユーザごとの crontab は crontab -e あるいは vi /var/spool/cron/root コマンドで編集できましたが、/etc/crontab の場合は 「vi /etc/crontab」 で編集します。なおシステム全体を影響する crontab なので、編集できるユーザは root ユーザのみに限られます。
このことが関係して /etc/crontab は crontab -e とは記述方式が若干ことなります。crontab -e では 「時刻 ＋ コマンド」 の形式でジョブを指定しますが、/etc/crontab では 「時刻 ＋ ユーザ ＋ コマンド」 という形式で記述します。
↓/var/spool/cron/root
| * * * * * reboot |
↓/etc/crontab
| * * * * * root reboot |
では、ここで Ubuntu Desktop 12.04 の /etc/crontab にデフォルトで記述されているジョブの動きをトレースしてみます。 図6 でいう 11 行目が簡単そうなので、そこを見てみましょう。
まず 図6 の 11 行目には、以下の一行が記載されています。
| 17 * * * * root cd / && run-parts --report /etc/cron.hourly |
「17 * * * * root」 までは前述したとおりで、「毎時17分に root ユーザでコマンドを実行する」 という意味になります。ではどんなコマンドを実行するのかというと、「cd / && run-parts --report /etc/cron.hourly」 というコマンドを実行します。
この run-parts コマンドは 「指定したディレクトリ配下のプログラムを全て実行する」 というコマンドのため、動作としては 「ルートディレクトリに移動したのち、/etc/cron.hourly ディレクトリ配下に保存されたプログラムを実行」 という流れになりますね。もし毎時実行させたいプログラムがあったなら、そのプログラムを実行させるスクリプトを記述し、この /etc/cron.hourly ディレクトリに保存することで、対象のプログラムを毎時実行させることができます。
あと /etc ディレクトリには、他にも以下のような cron 関連のディレクトリが存在します。用途と実行時間に応じて、好きなディレクトリにスクリプトを入れると良さそうです。
/etc/cron.hourly/ … 毎時実行のスクリプト保存場所
/etc/cron.daily/ … 毎日実行のスクリプト(ry
/etc/cron.weekly/ … 毎週実行の(ry
/etc/cron.monthly … 毎月(ry
↑図8：run-parts コマンドによってディレクトリ配下のスクリプトが実行
Ubuntu や CentOS では、/etc/cron.hourly ディレクトリは空っぽのようです。確かに1時間おきに実行するジョブって、あまり思い浮かばないですね。
さてさて、ここで 1行 ほど下の 12行目 に目をやると、何やら新しいキーワードが……。
| 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) |
ここでついに来ました。。
「anacron」 という輝か……しくないこのキーワード。このキーワードのおかげで、ワタクシはどれだけ頭を抱え、そして OSC （ORCA サポートセンター） に迷惑をかけたことか。。…とはいっても、anacron という存在を僕が最初から知っていれば、こんなに苦労することは無かったですよね。そういう意味でも、anacron について次項メモしていきます。
Anacron とは
cron と anacron の 違いが分かる男 になるためにも、以下メモしていきます。
まず cron はジョブをスケジュール通りに実行するのが特徴ですが anacron は少し違います。anacron では指定したスケジュール時間に加え、「ランダム時間」 をプラスしてジョブを実行します。また cron では1日に何回でもジョブを実行させられますが、anacron では1日に 最高でも1回 しかジョブを実行させられません。
こうみると anacron のメリットを感じられないかもしれませんが、こういった仕組みによって cron では実現できない 「ジョブを実行し損ねた際のジョブ再実行」 が可能になります （cron でも厳密には実現できるでしょうが、余計なスクリプトを組む手間を省くといった意味が含まれます）。
cron 特徴
・指定したスケジュール時間通りにジョブを実行する
・1日に何回でもジョブを実行できる
・ユーザごとにスケジュール登録が可能
→いわゆるマニュアル人間ｗ
anacron 特徴
・指定したスケジュール時間にランダム時間をプラスしてジョブを実行する
・1日に最高1回しかジョブを実行できない
・管理者のみスケジュール登録が可能
→融通の利く人 （僕はどっちだろう…）
「ジョブを実行し損ねたときのジョブ再実行」 について、図4 を参考にもう少し詳しくメモします。図4 では 「土曜（金曜深夜）の 0:00 に DB をバックアップする」 といった業務が発生しています。
cron でこの業務を行ないますと /etc/crontab に 「0 0 * * 6 root "DB バックアップ処理"」 を記述することで、金曜深夜 0:00 に DB バックアップを取得してくれます。エンジニアはサーバの前に張りついていなくとも、思う存分に花金を楽しんでいられます。
ところが、もしジョブを実行する時間に crond が起動していなかった場合があったとします。
たとえば 0:00 にジョブを実行するはずが、23:55 になんらかの原因 （瞬停など） により サーバに予期せぬ再起動処理 が走ってしまい、再びサーバが起動したのが翌 0:05 だとすると、ジョブが実行されるはずの 0:00 には crond が立ち上がっていません ので、DB バックアップ （ジョブ） が取得できていないことになります。しかも cron はスケジュール通りにしかジョブを実行しないことから、DB バックアップの取得成功の有無にかかわらず、次のジョブ開始時間まで DB バックアップを再実行することはありません。
↑図9：バックアップの未取得に気づかず翌日泣くパターン
もちろん実際には DB バックアップが取得できなかったことをエンジニアが気づくでしょうから、その都度バックアップすれば多少の問題はないでしょう。けれどもこういった定期的な自動バックアップ処理って、（まぁバックアップ取れてるから大丈夫っしょ…） とチェックが甘くなるんですよねぇ…。少なくとも僕の性格ではチェックが甘くなっていました。。。
そこで役立つのが anacron です。
同じシチュエーションで cron がジョブを実行するはずの 0:00 に crond が停止しており、0:05 には crond が立ち上がったとします。cron ではスケジュールが過ぎていますからジョブを再実行できませんが、ここで anacron が有効になっていると、cron が実行し損ねた DB バックアップ処理を anacron が代わりに走らせてくれます。動きとして、anacron には ジョブの実行履歴を確認するといった特性がありますので、そこからジョブの実行有無を確認できるようです。
↑図10：anacron によって cron が実行し損ねたジョブを再実行してくれる
なお cron にスケジュールを登録するには /etc/crontab ファイルを編集する必要がありますが、anacron は /etc/anacrontab を編集します。次は anacrontab の記述方法と、その流れについて追っていきましょう。
/etc/anacrontab
/etc/crontab と同様 /etc/anacrontab は root 権限のみ編集が可能です。そういったことから anacron はシステム全体に影響するジョブを担当することがわかりますね。
↑図11：CentOS 6.3 の /etc/anacrontab
上図は CentOS 6 の anacrontab の記述内容です。こう見ると crontab（図7） と記述方式が全く異なることが見て取れると思いますね。では、以下から一行ずつ紐解いていきます。
↓/etc/anacrontab
| 1 5 cron.daily nice run-parts /etc/cron.daily |
左から順に 「1 5 cron.daily nice run-parts /etc/cron.daily」 と記述されています。一番右側の 「nice run-parts /etc/cron.daily」 は、なんとなく分かりますね。これがスケジュールの条件に合致したとき anacron が実行するジョブのコマンドです。
これらは左から 「period in days」 「delay in minutes」 「job-identifier」 「command」 を意味しています。図11の /etc/anacrontab の画像を見て頂けると分かります。
period in days … ジョブの実行頻度
delay in minutes … ジョブ実行の遅延時間
job-identifier … ジョブの実行時間 （タイムスタンプ） を記録するファイル名
Commando … シュワルツェネッガーの映画 (///)
period in days は、ジョブの実行頻度を表しています。anacron は1日1回以上のジョブを実行できないので、ここに指定した数字がそのまま日数になります。1 なら1日おき、7 なら1週間おき、といった具合です。「@」 を付け足して @daily や @weekly といった記述も可能です。@monthly を使えばうるう年対策にもなりそうですね。
job-identifier は、ジョブを実行した時間を記録するファイル名を表しています。たとえば 2014年3月4日 にジョブが実行されると、anacron はこのファイルに実行した日付を YYYYMMDD 形式で書き込みます。後述もしますが anacron は このファイルに書かれた日付を参照してジョブの再実行を判断します。
Commando に関しては……まぁいいですよね。あえて触れません (//ω//)
Delay in minutes は、ランダム時間を表しています。
anacron ではジョブを実行するの時間を迎えたとき delay in minutes に記述した分数が経過して、ようやくジョブを実行する仕組みになっています。例えば 0:00 をスケジュールしたとして、delay in minutes に5分を設定していれば 0:05 にジョブを実行するといったイメージです。
しかしジョブ実行のタイミングは delay in minutes の記述だけでは決まらず、「RANDOM_DELAY」 と 「START_HOURS_RANGE」 の2つの変数が大きく影響してきます。（……頭の回転が遅いぼかぁ、この二つの理解にとんでもなく時間を喰いました。。。）
RANDOM_DELAY … ランダム時間の上限値
START_HOURS_RANGE … ジョブの実行を許可する時間範囲
デフォルト （図11） では RANDOM_DELAY=45 が設定されています。これはランダム時間の上限値の分数を意味しており、一方の下限値はデフォルトで6分です。ここでは 45 が記述されていますので、6分～45分のランダム時間内にジョブが実行されることになります。
先ほどの例 （0:00にジョブ実行＋delay in minutes が 5 ） で RANDOM_DELAY=45 を設定されていた場合、ジョブを実行するランダム時間は delay in minutes （5分） ＋ RANDOM_DELAY のデフォルト下限値 （6分） を足し合わせた11分 （0:11） から RANDOM_DELAY の上限値 （45分） の 0:50 までということですね。
↑図12：ランダム時間をおいての実行
次に START_HOURS_RANGE ですが、これはジョブが実行できる時間帯を意味しています。同じく図11の例では、この変数に 3-22 が設定されており、意味としては 「3時～22時の間にジョブの実行ができる」 ということです。前述の例では 0:00 がジョブを実行する時間でしたが、 START_HOURS_RANGE が 3-22 となっていると 0:00 は範囲外ということになりますので、実際の実行時間は 3:11 ～ 3:50 となります。
↑図13：ジョブを実行する期間
cron のときはピンポイントなスケジュールを組めましたが、anacron では以上のようなランダム時間を持たせたスケジュールを組むことができます。……まとめているのに、まだ頭が混乱している。。。
↓とっても参考になったサイト様 (めもめも様)
http://d.hatena.ne.jp/enakai00/20111004/1317718773
anacrontab の実行
anacron が実行されるまでの流れを書きます。
まず crond は 1秒毎に crontab にジョブの有無を確認しに行きます。このとき crond が参照する crontab は、システム全体に影響する /etc/crontab とユーザ毎の /var/spool/cron の2種類がありますが、もう一つ /etc/cron.d/ ディレクトリ配下にも crontab が存在します。
/etc/cron.d/ 配下を見てみると、そこには 0hourly といった crontab がありました。
その 0houry スクリプトの中身を覗いてみると、以下のような一行が記載されています。
| 01 * * * * root run-parts /etc/cron.hourly |
上記の内容は 「毎時1分に /etc/cron.hourly ディレクトリ配下にあるスクリプトを全て実行する」 といった意味となります。ここの指定によって /etc/cron.hourly ディレクトリのスクリプトが毎時実行されるのですね。
次に /etc/cron.hourly ディレクトリですが、そこには 0anacron というスクリプトファイルが存在します。
このスクリプトファイルには以下のような記述がされています。
↑図14：anacron を実行するスクリプト
このスクリプトを順に読んでいきます。
| if test -r /var/spool/anacron/cron.daily; then day=`cat /var/spool/anacron/cron.daily` fi |
「if test -r /var/spool/anacron/cron.daily」 の条件式があります。これは対象のファイルが存在して、かつ読み込める場合は true という意味です。この /var/spool/anacron/cron.daily ファイルには、anacron が最後に実行された日が YYYYMMDD 形式で記録されています。動きとしては、cron.daily ファイルが存在する場合は、その中に記述された最終実行日を day 変数に代入しているイメージですね。
次に、以下の行です。
| if [ `date +%Y%m%d` = "$day" ]; then exit 0; fi |
「`date +%Y%m%d`」 は、今現在の日付を YYYYMMDD 形式で抽出することを意味しており、それと cron.daily ファイルのジョブ最終実行日を比較しています。ということは anacron が実行されていれば exit 0 で処理を終え、まだ実行されていなければ else で次の処理へ進むということになります。
次は以下のこの行ですが、こちらはあまり意味がないらしいです。よってスキップさせて下さい。
本来ならしっかりとスクリプトを読んで意味を把握するべきなのですが、ぼかぁ コードリーディングアレルギー なので、大目に見て下さいまし。。
| if test -x /usr/bin/on_ac_power; then /usr/bin/on_ac_power &> /dev/null if test $? -eq 1; then exit 0 fi fi |
そして最後の一行です。
| /usr/sbin/anacron -s |
この一行で anacron が実行されます。
これが実行されたとき、前項でメモしたスケジュールに従ってランダム時間後にジョブが実行されます。
以上が anacron 実行までの道のりです。
自分なりのメモなのでとっても分かりづらく書いてしまいましたが、以下のサイト様ではフローチャート形式で本項を解説しています。もっと詳細に知りたい方は、ぜひともご覧になって下さい。僕の書いた文章とは比べ物にならないくらい、メッチャ見やすいっすｗ
↓とっても参考になったサイト様 (OSSはアルミニウムの翼で飛ぶ 様)
http://aikotobaha.blogspot.jp/2011/02/rhel6-7cronanacron.html
ORCA 再起動のネタ晴らし
最後に、本メモを書くきっかけとなった ORCA のログローテートについて追ってみます。
冒頭にも書きましたが、その場しのぎの解決策として 「/etc/cron.d/anacron ファイルのタスク開始時間を2時間ずらした」 と書きました。さて、果たしてこれが正しいのか、そこを意識して以下をメモしていきます。
まず Ubuntu Desktop 12.04 /etc/cron.d/ ディレクトリ配下を覗いてみると、anacron という名の crontab がおりました。
| gen@chan:~$ ls /etc/cron.d/ anacron |
この anacron を開いてみると、以下のような一行がありました。
| 30 7 * * * root start -q anacron || : |
「30 7」 がデフォルトのスケジュールですが、僕はここの数値を 「30 5」 に変更しています。7:30 に実行するものを、5:30 にジョブを実行する、という意味になりますね。5:30 を迎えたときに anacron の処理が実行されます。
そのとき crond が実行する （であろう） コマンドが /etc/anacrontab の 9行目 に記載されていました。
| 1 5 cron.daily nice run-parts --repost /etc/cron.daily |
「/etc/anacrontab」 のメモ （前々項） にも書きましたが、ここではランダム時間が経過した後に /etc/cron.daily ディレクトリ配下のスクリプトを実行する動きになります。
/etc/cron.daily ディレクトリを覗いてみると、いくつかのファイルが存在していますが、その中のひとつに logrotate というスクリプトファイルが存在しました （ls の結果は省略しています）。
| gen@chan:~$ ls /etc/cron.daily 0anacron apt dpkg logrotate standard |
この logrotate スクリプトファイルをリーディングし………たいのはヤマヤマなのですが、前述したとおり僕はコードリーディングアレルギーなので、ここに関しては 「とりあえずログローテートが動く」 と妥協させて下さいまし。。。(´；ω；`)
ログローテートが動きますと /etc/logrotate.d ディレクトリ配下のスクリプトファイルが実行されますが、このディレクトリを ls してみると、jma-receipt というスクリプトファイルが出てきます （ls の結果は省略しています）。
| gen@chan:~$ ls /etc/logrotate.d/ apt cups dpkg jma-receipt ufw upstart |
なにやら近づいてきましたゾ…。
そしてこの jma-receipt スクリプトファイルを開いてみた結果が、以下でございます。
| /var/lib/jma-receipt/dbredirector/*.log { rotate 6 daily compress missingok postrotate /etc/init.d/jma-receipt restart 2>&1 >/dev/null endscript } |
こやつか！！
……と、いう感じでございます （笑）。
以上のことから、今回 ORCA のログローテート時にサービスが再起動してしまう件については、 「/etc/cron.d/anacron ファイルのタスク開始時間を2時間ずらした」 という適当に施した設定が あながち間違いではない ということのようです。
うむ、奇跡じゃｗ ヽ(^ω^ )ノ
最後に
この日医標準レセプトソフト (ORCA) ですが、実はこのソフトには 資格 があります。
その名も 「日医総研日医IT認定制度」 というモノで、以下の 2種類 の試験が年に1回開催されています。
・日医認定システム主任者 （主に Linux の知識を問う資格）
・日医認定インストラクター （主に ORCA や医療知識を問う資格）
インストラクター試験に関してはよく分かりませんが、僕が勤務する病院の医事課さんたちが取得しています。一方でシステム主任者試験に関しては……なにを隠そう僕は コノ試験の合格者でございます。
すげぇじゃん！
――と思うでしょうが、これには驚愕の裏話があります。
この試験、「午前の筆記試験」 と 「午後の実技試験」 があるのですが……。
なんとワタクシ、午後の実技試験の ある操作方法をド忘れする というあり得ないボンミスを発動。
その結果、 午後試験 0点 （回答用紙未提出、途中退席）。
でも、合格しました。
たぶん、大人の事情 があるのでしょうね。。。
しかしながら、ORCA は今後どんどん市場に出てくると思います。
今はこんなノリで合格できた試験ですが、ORCA の知名度が上がればもっと難易度が高くなるでしょう。
そういう意味では、今のうちに取得しておくべき資格ですね。機会があれば、みな様もぜひ！！
スポンサーサイト
