カテゴリー「server」

つい忘れがちなので、foregroundからbackgroundへジョブを移すメモです。

centos7で確認済みです。


まず、こんな処理があったとします。

$ cat ./hogehoge.sh 
#!/bin/sh
while true; do echo "hogehoge" >> ./fugafuga.txt; sleep 1; done

これをssh経由でforegroundで実行してしまったが、background実行にして、sshを切りたい場合、

(実行)
$ ./hogehoge.sh 

(中断)
^Z       ※ここでCtr+z
[1]+  Stopped                 ./hogehoge.sh

(確認)
$ jobs
[1]+  Stopped                 ./hogehoge.sh

(バックグラウンドに切り替え)
$ bg 1
[1]+ ./hogehoge.sh &

(TTYから切り離す)
$ disown -h %1

とすることで、background実行になり、sshを切ってもジョブは残り続けます。

予め時間がかかるときは、以下のようにnohup(debian系ならstart-stop-daemonでもよし)を使って実行しておきましょう。

(命令が1つの場合)
$ nohup ./hogehoge.sh 1> ./success.txt 2> ./error.txt &

(命令が連結する場合)
$ nohup sh -c 'while true; do echo "hogehoge" >> ./fugafuga.txt; sleep 1; done' 1> ./success.txt 2> ./error.txt &

以上

投稿日時:2021年02月24日 19:03   カテゴリー:centos, server   [コメントがあればどうぞ]

なにをいっているのか不明なタイトルですが、UDPクライアントでは、受信をするためにbindまたはconnectのシステムコールが必要です、ということです。

TCPクライアントでは、主にconnectのシステムコールが使われることで、一時的に受信ポートが設定されます。そのため、受信が可能となっています。

UDPクライアントでは、bindまたはconnectのシステムコールが内部的に使われている実装と、そうでない実装があります。

javaのNIOのudpにおいては、bindまたはconnectのシステムコールが使われていません。そのため、受信をするためには、上記のシステムコールを使う必要があります。

私が以前作成した、

https://github.com/shigenobu/blueshelf

というUDPのNIOのwrapperでは、クライアントでもbindし、bindしたポート(ファイルディスクリプタ)を使って、送信を行い、そのまま受信してます。

クライアントでbindするメリットは、受信ポートを事前に決めることができる点です。これにより、1対多の通信の実装が行いやすくなります。

もちろん、connectでも1対多は可能ですが、受信ポートを外側から知る手段が必要となります。(外部のサーバを利用するなど)

もちろん、NAT環境下では、外部のサーバを利用しないとはいけませんが、ローカルネットワーク通信においては、受信ポートを予めわかっているというのはクラスタリングをするときに有用かなと考えています(UDPでクラスタリングって微妙ですが)

たぶんあっていると思うのですが、もし間違っていたらごめんさない。

以上

投稿日時:2021年02月24日 18:40   カテゴリー:network, server   [コメントがあればどうぞ]

fluentdとelasticsearchを長時間つないでいると、

「Cannot get new connection from pool.」というエラーが出る。

これが出ると、fluentdを再起動しなければならなかった。

そのため、logrotateでfluentdを再起動して、この問題を回避していた。

この現象が出るfluentdのプラグインのバージョンは以下の通りであった。

(たぶん、これより古いバージョンでも出てたのでは)

  • elasticsearch : 1.1.pre
  • elasticsearch-api : 1.1.pre
  • elasticsearch-transport : 1.1.pre
  • fluent-plugin-elasticsearch : 1.9.2

 

上記を以下のバージョンに変更したところ、コネクションエラーは一切起きなくなった。

  • elasticsearch : 5.0.4
  • elasticsearch-api : 5.0.4
  • elasticsearch-transport : 5.0.4
  • fluent-plugin-elasticsearch : 1.9.5

 

念のためresurrect_afterという設定も入れてはいる。

 

一応、これで1か月以上再起動かけなくても、エラーは出なくなった。

ちなみに、elastic search本体のバージョンは5系である。

 

以上

投稿日時:2017年07月22日 23:48   カテゴリー:elasticsearch, server   [コメントがあればどうぞ]

以前の記事で、monitいいね!なんて書いたので、

monitの設定を残しておく。

なお、バージョンは5.1.4である。

 

[monit.rc]

set daemon 30

set logfile syslog

set eventqueue basedir /var/monit slots 100

set mailserver smtp.gmail.com port 587
 username XXX password XXX
 using tlsv12 with timeout 30 seconds

set mail-format {
 from: XXX@XXX
 subject: Monit Alert ($HOST)
 message: Monit
 ACTION : $ACTION
 SERVICE : $SERVICE
 EVENT : $EVENT
 at $DATE on $HOST.
 DESCRIPTION : $DESCRIPTION
}

set alert XXX@XXX not on {
 instance, action, exec
}

set httpd port 2812 and
 use address 0.0.0.0
 allow localhost
 allow XXX.XXX.XXX.XXX/255.255.255.0
 allow XXX:XXX
 allow XXX:XXX read-only

include /etc/monit.d/*.rc

monit.d以下のファイル。

[disk.rc]

check device root with path /
if space usage > 80% for 5 times within 15 cycles then alert
if inode usage > 90% then alert
if space usage > 95% then stop

[net.rc]

check network eth0 interface eth0

[system.rc]

check system XXX
if cpu > 80% for 5 cycles then alert
if memory usage > 90% for 5 cycles then alert
[mariadb.rc]
check process mariadb with pidfile /var/run/mysqld/mysqld.pid
start program "/usr/bin/systemctl start mariadb.service"
stop program "/usr/bin/systemctl stop mariadb.service"
[maxscale.rc]
check process maxscale with pidfile /var/run/maxscale/maxscale.pid
start program "/usr/bin/systemctl start maxscale.service"
stop program "/usr/bin/systemctl stop maxscale.service"

ほんとはもっとあるけど、

重要なもののみとしました。

 

ポイントとしては、

「データを保持するものは、安易に再起動をかけない」

というところでしょうか。

mariadbについては、今回レプリケーションを組んでいる関係上、

落ちた場合の即再起動が、逆に悪影響を及ぼす可能性があるためです。

 

あとは、うまいこと通知をいれること、

monit自体のプロセス監視などをいれておくことも大事です。

現状、以下2つのcron処理において、

  • monitプロセスの死活監視および再起動
  • monitの再監視設定

を行うようにしています。

*/5 * * * * /usr/bin/pgrep "monit" || /usr/bin/systemctl start monit > /dev/null 2>&1
7 * * * * /usr/bin/pgrep "monit" && /usr/bin/monit monitor all > /dev/null 2>&1

 

やはり、m/monitと連動させたいな。。

 

投稿日時:2016年12月26日 23:48   カテゴリー:server   [コメントがあればどうぞ]

以前の記事でnginxのIPv6対応を書いた。

しかし、設定上、


ipv6only=on

という記述は、1度しか書けないため、

virtualhostで複数運用している場合に、この設定は邪魔となる。

 

virtualhostで運用する場合が多いので、

最終的には以下のようにすればよいのではないだろうか。

 

/etc/nginx/nginx.conf

http {
    :
    :
    # serverディレクティブは書かない
    include /etc/nginx/conf.d/*.conf;
}

 

/etc/nginx/conf.d/default.conf

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name localhost;
    :
    :

 

/etc/nginx/conf.d/your-ssl-vh.conf

server {
    listen                  80;
    listen                  [::]:80;
    listen                  443 ssl;
    listen                  [::]:443 ssl;
    server_name             your-ssl-vh;
    ssl_certificate         /etc/pki/tls/certs/server.crt;
    ssl_certificate_key     /etc/pki/tls/certs/server.key;
    :
    :   

 

このように記載しておくと、your-ssl-vhホストでは、

ipv4、v6の、non-sslまたはsslでのlistenとなる。

non-sslサイトを生きにしつつ、sslも併用し、

念のためipv6対応も入れたいというケースはこのような対応となるだろう。

 

以上

投稿日時:2016年10月16日 23:52   カテゴリー:nginx, server   [コメントがあればどうぞ]

muninでMariaDB10.0.4を監視してたら、

情報がほとんどあつまっていなかった。

 

munin自体はepelからインストールしたのだが、

これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、

以下にあるファイルで上書きする必要がある。

 

https://github.com/munin-monitoring/munin/blob/8abb3faf7865af125ecc18b4feece35c59c90fd9/plugins/node.d/mysql_.in

 

このファイルで上書き、

1行目の


#!@@PERL@@


#!/usr/bin/perl

に直したら、MariaDB10.0.4でも問題なく動いた。

 

以上

投稿日時:2016年07月29日 23:20   カテゴリー:mariadb, rdb, server   [コメントがあればどうぞ]

monitというとプロセス監視をしてくれるだけのイメージがあったが、

深く触ってみると、こいつはすごいなと思った。

基本的にmonitあれば大半のことは事足りると思う。

ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。

 

monitの便利なところとして、以下があげられる。

  • プロセスの死活監視(ダウンしてくれれば、勝手に起動してくれるし、勝手に起動しない形も可能。DBなんかは勝手に起動して問題あるケースもあるよね?)
  • 閾値と発砲の関連付け
  • SMTPを使った発砲機能(リトライ機能もある)
  • web管理画面

さらに、m/monitをつかえば、情報の集約も可能となる。

(有料だけど、買い切りでそれほど高くないのは、良心的)

 

クラウド環境では、かなりの監視ツールがあるが、

こねたことはできないので(できても意外に金がかかる。。)、

monit(もしくはm/monit)を併用すると、結構安心して夜も眠れる環境が出来そう。

 

どこかで、monitの設定を書いてみようと思う。

 

以上

投稿日時:2016年07月11日 00:46   カテゴリー:server   [コメントがあればどうぞ]

glibcにバッファオーバフローの脆弱性があったようなので、

アップデートすることにした。

 

centos7では、以下のバージョンがパッチ適用済みらしい。

2.17-106.el7_2.4

 

そして、updateが完了したら、

再起動する必要があります。

 

[参考]

https://jvn.jp/vu/JVNVU97236594/

 

以上

投稿日時:2016年02月19日 16:05   カテゴリー:server   [コメントがあればどうぞ]

td-agentはプラグインが豊富だけど、

結構品質(というか、どこまで想定して作られているか)がよくないものが多いように感じる。

 

OSS時代の申し子的な存在だけど、

意外にプラグインの品質が悪くて、修正してしまうケースもある。

 

本体はとても優れたプロダクトですが、

プラグインの品質は優劣が激しいので、

気をつけましょう。

 

・・・それに毎回設定で苦労してるから、

td-agentに代わるものを、akkaで作りたいな。。

 

投稿日時:2015年10月26日 17:09   カテゴリー:server   [コメントがあればどうぞ]

ちまたでは、chefやらansibleといった

インフラ構成ツールが流行っている。

 

しかし、個人的にはどっちもめんどくさい。

ドキュメントは充実しているが、

それなりに扱うには独自の書き方を習得する必要がある。

 

そこで、以下のように考えてみた。

  • ssh接続でコマンドを発行できる
  • ssh接続でファイルを操作し、部分置換・全体置換・追記ができる

以上があれば十分で、あと必要なものは、

  • 環境ごとの設定
  • サーバ用途でのグルーピング

ってくらいだろうか。。

 

そして、「冪等性」ってのを保つのは非常に重要。

 

これらを踏まえつつ、

基本的にはシェルスクリプトを作成し、

WEBベースで、実行・管理できればよいかなと思っている。

そんなツールに着手してみようかな。。

 

投稿日時:2015年04月16日 10:40   カテゴリー:server   [コメントがあればどうぞ]