シェルを作るときに気にする

2重起動防止 pidファイルの確認 プロセス起動確認

を「/etc/init.d/functions」を使って実装してみる。

. /etc/init.d/functions SCRIPT_NAME=testscript PID_FILE=/var/run/${SCRIPT_NAME} # 起動の確認 ここで一気に確認 pidofproc ${SCRIPT_NAME} if [ $? -eq 0 ]; then echo “プロセスは既に起動しています” exit 1 fi # pidファイルが残っている場合の処理 if [ -f ${PID_FILE} ]; then echo “プロセスは停止していますがPIDファイルが存在します” echo “${PID_FILE}を削除します” rm -f ${PID_FILE} fi touch ${PID_FILE} echo $$ > ${PID_FILE} # 以下処理・・・

if [ "$str" == "false" ];then #明るい緑 [ "$BOOTUP" = "color" ] && $SETCOLOR_SUCCESS echo “I’m fujihara” [ "$BOOTUP" = "color" ] && $SETCOLOR_NORMAL else #赤 [ "$BOOTUP" = "color" ] && $SETCOLOR_FAILURE echo “I’m fujihara” [ "$BOOTUP" = "color" ] && $SETCOLOR_NORMAL fi

スクリプトをバックグラウンドで動作するデーモンとして登録する方法。
「/etc/init.d/crond」を参考に調べた。

ここで使われるフォルダは以下になる。

/proc ・・・プロセス情報が入っている /var/lock/subsys ・・・ lockファイル作成ディレクトリ /var/run ・・・ プロセスIDが書かれたファイルを書き出す場所 /etc/init.d/functions

「/etc/init.d/functions」にはデーモンの制御に便利なシェル関数が書かれている。プロセスの確認、開始メッセージ表示など、普通のシェルでも使える内容になっている。

checkpid PID

指定されたPIDで起動していれば0、それ以外は1。「/proc」以下にPIDのフォルダがあるかで判断している。

daemon {+/-nicelevel} {program}

プログラムを開始する。

killproc [-d delay] {program} [signal]

プログラムを停止する。「/var/run」にあるPIDファイルは削除してくれる

pidfileofproc {program}

プログラムのPIDをみつける。「/var/run/{program}.pidのみ確認する。
PIDファイルがあれば0・・・なんだろうけど、return 1をしていないため、絶対0がかえってしまう。バグ？
以下の文で、PIDが不正かどうかチェックしている。

# First try “/var/run/*.pid” files if [ -f /var/run/$base.pid ] ; then local line p pid= read line < /var/run/$base.pid for p in $line ; do [ -z "${p//[0-9]/}” -a -d /proc/$p ] && pid=”$pid $p” done if [ -n "$pid" ]; then echo $pid return 0 fi fi

プロセスIDを確認する以下の部分では、まず0から9の数値をすべて空文字におきかえることができるかと、/proc/にプロセスIDのフォルダが存在するかで確認している。

[ -z "${p//[0-9]/}” -a -d /proc/$p ] && pid=”$pid $p”

プロセスIDが空文字の場合はのちの「if [ -n "$pid" ]; then」で引っかかる。

pidofproc {program}

プログラムのPIDをみつける。「/var/run/{program}.pidをまず探し、それでなければ「pidof」コマンドを使って探す。存在すれば0を返す。それ以外は1。

status {program}

プログラムのステータスを確認する。

echo_success

成功メッセージ表示。

[...]

シェルをかくときに 、そのシェルがどこで動くかを考えなければならない。
例えば、「/tmp/fujihara/sh」にtest.shを作ったとする。テストシェルは「mkidr ./logs」コマンドでログ用のフォルダを自動で作る。
現在「/tmp」にいるとして、このスクリプトを「./fujihara/sh/test.sh」とたたけば、「/tmp/logs」ができる。しかし、「/tmp/fujihara/sh」にいて「./test.sh」とたたけば、「/tmp/fujihara/sh/logs」ができる。
このように、ユーザの位置によって、作るフォルダなどがかわってくると管理が大変。あちこちに一時フォルダができたりしてしまう。「実行場所に作業フォルダやシェルの結果ファイルなどを作る」というポリシーがなければ、シェルのいる場所に作るようにスクリプトをしておいたほうがいいと思った。

シェルの置かれているパスを取得する

シェルの中では「$0」に実行されたコマンドが入る。「/tmp/fujihara/sh/test.sh」だったり「./sh/test.sh」する。これだと「`dirname $0`」としても絶対パスか相対パスか確定できないので、以下のコマンドを使う。

which $0

これで「/tmp/fujihara/sh/test.sh」のような絶対パスが取れる。あとはdirnameコマンドで、ディレクトリまでを取得すればOK。

SHPATH=`which $0` REALDIR=`dirname $SHPATH`

viを覚えるのを嫌がってから数ヶ月。おかげで、viの文字検索までできるようになった。シェルを使うようになって気がついたことなどをメモ。

基本の基本 シェルは「fujihara.sh」みないな名前だけど、拡張子は関係ない シェルの頭には「#!/bin/bash」とおまじないをかく 実行権限を「chmod +x fujihara.sh」みたいにつけないと動かない 改行コードはLFになる

上記をおぼえたら、シェルを書き始めることができるようになった。

基本 2重起動のことを考えなければならない カレントディレクトリと、シェル本体が置かれるディレクトリは異なる可能性がある。シェルが実行される場所を意識しなければならない バックグラウンドで動かす場合は止めることも考えなければならない 標準出力等をログに出している場合は、ログのサイズが大きくならないようにlogrotateなどを考慮しなければならない

上記を覚えたら、最低限考えることがわかった。