【Linux CentOS 6.9 64bit】 同じパスで指定されるスクリプトが同時に実行されないようにする方法について

この内容は古いです。

もっと良い方法があります。
http://akira-arets.blogspot.jp/2018/04/linux-centos-duplicatestartprohibition.html


以下のようなテストスクリプトを作成した。
#ここから、#ここまで　で示されるコードが、同時実行を防止する機能を持っている。
それ以外は、動作検証／デバッグ用である。

動作検証のため、sleep 70sを最後に置き、実行状態が70秒間、継続するようにした。

# cat /root/Python/webtest/com/test01.sh

#!/bin/sh

echo "PATH  is  $0"

echo "PPID is $PPID"
echo "PID is $$"

cmdline=`/bin/cat /proc/$$/cmdline`
echo "/proc/$$/cmdline  is  $cmdline"


#ここから、判定ルーチン

# コマンドラインで指定したパス名 $0 を検索キーにして、既に動作中のプロセスを検索し、最も古いプロセスのIDを取得する。 
psnum=`pgrep -fo "$0"`

# 取得した最古のプロセスIDと、自身のプロセスIDとを比較する。
# 一致しなければ、同一パス名 $0 で呼び出されたプロセスが他に既に存在しているため、二重起動を防止し中断する。

if [ "$$" != "$psnum"  ] ; then
        echo "no"     # 既に同じパスで指定されるスクリプトは起動中である。（二重起動防止のため中断）
        exit 1
fi

echo "ok"             #同じパスで指定されるスクリプトは起動していない。（さらに処理を継続）
#ここまで

echo "pgrep -fo $0  is  $psnum"
sleep 70s

cronでこのスクリプトが実行されるようにパスを指定して設定した。
# crontab -e

*/1     *       *       *       *       /root/Python/webtest/com/test01.sh

そして、cronによって実行されたスクリプトの結果を確認した。 
# tail /var/mail/root

PATH  is  /root/Python/webtest/com/test01.sh
PPID is 4166
PID is 4168
/proc/4168/cmdline  is  /bin/sh/root/Python/webtest/com/test01.sh
ok
pgrep -fo /root/Python/webtest/com/test01.sh  is  4168

このとき、まだ他で動作しているスクリプトはない。
このPIDは、4168　になった。
コマンドライン（/root/Python/webtest/com/test01.sh）をキーとしpgrepで取得したPIDは、4168　になった。
一致していることから、 /root/Python/webtest/com/test01.sh　はただ一つしか動作していないことがわかった。（ok）



sleep 70s が効いてプロセスが存在しているうちに、上記と同じパスでスクリプトを直接実行した。
# /root/Python/webtest/com/test01.sh

PATH  is  /root/Python/webtest/com/test01.sh
PPID is 4134
PID is 4174
/proc/4174/cmdline  is  /bin/sh/root/Python/webtest/com/test01.sh
no
pgrep -fo /root/Python/webtest/com/test01.sh  is  4168

このPIDは、4174　になった。
コマンドライン（/root/Python/webtest/com/test01.sh）をキーとしpgrepで取得したPIDは、4168（cronから実行されているスクリプトのPID）　になった。

一致しないことから、 /root/Python/webtest/com/test01.sh　は、別のプロセスとして動作中であることがわかった。（no）



さらに、コマンドラインが別のものになるようにして、同じスクリプトを起動した。
# ./test01.sh

PATH  is  ./test01.sh
PPID is 4134
PID is 4469
/proc/4469/cmdline  is  /bin/sh./test01.sh
ok
pgrep -fo ./test01.sh  is  4469

この場合、既にcronで実行中のものとはパスが異なるのでプロセス検索で検出されない。
新規のプロセスとして実行できた。OKが表示された。
（しかし、当然、さらに同じパスで起動しようとすると、noが表示された。）



＜参考＞
・Linux - bash スクリプト二重起動チェック！
< http://www.mk-mode.com/octopress/2016/02/21/linux-bash-check-double-start/ > 2017年6月27日

・PGREP
< https://linuxjm.osdn.jp/html/procps/man1/pgrep.1.html > 2017年6月27日

【Linux CentOS 6 64bit】スクリプトの「#!/bin/sh」の有無とシステムが認識するコマンドラインの関係について

pgrepコマンドで、実行済コマンドラインを与えることで、そのプロセスID (PID)を取得したかった。

ところが、スクリプトの先頭行にある「#!/bin/sh」が無い場合、システムが認識しているコマンドラインが変化し、うまくPIDを取得できなかった。


次のようにスクリプトを作成して、単独で実行し、変数などの値を調べた。

#!/bin/sh

echo "PID is $$"

cmdline=`/bin/cat /proc/$$/cmdline`
echo "/proc/$$/cmdline  is  $cmdline"

echo "PATH  is  $0"
psnum=`pgrep -fo "$0"`
echo "pgrep -fo $0  is  $psnum"

###
if [ "$$" != "$psnum"  ] ; then
        echo "no"
        exit 1
fi

echo "ok"

このスクリプトの実行結果は次のようになった。
# /root/Python/webtest/com/test0.sh

PID is 3564
/proc/3564/cmdline  is  /bin/sh/root/Python/webtest/com/test0.sh
PATH  is  /root/Python/webtest/com/test0.sh
pgrep -fo /root/Python/webtest/com/test0.sh  is  3564
ok

スクリプト内で$$変数によって取得したPIDと、pgrepコマンドに$0を与えて取得したPIDが一致している。
そのため、条件分岐せずに、ok　と表示された。これは意図した動作である。



一方、スクリプトの先頭行から、#!/bin/sh　を外して実行した場合、実行結果は次のようになった。
# /root/Python/webtest/com/test0.sh

PID is 3560
/proc/3560/cmdline  is  -bash
PATH  is  /root/Python/webtest/com/test0.sh
pgrep -fo /root/Python/webtest/com/test0.sh  is
no

実行済コマンドラインが「-bash」となっている。
そのため、pgrepコマンドに$0を与えても、PIDを取得することができなかった。
意図した動作をしない。



＜参考＞
・/bin/sh と /bin/bash の違い
< http://sechiro.hatenablog.com/entry/20120806/1344267619 > 2017年6月27日

【Linux CentOS6.9 64bit】HylafaxとIAXmodemを再起動する順序について【IAXmodem 1.2.0】【Hylafax+ 5.5.9】

Asterisk + IAXmodem + hylafax+ で、ファックスサーバを構築し動作させていたところ、
2ヶ月ほど連続稼動させたところで、急にファックスが受信できなくなってしまった。

とりあえず、IAXmodemと、hylafax+と、Asterisk の再起動を行った。

ところで、IAXmodemと、hylafax+の再起動において、その順序に注意が必要だったのでメモを残しておく。


＜使用したバージョンについて＞
hylafax+（5.5.9） は、CentOSにおいてyum（epelリポジトリ利用）で導入したものである。
IAXmodem（1.2.0）は、ソースから導入した。



■まず、Hylafax IAXmodemの関係について、faxgettyというプログラムと共に整理した。

IAXmodemは、動作中、/dev/IAXmodem　のように、設定に応じたデバイスファイルを存在させる。
hylafaxは、faxgettyというプログラムでそれらのデバイスファイルとの関係を得る。

（例）
# /usr/sbin/faxgetty /dev/IAXmodem &

だから、IAXmodemを起動して、その後、hylafax+を起動し、そしてfaxgettyを実行する必要がある。



■以下では、Hylafax+と、IAXmodemの再起動時の挙動を調べた。

○IAXmodemを再起動する場合　（Hylafaxは起動したままである。）

最初の状態である。faxgettyが動作している。
#  ps -aef | grep faxgetty
uucp     18305     1  0 04:15 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem

サービスを停止する。
# service iaxmodem stop

すでに実行中のfaxgettyは動作したままになってしまった。
#  ps -aef | grep faxgetty
uucp     18305     1  0 04:15 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem

しかし、２分ほど待ってから、調べてみると、動作していたfaxgettyのプロセスは消滅した。
#  ps -aef | grep faxgetty
root     18844  9964  0 04:17 pts/21   00:00:00 grep faxgetty

このとき、Hylafaxから以下のメールを受け取った。
Hylafaxが、faxgettyの引数に渡していたIAXmodemデバイスが利用できないことを検知したようである。
そのために、対応のfaxgettyプロセスはHylafaxによって消滅させられたのだと思う。

# tail /var/spool/mail/root

The HylaFAX software thinks that there is a problem with the modem
on device /dev/IAXmodem that needs attention; repeated attempts to
initialize the modem have failed.

Consult the server trace logs for more information on what is happening.

You will be notified again after 5 minutes if the problem persists.

サービスを再び起動した。
# service iaxmodem start



○Hylafax+を再起動する場合　（IAXmodemは起動したままである。）

#  ps -aef | grep faxgetty
uucp     18094     1  0 04:00 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem

サービスを停止する。
# service hylafax+ stop

しかし、これだけでは、すでに実行中のfaxgettyは動作したままになってしまった。
５分ほど放置してみたが、状況には変化がなかった。
faxgettyを監督しているHylafax本体が起動していないため、faxgettyは終了しないのだろうと思う。
#  ps -aef | grep faxgetty

uucp     18094     1  0 04:08 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem

そして、サービスを再び起動した。
# service hylafax+ start

サービスを再び起動した時に、動作していたfaxgettyのプロセスはただちに消滅した。
hylafaxは起動時には、動作しているfaxgettyプロセスを一掃するのではないかと思う。



■Hylafaxと、IAXmodemを再起動するためのスクリプトを作成した。

Hylafaxと、IAXmodemの再起動には、上記の性質を考慮して行う必要がある。
以下の手順で、Hylafaxと、IAXmodemを再起動すると良いだろう。

（１）Hylafaxの再起動（これによって、古いfaxgettyプロセスが消滅する。）
# service hylafax+ restart

古いfaxgettyプロセスはただちに一掃された。
#  ps -aef | grep faxgetty
root     20339  9964  0 04:34 pts/21   00:00:00 grep faxgetty

（２）IAXmodemの再起動
# service iaxmodem restart

（３）faxgettyをIAXmodemを引数につけて実行する。
# /usr/sbin/faxgetty /dev/IAXmodem &

#  ps -aef | grep faxgetty
uucp     20417     1  0 04:37 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem



（スクリプトにまとめた）

次のような再起動用スクリプトを作成したところ、うまく動作した。
念のため、待機時間を５秒挿入している。
例ではモデム数は一個だけだが、テスト環境においては２０個程度存在していた。

（Asteriskは再起動に時間を要する場合があるので、一番最後が良いかもしれない。あるいは充分なウェイトを置いて最初に行う。）

/sbin/service hylafax+ restart
/bin/sleep 5s
/sbin/service iaxmodem restart
/bin/sleep 5s
/usr/sbin/faxgetty /dev/IAXmodem &

（注意）
逆の手順でIAXmodemから先に再起動させた場合、正しく動作しなかった。
モデムが全て、waiting　状態のままになってしまった。



■ところで、defunctってなんだろうか。

uucp     20419     1  0 04:37 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem1
uucp     20420     1  0 04:37 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem2
uucp     20421     1  0 04:37 pts/21   00:00:00 /usr/sbin/faxgetty /dev/IAXmodem3
uucp     20446 20419  0 04:37 ?        00:00:00 [faxgetty] <defunct>
uucp     20447 20420  0 04:37 ?        00:00:00 [faxgetty] <defunct>
uucp     20484 20420  0 04:49 ?        00:00:00 [faxgetty] <defunct>
uucp     20485 20419  0 04:49 ?        00:00:00 [faxgetty] <defunct>
root     20528  9964  0 04:58 pts/21   00:00:00 grep faxgetty

着信を受けたIAXmodemに対応するfaxgettyプロセスについて、defunctとなった。
無害のようである。参考になるページを見つけた。



＜参考＞
・RE: [hylafax-users] "Waiting for modem to come ready" another
< http://www.hylafax.org/archive/2010-11/msg00128.php > 2017年6月24日

・Re: [hylafax-users] faxgetty <defunct> - 'Extra' FaxGetty
< http://www.hylafax.org/archive/2006-01/msg00322.php > 2017年6月24日

【Linux CentOS 6.8 64bit】Python3.5をyumで導入する手順

CentOS 6.8 ではデフォルトでpythonのバージョンは、2.6だった。
それでは使えないモジュールがあったので、別途、python3.5をインストールした。

以下は、インストール手順である。


○必要なリポジトリを追加した。
# yum install -y https://centos6.iuscommunity.org/ius-release.rpm

Installed:
  ius-release.noarch 0:1.0-15.ius.centos6

○必要なパッケージをインストールした。
# yum install -y python35u python35u-libs python35u-devel python35u-pip

Installed:
  python35u.x86_64 0:3.5.3-1.ius.centos6             python35u-devel.x86_64 0:3.5.3-1.ius.centos6         python35u-libs.x86_64 0:3.5.3-1.ius.centos6
  python35u-pip.noarch 0:9.0.1-1.ius.centos6

Dependency Installed:
  python35u-setuptools.noarch 0:33.1.1-1.ius.centos6

Complete!

○コマンドの場所を確認した。
# which python3.5

/usr/bin/python3.5

○コマンドを実行してバージョンを表示させた。
# python3.5 --version

Python 3.5.3

○新しいバージョンを起動した。
# python3.5

Python 3.5.3 (default, Jan 17 2017, 14:36:19)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>


（注意）
新しいバージョンで動作させるpyスクリプトを作成するときには、最初に次の行が必要だった。

#!/usr/bin/env python3.5

さもなければ、下記の従来のバージョンで動作してしまった。



○従来のバージョンも起動できた。
# python

Python 2.6.6 (r266:84292, Jul 23 2015, 15:22:56)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>



＜参考＞
・Install Latest Python on CentOS 7
< http://www.codeghar.com/blog/install-latest-python-on-centos-7.html > 2017年6月23日

・How To Install Python 3 and Set Up a Local Programming Environment on CentOS 7
< https://www.digitalocean.com/community/tutorials/how-to-install-python-3-and-set-up-a-local-programming-environment-on-centos-7 >  2017年6月23日



【fetchmail 6.3.17】不正なヘッダーを持ったメールがfetchmailで受信されずPOP3サーバに残存する問題について【CentOS6.9 64bit】

fetchmail（Ver. 6.3.17）を用いてPOP3でメールを受信していたところ、ログに次のエラーが記録された。

fetchmail incorrect header line found while scanning headers

不正なヘッダーを持つメールがPOP3サーバに存在しているらしい。

また、下記のように、「not flushed」と記録されたことから、メールがPOP3サーバから削除されなかったことがわかった。

# less /var/log/maillog

Jun 11 00:45:03 MyPC fetchmail[14617]: 2 messages for mymailaccount at mail.example.com (18462 octets).
Jun 11 00:45:03 MyPC fetchmail[14617]: reading message mymailaccount@mail.example.com:1 of 2 (10984 octets) (log message incomplete)
Jun 11 00:45:03 MyPC fetchmail[14617]: incorrect header line found while scanning headers
Jun 11 00:45:03 MyPC fetchmail[14617]:  not flushed

POP3サーバから削除されなかったメールは、この不正なヘッダーを持つメールだけのようである。
それ以外のメールは、通常通り受信されて、サーバから削除されていた。（nokeepの場合）



■不正なヘッダーを持つメールも受信するように設定した。

不正なヘッダを持つメールだとしてもPOP3メールサーバーに残ったままになるのは困るので、
強制的に受信処理するように、次のように設定ファイルに１行追加した。

（注意）
これによって受信できるようになったが、利用環境によっては、
不正なヘッダーのメールを処理することによって何か不具合が生じるかもしれない。

# vi fetchmailrc

（省略）
defaults:
bad-header accept
（省略）

設定後、fetchmailを動作させてPOP3サーバからメールを受信した。

ログを確認した。
# less /var/log/maillog

Jun 14 05:15:03 MyPC fetchmail[1143]: 3 messages for mymailaccount at mail.example.com (96755 octets).
Jun 14 05:15:03 MyPC fetchmail[1143]: reading message mymailaccount@mail.example.com:1 of 3 (3765 octets) flushed
Jun 14 05:15:04 MyPC fetchmail[1143]: reading message mymailaccount@mail.example.com:2 of 3 (81977 octets) flushed
Jun 14 05:15:04 MyPC fetchmail[1143]: reading message mymailaccount@mail.example.com:3 of 3 (11013 octets) flushed

不正なヘッダーを持つメールも、受信されPOP3サーバから削除された。



＜参考＞
・fetchmailでヘッダ異常のメールを読み取らせる
< https://hgotoh.jp/wiki/doku.php/documents/mail/mail-001 > 2017年6月14日

・fetchmail(1)
< https://www.freebsd.org/cgi/man.cgi?query=fetchmail&manpath=SuSE+Linux/i386+11.3 > 2017年6月14日