Linux上でテキストファイルを行単位で分割して加工するスクリプトを作っている。
テキストファイルの分割は”split”コマンドを使えば簡単なんだけど、その際に分割されたファイル名が”指定したベース＋aa~zz”とアルファベットが追加された名前になってしまう。
分割されたファイル単位で処理をするので、ここは数字の方が扱いやすい。
どうにかならないかと思って調べてみたら、”-d”オプションで数字（デフォルトでは二桁）になるらしい。
早速試したところ”そんなオプションは無ぇ！”と怒られてしまったorz。
確かにヘルプを見てもそのオプションは無いので、どうもsplitが古いバージョンのもののようだ（汗）。
新しくするのも面倒だったのでスクリプトのループを変えて対処してしまった。
More from: linux
ファイル名の途中に16進数を入れる方法（sh）
Linuxのshスクリプトでファイル名の途中に16進数を連番で入れる方法を探っていてようやく出来たのでメモ。
また、ファイルが存在する間だけ処理をするのでループ化している。
#!/bin/sh
no=0 #通し番号初期化
end=1 #ループ終了条件初期化
while test $end -eq 1
do
ファイル名=（必要なら）ディレクトリ名/固定文字列`printf %X$no`固定文字列
if [ -e $fname ];then
処理
no=$((no+1)) #通し番号インクリメント
else
end=0
fi
done
printf書式内のXはA-Fで表記するため、小文字の場合は%xにする。
さらに桁数固定なら%4Xのように桁数を指定する。
巨大なテキストファイル・・・
メールの受信が出来なくなったとの連絡があって調べてみたら、サーバー上のスプールファイルが2GBに達していた。
これではpop3でのログインだけでも時間がかかってしまうので、悩んだ挙句分割することにした。
サーバー上でバックアップをとってからそのバックアップファイルをviで開こうとしたが、しばらく経っても開き切らない（汗）。
そこでPC上で分割してからエディターで開いて加工をしてスプールに戻したが、この作業に数時間を費やしてしまったorz。
問題のアカウントに来るメールを一部別アカウントに振り向けたのでしばらくはこんなことは無いと思う。
改行コードか！
Linuxファイルサーバ上のテキストファイルを操作していて特定の文字列を取り除きたかった。
そこで
grep -v -f aaa.txt bbb.txt
を実行したところがaaa.txtに書いてある文字列がbbb.txtに残ってしまう。
エディター上で文字列を見比べてもタイプミスは見当たらない。
おかしいなぁ、と思ってgrepのヘルプを見て思いついたのが改行コード。
ファイルの作成＆編集はWindows10上で行っているので改行コードはCR+LF。
Linuxでは通常LFのみなので試しにaaa.txtの改行コードをLFだけにしてみたらうまくいった（bbb.txtはそのままでもOKだった）。
未だにこんなことで悩まなくてはならないなんて私もまだまだだな（汗）。
IBMがレッドハットを買収？
米IBMがLinux ディストリビューターのRedHatを買収すると発表した。
法的な問題がクリアできれば買収は2019年中に完了する見込みとのこと。
RedHatと言うとLinuxの普及に大いに影響を与えた企業で、現在はデスクトップ用のLinux開発はFedoraプロジェクトに移管し本体は企業向けエンタープライズ事業及びクラウド事業を進めている。
IBMとは以前からエンタープライズ事業で協力してきており、今回の買収はIBMがRedHatのもつクラウド事業に目を付けたものと報道されている。
私も何度かRedHatLinuxをPCにインストールしてサーバーとして使ったりしていたが、まさかIBMが買収するとはねぇ、、、
NFSがつながらない・・・（解決編）
先日、「nfsがつながらない・・・」という記事を書いた。
その時にはクライアント側のサーバー（ややこしいな）の再起動をすれば解決するのでは無いかと考えていた。
今週に入って再起動の機会がある筈だったので、その時までなんとか我慢して運用かと思っていたところ、土曜の夜にトラブルで再起動の必要なサーバが止まってしまい、図らずも再起動となってしまった。
このことを知ったのは月曜になってからだったんだけど、早速nfsマウントを試してみるとやっぱり接続できないorz。
つまり、nfsサーバを先に停止したことが障害の原因では無かったということになる。
クライアント側に出るエラーは
”ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
と以前と同じものなので、やはりnfsサーバ側との通信が出来ていないことになる。
portmapperでは無いかとの指摘もあったが、nfsサーバ側のrpcinfoの結果を見る限りportmapperは動作している（ディストリビューションの関係で”portmap”ではなく”rpcbind”だったが）。
いろいろ考えた結果、ファイアウォール（iptables）に思い当たり、試しに/etc/rc.d/init.d/iptables stopで止めてみると、クライアント側からのrpcinfoコマンドにnfsサーバ側が応答してくるようになり、さらにnfsマウントも試したところ無事にマウント出来た。
つまり、先週から悩んでいたのはiptablesが原因だったということだ（汗）。
そこで、iptablesの設定で必要なポートを開けようとポート番号を調べてみたところ、現状で使っているポートが以下のようになっていた。
（rpcinfoの出力）
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 60503 mountd
100005 1 tcp 35344 mountd
100005 2 udp 48471 mountd
100005 2 tcp 42678 mountd
100005 3 udp 50205 mountd
100005 3 tcp 41105 mountd
100024 1 udp 56315 status
100024 1 tcp 57525 status
これを見るとmountdとstatusの二つは任意のポートを使っているようだ。
これではiptablesで沢山のポートを開けなくてはならず、セキュリティ的に不安なので使用するポートを固定する方法を調べた。
ポートを固定するにはnfsの設定ファイル（/etc/sysconfig/nfs）でコメントアウトされているポート番号（*_PORT）の項目のコメントアウトを外してnfsを再起動すれば良いとのこと。
早速実行してクライアント側でrpcinfoを実行してみた結果が下。
100021 1 udp 44644 nlockmgr
100021 3 udp 44644 nlockmgr
100021 4 udp 44644 nlockmgr
100021 1 tcp 35635 nlockmgr
100021 3 tcp 35635 nlockmgr
100021 4 tcp 35635 nlockmgr
100011 1 udp 875 rquotad
100011 2 udp 875 rquotad
100011 1 tcp 875 rquotad
100011 2 tcp 875 rquotad
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100005 1 udp 892 mountd
100005 1 tcp 892 mountd
100005 2 udp 892 mountd
100005 2 tcp 892 mountd
100005 3 udp 892 mountd
100005 3 tcp 892 mountd
100024 1 udp 662 status
100024 1 tcp 662 status
mountdが892、statusが662で固定されたので、それらを含む必要なポートをiptablesで開けるように設定したところ、iptablesを動作させてもnfsでのマウントもファイルへのアクセスも可能になった。
※当然ながらportmapperのポート（111）も開けるように設定した。
いやぁ、良かった良かった（汗）。
boot時のfsckの回避方法
Linuxサーバの再起動が必要になるのがほぼ確実なんだけど、1200日以上無停止で稼働しているサーバなので、再起動時にfsckが走ることになる。
そうなると起動が終わるまで長時間サービスを停めることになるので出来ればfsckを走らせたくない。
調べてみると起動時のfsckの実行を抑止する方法があった。
一つ目はfstabの6つ目のパラメータを”0″にする方法で、これだとヴォリュームラベル/デヴァイス単位で設定出来る。
二つ目はshutdownコマンドのオプションで”-f”（fastboot）を指定する方法で、このオプションを付けると”/”にfastbootというファイルを作成し、次回のboot時にbootプロセスがfsckをスキップする（ことを期待する）。
今回は全てのディスクのfsckをスキップさせたいので、”shutdown -f -r”を試してみようかな？
問題は短時間とは言え提供中のサービスを止めるのでタイミングをどうするかだなぁ（汗）。
mount解除は出来たものの・・・
仕事場のサーバの更新で、作業担当者がNFSサーバを先に止めてしまい、クライアント側でアクセス出来なくなってしまった。
クライアント側も一度止めて起動しなおせば良かったんだけど、こっちは止める予定が無かったのでそのままになっていた。
このことに気付いたのは作業が終了して運用に入ってから（汗）。
クライアント側でdfコマンドでマウント状況を見ようして途中で帰って来なくなって気付いた。
プロセスがディスク待ちとなってしまってシグナルを受け付けない状態で止められない。
こうなってしまっては一度再起動するしか手段は無いようだけど、すでに運用に入っているうえ、4年近く止めていないので起動時にfsckがかかるのが確実で起動にかかる時間が読めない。
mtabを見るとOS自体はNFSサーバの一部をマウントしたままと認識しているが、実際にはアクセス出来ない状態。
少なくとも、一度マウントを解除して再度マウントし直さなくてはならないんだけど、普通にumountコマンドで解除しようとしてもエラーが出て解除できない。
仕方がないので”umount -f”でやってみても駄目で、最後の手段”umoount -l”で試すとエラーは出たけどmtabからはエントリーが消えたので解除出来、df-kで見ても問題なく解除されていた。
後は再度マウントすれば良いんだけど、昨日の記事に書いたように再マウントできない状態になっている。
やっぱり再起動しないと駄目なんだろうなぁ・・・（汗）。
nfsがつながらない・・・
仕事場のサーバ（群）を更新したら、nfsでのマウントが出来なくなった。
元々全てのサーバを仮想環境で動かしていて、その基盤自体を更新したので一部のサーバを除いて再起動となった。
それぞれのサーバの環境そのものは古い基盤からコピーしたので設定そのものに変化は無いが、一部の古い基盤上に残したサーバからnfsでの接続が上手く出来なくなってしまった。
もちろん両サーバの間の疎通確認は取れていて、pingやsshでの接続は問題無い。
ところが”mount -t nfs NFSサーバ:ディレクトリ マウントポイント”コマンドを実行すると,
“mount: RPC: ポートマッパーの失敗です – RPC: 受け取れません”
というエラーが表示されマウントできない。
nfsサーバ側ではnfsデーモンは動作させているのだけど、クライアント側からもチェックしてみようと思って、
”/usr/sbin/rpcinfo -p NFSサーバ”を実行すると、
”rpcinfo: ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
となってしまう。
つまりpingは通るけど、rpcinfoコマンドは通信できないらしい。
NFSサーバ側でrpcinfoコマンドを実行するとnfsもmountdも動作していると出る。
”arp -d NFSサーバ”でarpテーブルのエントリを削除しても変化無いので、今のところはお手上げ状態。
スタックさせたL3スイッチのトラブルがあったので、その影響らしいが再起動するしか無いのかなぁ？
ファイルが大きすぎたorz
Linuxサーバーで自動的に作成しているファイルが作られていないとの連絡が来た。
調べてみるとファイルの先頭と最後だけが作られている。
ヘッダとフッタは固定文字列を出力しているため、中身だけが全く無い状態。
試しに手動で同じスクリプトを動かしてみると、中で使っているsortコマンドが/tmp以下に作るファイルがスペースが無くて作れないというエラーを吐いて処理が落ちた。
確かに基にしたファイルはいつになく大きいのでsortするにもいつも以上にディスクを必要としているようだ。
かと言って/tmpを含むファイルシステムを拡張するわけにもいかないので、テンポラリファイルの作成先を変更することにした。
それには環境変数”TMPDIR”を設定するか、sortに”-T”オプションでテンポラリファイル作成用ディレクトリを指定するかのどちらかが必要。
今回は”-T”オプションで容量に余裕のあるファイルシステム上のディレクトリを指定するようにしたら問題無くファイルが作成された。
いや、まさかあんな大容量のファイルを相手にすることになるとは想定外だったなぁ（汗）。