■目次
他社サーバのトラブル調査を依頼されたときサーバが重い・サーバに繋がらない 1サーバが重い・サーバに繋がらない 2サーバが重い・サーバに繋がらない 3サーバが重い・サーバに繋がらない 4サーバが重い・サーバに繋がらない 5サーバが重い・サーバに繋がらない 6サーバが重い・サーバに繋がらない 7サーバが重い・サーバに繋がらない 8サーバが重い・サーバに繋がらない 9サーバが重い・サーバに繋がらない 10サーバが重い・サーバに繋がらない 11サーバが重い・サーバに繋がらない 12サーバが重い・サーバに繋がらない 13サーバが重い・サーバに繋がらない 14サーバが重い・サーバに繋がらない 15ドメイン経由でサーバに繋がらないSSHで認証できない 1SSHで認証できない 2SSHで認証できない 3特定のサービスが動作していないアクセスログにHTTPステータスコード206が連続表示されるtopコマンドを使えないSSLを設定しても「プライバシーが保護されません」などが表示されるWebページを書き換えられているPHPで Strict Standards: date() が表示されるPHPで Warning: strtotime() が表示されるPHPでPOSTデータの内容が途切れるPHPでファイルをアップロードできない / タイムアウトするPHPから MySQLに接続できないMySQLに接続しようとすると Unknown table engine 'InnoDB' と表示されるMySQLに接続しようとすると Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' と表示されるMySQLに接続しようとすると Lock wait timeout exceeded; try restarting transaction と表示されるMySQLのデータベース破損を修復MySQLで意図した値を参照できないFTPソフトで時差が発生するFTPソフトで.htaccessが表示されないメールを送信しても届かない / 迷惑メールとして処理される 1メールを送信しても届かない / 迷惑メールとして処理される 2メールを送信しても届かない / 迷惑メールとして処理される 3ZabbixでSSHを監視できないZabbixでFTPを監視できないZabbixで管理画面が表示されないchkrootkitが誤動作するClam AntiVirus(アンチウィルスソフト)からログファイルがロックされているとエラーが来るyumを実行できないディスク容量が残り少ないinodeが残り少ないAWSでPHPからMySQLに接続するための命令をインストールできないミドルウェアなどを起動できない/var/log/messages に「kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }」と記録されるさくらの専用サーバで再起動できない
■他社サーバのトラブル調査を依頼されたとき
他社が立てたサーバで、トラブルがあった時だけ有償対応するのは危険。対応は慎重に検討する 自分で立てたサーバなら監視ツールなども入れるし継続的に監視もできるが、 他社が立てたサーバの場合、それらが何も無いことがある また、想定外のツールが仕込まれていて、それがもとでトラブルになった場合の対応が難しい サーバの設定を変更した場合その後継続的な監視も必要なので、1日2日で完了するものでは無い 一般に「サーバの監視を継続的に行う」という仕事が成立している以上、 一時的な対応で簡単に対応できるとは考えないほうがいい 「何かトラブルがあったときだけ対応」という以来は避けたほうが賢明
■サーバが重い・サーバに繋がらない 1
まずはサーバ会社の障害情報を確認する (上位回線に攻撃があった場合、Zabbixなどでは感知できない。) 次にZabbixなどで、外部からの大量リクエストによって重くなっているのか、そうでないのかを確認する リクエストによって重くなっている場合、そのリクエストの詳細を調べて、必要なら遮断するなどする 内部で問題が起こっている場合、該当プログラムを探す。 (以下の「サーバが重い・サーバに繋がらない」「Webページにアクセスできない」の具体例を参照) 原因が不明な場合、サーバーの再起動が有効な場合がある
■サーバが重い・サーバに繋がらない 2
サーバに繋がらないという連絡 Zabbixで Too many processes on {HOSTNAME} を確認すると、プロセス数が300を超えていた。 topコマンドで確認すると、MySQLの負荷が異常に高い MySQLのスロークエリを確認すると、以下のSQLなど複数のクエリで長時間ロックされていた。 # Time: 150911 19:11:57 # User@Host: refirio[refirio] @ localhost [] # Query_time: 1412.046061 Lock_time: 706.623757 Rows_sent: 1 Rows_examined: 1756 SET timestamp=1441966317; SELECT COUNT(*) as cnt FROM w_delivery_call_header target WHERE EXISTS(SELECT * FROM w_delivery_call_list dl 以下略 MySQL方面からは、これ以上のことは判らず。 引き続き原因調査のため、SSHでログインしてしばらく操作していると、以下のメッセージが表示された。 Message from syslogd@refirio1 at Sep 11 20:34:02 ... kernel:Uhhuh. NMI received for unknown reason 21 on CPU 0. Message from syslogd@refirio1 at Sep 11 20:34:02 ... kernel:Do you have a strange power saving mode enabled? Message from syslogd@refirio1 at Sep 11 20:34:02 ... kernel:Dazed and confused, but trying to continue エラーメッセージでググる。 OSが認識していない理由コードでNMIが発生したというメッセージ http://japan.zdnet.com/article/20367195/ Dazed and confused, but trying to cont... http://ossmpedia.org/messages/linux/2.6.9-34.EL/58911.ja 「実際の報告事例としては相性も含めてメモリカードの不具合が一番多い。」 誰も教えてくれなかったMySQLの障害解析方法 http://qiita.com/muran001/items/14f19959d4723ffc29cc ハードウェアの故障やメモリの容量不足によっても、スロークエリは発生するみたい ハードの問題の可能性が高いため、サブ機に切り替えて様子見。 その後、IPが変化したり、Zabbixの監視対象から外れていないか確認。 SSHアクセス、HTTPアクセス、バックアップの仕組みが動いているか、など諸々の動作確認を行う。 さくらに連絡 マザーボードの問題らしい 載せ替えて対応してくれるらしいが、ネットワークカードのMacアドレスが変わる よってサーバ内の設定調整が必要になるが、Macアドレスを使うアプリケーションは走らせていないので問題無いと思われる (Macアドレスでライセンス認証を行うものがあるので注意。)
■サーバが重い・サーバに繋がらない 3
ブラウザから見て画面が表示されないという連絡 topで確認すると、MySQLのプロセス1つがCPU使用率100%になっていた Zabbixで確認すると全体の25%を使用している CPUのコア数は4なので、CPUを1つ使い切っている。重い処理が1つ走った可能性がある また、ロードアベレージも1〜3程度まで上昇し、メモリもfreeが普段の半分くらいになっている スロークエリを確認(ファイルに記録している場合。以下の場所は一例) # vi /var/log/slow.log # vi /var/lib/mysql/mysql-slow.log ログが見当たらない場合、/etc/my.cnf の設定を確認するか、ファイルを検索する # find / -name mysql-slow.log /home/www/html/logs/mysqld/mysql-slow.log /home/www/html/logs/mysql-slow.log /home/admin/mysql-slow.log # vi /home/www/html/logs/mysqld/mysql-slow.log スロークエリを確認(データベースに記録している場合) SELECT * FROM mysql.slow_log; 以下のクエリが実行された以降、重くなった? # Time: 160205 10:17:08 # User@Host: refirio[refirio] @ localhost [] # Query_time: 2427.133555 Lock_time: 0.000157 Rows_sent: 0 Rows_examined: 9586647062 SET timestamp=1454635028; CREATE TEMPORARY TABLE `dataC6` (INDEX(owner_cd)) SELECT Q.owner_cd, Q.wms_section_cd, COUNT(Q.arrival_no) AS 'cntWork', SUM(Q.list_sum) as cntWorkd FROM (SELECT mag.area_group, mag.area_group_name, mo.owner_name, ah.owner_cd, ah.wms_section_cd, ah.arrival_no, ah.regist_date, ah.reserve_date, SUBSTRING(ah.regist_date,1,10) AS date , GET_SUM_ITEM_NUM_BY_ARRIVAL_LIST(ah.arrival_no) AS 'list_sum' FROM w_arrival_reserve_list ah LEFT JOIN m_owner mo ON ah.owner_cd = mo.owner_cd LEFT JOIN m_area ma ON mo.area_cd = ma.area_cd LEFT JOIN m_area_group mag ON ma.area_group = mag.area_group WHERE ah.regist_date between '2011-01-01 00:00:00' and '2016-02-05 23:59:59' AND not exists(select 1 from w_arrival_result ar where ah.arrival_no = ar.arrival_no) AND ah.csv_status<>'0' AND mo.area_cd IN (SELECT m_area.area_cd as area_cd FROM m_area WHERE m_area.area_group = 32 ) GROUP BY ah.arrival_no ) Q GROUP BY Q.area_group ASC, Q.owner_cd ASC; また、以下の様な処理が何度もスロークエリに記録されている SELECT COUNT(*) as cnt FROM w_delivery_call_list target INNER JOIN w_delivery_call_header dh ON target.delivery_no = dh.delivery_no AND target.owner_cd = dh.owner_cd INNER JOIN m_owner_wms_section ow ON target.owner_cd = ow.owner_cd AND target.wms_section_cd = ow.wms_section_cd WHERE ow.area_cd = 'HN1' AND target.ignore_flg <> '1' AND NOT EXISTS(SELECT * FROM w_delivery_call_list dl INNER JOIN t_item ti ON dl.owner_cd = ti.owner_cd AND dl.wms_section_cd = ti.wms_section_cd AND dl.wms_item_cd = ti.wms_item_cd INNER JOIN m_owner_wms_section ow ON dl.owner_cd = ow.owner_cd AND dl.wms_section_cd = ow.wms_section_cd WHERE dl.stockout_flg = '1' AND dl.picking_flg = '1' AND dl.delivery_no = target.delivery_no AND (ti.uninventory_flg <> '1' AND ti.uninventory_flg <> '3') AND ow.area_cd = 'HN1')AND dh.shipment_start_date <= DATE_ADD(CURDATE(), INTERVAL 10 DAY) + 0 AND target.csv_status = 0; ログイン時、もしくはダッシュボードで常に重い処理が走っているみたい 普段から重いが、MySQLが重くなると致命的になる? プログラム側の改修が必要の可能性あり 以下のSQLで、60秒より長く実行され続けているクエリを探すこともできる SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 60;
■サーバが重い・サーバに繋がらない 4
CloudWatchを確認すると、RDSのCPU使用率が60%ほどに達していた AWSのコンソールからスロークエリログをダウンロードして確認 (テーブルに記録している場合、SQLでスロークエリログを確認する) select * from `sh_headers` where `unit_id` = '32' and `sh_headers`.`no` = '4452013' and `dlv_nt_no` = '4452013' limit 1; のような、検索のスロークエリログが大量に記録されている このクエリをNavicatで実行すると1.112秒かかる。7秒以上かかるときもある。遅い 使用していたRDSは db.t2.large。t2系なので、CPUクレジットを確認すると枯渇していた CPUCreditBalanceで残高、CPUCreditUsageで使用状況を確認できる (監視対象に入れていなかったが、これも監視対象に入れておくと良い。その他、AWSならではな監視項目があるかもなので、ひととおり確認する) CPU クレジット - T2 インスタンス - Amazon Elastic Compute Cloud http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/t2-instances.html#t2-instances-cpu-credits 引き続き、CPUクレジットを消費した原因を調査 MySQLの以下のコマンドでプロセスを確認すると、ゾンビプロセスがいた SHOW PROCESSLIST; 処理時間が非常に長いのでKILLした(らしい) すぐにRDSのCPU使用率が下がり始めた 直接の原因は最近行った改修内容と思われる 改修以降にCPU負荷が高くなったため、該当箇所を再調整して様子を見る
■サーバが重い・サーバに繋がらない 5
Apacheのログに # tail -n 10 /var/log/httpd/error_log [Tue Jun 21 09:54:56 2016] [notice] child pid 26477 exit signal Segmentation fault (11) [Tue Jun 21 09:54:56 2016] [notice] child pid 26514 exit signal Segmentation fault (11) [Tue Jun 21 09:54:56 2016] [notice] child pid 646 exit signal Segmentation fault (11) [Tue Jun 21 09:55:07 2016] [notice] child pid 647 exit signal Segmentation fault (11) [Tue Jun 21 09:55:07 2016] [notice] child pid 648 exit signal Segmentation fault (11) [Tue Jun 21 09:55:07 2016] [notice] child pid 649 exit signal Segmentation fault (11) [Tue Jun 21 09:55:07 2016] [notice] child pid 650 exit signal Segmentation fault (11) [Tue Jun 21 09:55:07 2016] [notice] child pid 651 exit signal Segmentation fault (11) [Tue Jun 21 09:55:07 2016] [notice] child pid 652 exit signal Segmentation fault (11) [Tue Jun 21 09:56:22 2016] [notice] child pid 654 exit signal Segmentation fault (11) のように出力されている場合、セグメンテーション違反が発生している セグメンテーション違反は、 ・プログラムの不具合で、大量のメモリを消費した ・C/C++などで作成されたプログラムが、mallocで確保した領域の外など参照してはいけない領域のメモリを参照してしまった ときなどに発生する このとき、psの結果は以下のようになっていた ApacheがCPUをまったく消費していない(動作していない) [root@zabbix ~]# ps aux | grep httpd apache 15313 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15314 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15315 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15316 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15317 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15318 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15319 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15320 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15321 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15322 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15323 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd apache 15324 0.0 0.5 63360 5188 ? S 10:46 0:00 /usr/sbin/httpd root 15393 0.0 0.0 5096 784 pts/0 S+ 10:47 0:00 grep httpd root 30158 0.0 1.1 63360 11660 ? Ss Dec16 0:00 /usr/sbin/httpd Apacheを再起動するとCPUが消費されるようになり、 「Segmentation fault」もなくなり、Webページにアクセスできるようになった [root@zabbix ~]# service httpd restart httpd を停止中: [ OK ] httpd を起動中: [ OK ] [root@zabbix ~]# ps aux | grep httpd root 15408 1.8 0.9 62840 10184 ? Ss 10:47 0:00 /usr/sbin/httpd apache 15410 3.6 2.2 70728 23264 ? S 10:47 0:00 /usr/sbin/httpd apache 15411 0.0 0.7 63492 7764 ? S 10:47 0:00 /usr/sbin/httpd apache 15412 0.0 0.5 62972 5432 ? S 10:47 0:00 /usr/sbin/httpd apache 15413 0.6 1.2 64664 12996 ? S 10:47 0:00 /usr/sbin/httpd apache 15414 0.0 0.4 62972 4756 ? S 10:47 0:00 /usr/sbin/httpd apache 15415 0.0 0.4 62972 4756 ? S 10:47 0:00 /usr/sbin/httpd apache 15416 0.0 0.4 62972 4756 ? S 10:47 0:00 /usr/sbin/httpd apache 15417 0.0 0.4 62972 4756 ? S 10:47 0:00 /usr/sbin/httpd root 15419 0.0 0.0 5092 772 pts/0 S+ 10:47 0:00 grep httpd プログラムの不具合なら、yum update で解決するかもしれない もしくは依存ライブラリを差し替えるなど 可能なら試す サーバの再起動で解決することもあるらしい 「再起動によって不正な状態にあったメモリが解消された」 「再起動によって十分なメモリが確保された」 ということかもしれない インフラエンジニアがSegmentation fault をなんとか治してみる http://sarface2012.hatenablog.com/entry/20101027 Cライブラリの問題などで発生することが多いようだが、 PHPで「不正なクラスを参照したために大量のメモリを消費された」場合など、 メモリ不足でも発生することがあるみたい CentOS6 + Apache + PHP で Segmentation fault http://d.hatena.ne.jp/pospome/20140420/1398016279
■サーバが重い・サーバに繋がらない 6
ZabbixとCloudWatchから、「CPUの空きが少なくなっている」と警告が来た。 その時間のps結果(記録する仕組みを構築してあった)を見ると apache 7382 0.0 51.2 1415264 1051548 ? R 12:58 0:05 /usr/sbin/httpd となっていた。 Apacheが51.2%のメモリを消費している。 その時間のApacheエラーログを確認すると [Thu Jul 14 14:46:32 2016] [error] [client 10.0.1.78] PHP Fatal error: Allowed memory size of 1073741824 bytes exh austed (tried to allocate 7680 bytes) in /var/www/vhosts/common/libs/cores/basis.php on line 52 とあった。 Webアプリケーションから巨大なファイルアップロードをしようとして、エラーになったもの。
■サーバが重い・サーバに繋がらない 7
毎週日曜日になるとIOの数値が異常に上がり、サイトがダウンする 日曜日に何か特別な作業をしたりはしていない 該当日時の /var/log/messages を確認すると ats-collection kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 ats-collection kernel: httpd invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0 ats-collection kernel: miniserv.pl invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0 のようなログがあった。メモリ不足でMySQLやApacheが強制終了させられている また /var/log/httpd/error_log には大量の404エラーが、/var/log/messages にはSMTPへのauth failureが大量に記録されている ・外部からのアタックによりサーバがダウンしている ・平日はギリギリ稼働しているが、日曜日にアタックが多くなりダウンしている ・エラーログ読み書きのためにIOの数値が上がっている という可能性がある。対応としては ・固定IPからの攻撃ならブロックする ・SMTPが不要なサーバならポートを閉じる。他にも不要なポートが空いていれば閉じる ・サーバのスペックを上げる(メモリの増加) などがある
■サーバが重い・サーバに繋がらない 8
朝の10時過ぎから、某学校サーバにアクセスしづらい状態になった Zabbixで確認するとトラフィックが急激に増加していた。原因は10時から合格発表があったため SSHでサーバにログインし、sarコマンドでトラフィックをリアルタイムに監視。 $ sar -n DEV 1 20 | grep eth0 10時14分43秒 eth0 10560.20 11452.04 1266.93 11511.12 0.00 0.00 22.45 10時14分44秒 eth0 10537.76 11457.14 1323.67 11336.58 0.00 0.00 26.53 10時14分45秒 eth0 10716.00 11577.00 1326.23 11583.44 0.00 0.00 24.00 10時14分46秒 eth0 11122.22 11577.78 1388.56 11517.21 0.00 0.00 14.14 10時14分47秒 eth0 9507.07 11029.29 1178.79 12118.10 0.00 0.00 26.26 10時14分48秒 eth0 9288.89 11085.86 1173.10 12113.81 0.00 0.00 26.26 10時14分49秒 eth0 8996.00 10951.00 1156.57 11992.37 0.00 0.00 24.00 10時14分50秒 eth0 8947.47 10778.79 1080.09 12120.24 0.00 0.00 26.26 10時14分51秒 eth0 9882.83 11351.52 1254.92 11765.30 0.00 0.00 24.24 10時14分52秒 eth0 10688.78 11896.94 1401.18 11873.96 0.00 0.00 21.43 10時14分53秒 eth0 10903.06 11642.86 1416.27 11664.75 0.00 0.00 24.49 10時14分54秒 eth0 10866.67 11215.15 1355.76 11369.29 0.00 0.00 26.26 10時14分55秒 eth0 10964.29 11460.20 1376.89 11759.93 0.00 0.00 24.49 10時14分56秒 eth0 10537.00 11191.00 1280.03 11539.10 0.00 0.00 24.00 10時14分57秒 eth0 10692.00 11669.00 1355.28 11894.80 0.00 0.00 22.00 10時14分58秒 eth0 11584.69 12365.31 1534.60 12001.36 0.00 0.00 25.51 10時14分59秒 eth0 11228.28 12140.40 1450.51 11683.98 0.00 0.00 12.12 10時15分00秒 eth0 10805.05 11335.35 1351.23 11124.17 0.00 0.00 18.18 10時15分01秒 eth0 10600.00 11835.35 1392.09 11433.73 0.00 0.00 26.26 10時15分02秒 eth0 11733.33 12204.04 1514.41 11631.43 0.00 0.00 14.14 平均値: eth0 10506.42 11509.86 1328.58 11701.87 0.00 0.00 22.65 右から4番目の値が、1秒間あたりの送信キロバイト数。 コンテンツを表示させるため、最大で1秒間に 12,120 Kbytes(96,960 Kbits)のデータが送信された。 つまり、約95Mbpsの速度が出たことになる。計測したサーバの回線は ・アップリンク:100Mbps ・接続形態:100Base-TX ・ご利用帯域目安:10Mbps(優先制御回線) となっているので、十分な速度が出ていると判断できる。(目安10Mbps、最大100Mbps。) 回線の限界までデータが流れているため、表示が遅くなっている状態。 契約上保証されている10Mbpsどころか、回線の限界である100Mbpsの速度がでているため、 「30Mbps(優先制御回線)」の契約に変えても合格発表直後は回線が詰まると思われる。 合格発表直後30分程度でアクセスは落ち着くようなので、その間だけ遅いのを良しとするか否か。 良しとできないなら、さくらの契約的に対処は難しいので、コンテンツを軽くする必要があると思われる。
■サーバが重い・サーバに繋がらない 9
Zabbixからサーバについての警告 確認すると、突然ロードアベレージが上がっており、大量のトラフィックも記録されている CPUはuser(アプリケーション)によって大量に使用されている WordPressを使っているサイトだったので、大量アクセスが原因と思われる アクセスログを見ると、以下ようなアクセスが大量に記録されている ツールによるイタズラと思われる # vi /var/log/httpd/access_log
10.2.0.253 - - [08/Sep/2017:15:27:27 +0900] "GET /course/tennis/blog/detail.php?id=7547 HTTP/1.1" 200 34005 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 340873 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:27 +0900] "GET /course/tennis/blog/detail.php?id=1402 HTTP/1.1" 200 34112 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 342551 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:27 +0900] "GET /course/tennis/blog/detail.php?id=7546 HTTP/1.1" 200 33267 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 327939 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:28 +0900] "GET /course/tennis/blog/detail.php?id=7545 HTTP/1.1" 200 33821 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 337142 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:28 +0900] "GET /course/tennis/blog/detail.php?id=7544 HTTP/1.1" 200 36823 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 381773 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:28 +0900] "GET /course/tennis/blog/detail.php?id=7543 HTTP/1.1" 200 33740 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 333276 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:29 +0900] "GET /course/tennis/blog/detail.php?id=7542 HTTP/1.1" 200 35198 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 352983 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:29 +0900] "GET /course/tennis/blog/detail.php?id=7541 HTTP/1.1" 200 33783 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 320295 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:30 +0900] "GET /course/tennis/blog/detail.php?id=7540 HTTP/1.1" 200 33501 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 327385 52.196.209.177 http 10.2.0.253 - - [08/Sep/2017:15:27:30 +0900] "GET /course/tennis/blog/detail.php?id=7539 HTTP/1.1" 200 33791 "http://www.riseisha.ac.jp/course/tennis/blog/?paged=17" "Wget/1.14 (linux-gnu)" 334674 52.196.209.177 http
http://www.iphiroba.jp/ でIPアドレスを調べると以下の内容だった どこかの人がAWSに立てたEC2サーバと思われる - - - - - - - - - - - - - - - - - - - - IPアドレス: 52.196.209.177 ホスト名: ec2-52-196-209-177.ap-northeast-1.compute.amazonaws.com 国: 日本 都道府県: 東京 市区町村: 新宿区 - - - - - - - - - - - - - - - - - - - - ツールを名指しでアクセス制限してみた 即座に負荷が減った # vi .htaccess
BrowserMatch "Wget/1.14 (linux-gnu)" bad_bot Order Allow,Deny Allow from all Deny from env=bad_bot
ロードバランサー環境でIP制限する方法などは security.txt を参考に
■サーバが重い・サーバに繋がらない 10
AWSのEC2インスタンス一覧で、「アラームのステータス」が「データなし」となった しばらくすると自動で復旧した (インスタンスを10台程度起動させていると、数ヶ月に一度(1台)くらいの頻度で起きるように思う) cat /var/log/messages で繋がらなくなった時間のログを確認。uptime でサーバの稼働時間も確認。 再起動された形跡があれば、以下の可能性が高い AWS Developer Forums: インスタンスが勝手に再起動される https://forums.aws.amazon.com/message.jspa?messageID=288044 ハードウェアの問題などでAWSがインスタンスを強制的に再起動することがある その際AWSから個別連絡は行われない 防ぐためには、マルチAZでの複数台構成にする必要がある (最低でも2台以上の構成にする必要があるが、1台になったときにアクセスが集中することを考えれば3〜4台以上にすることが好ましい) 計画停止される場合、15日前くらいにメールで通知されるので、メールは確認しておく 止まった時の /var/log/messages ファイルの内容は以下のとおり。 May 17 09:02:29 web1 clamd[2582]: SelfCheck: Database status OK. May 17 09:12:29 web1 clamd[2582]: SelfCheck: Database status OK. May 17 09:13:13 web1 init: serial (ttyS0) main process (2691) killed by TERM signal May 17 09:13:13 web1 init: tty (/dev/tty1) main process (2692) killed by TERM signal May 17 09:13:13 web1 init: tty (/dev/tty2) main process (2695) killed by TERM signal May 17 09:13:13 web1 init: tty (/dev/tty3) main process (2697) killed by TERM signal May 17 09:13:13 web1 init: tty (/dev/tty4) main process (2699) killed by TERM signal May 17 09:13:13 web1 init: tty (/dev/tty5) main process (2701) killed by TERM signal May 17 09:13:13 web1 init: tty (/dev/tty6) main process (2704) killed by TERM signal May 17 09:13:13 web1 init: plymouth-shutdown main process (12355) terminated with status 1 May 17 09:13:13 web1 init: splash-manager main process (12350) terminated with status 1 May 17 09:13:15 web1 clamd[2582]: Pid file removed. May 17 09:13:15 web1 clamd[2582]: --- Stopped at Tue May 17 09:13:15 2016 May 17 09:13:15 web1 clamd[2582]: Socket file removed. May 17 09:13:16 web1 ntpd[2301]: ntpd exiting on signal 15 May 17 09:13:16 web1 rpcbind: rpcbind terminating on signal. Restart with "rpcbind -w" May 17 09:13:16 web1 kernel: Kernel logging (proc) stopped. May 17 09:13:16 web1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2124" x-info="http://www.rsyslog.com"] exiting on signal 15. May 17 15:07:51 web1 kernel: imklog 5.8.10, log source = /proc/kmsg started. May 17 15:07:51 web1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2088" x-info="http://www.rsyslog.com"] start May 17 15:07:51 web1 kernel: [ 0.000000] Initializing cgroup subsys cpuset May 17 15:07:51 web1 kernel: [ 0.000000] Initializing cgroup subsys cpu May 17 15:07:51 web1 kernel: [ 0.000000] Initializing cgroup subsys cpuacct May 17 15:07:51 web1 kernel: [ 0.000000] Linux version 4.1.17-22.30.amzn1.x86_64 (mockbuild@gobi-build-60009) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Fri Feb 5 23:44:22 UTC 2016 May 17 15:07:51 web1 kernel: [ 0.000000] Command line: root=LABEL=/ console=ttyS0 LANG=ja_JP.UTF-8 KEYTABLE=us May 17 15:07:51 web1 kernel: [ 0.000000] e820: BIOS-provided physical RAM map: May 17 15:07:51 web1 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dfff] usable May 17 15:07:51 web1 kernel: [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved May 17 15:07:51 web1 kernel: [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved May 17 15:07:51 web1 kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007fffffff] usable May 17 15:07:51 web1 kernel: [ 0.000000] BIOS-e820: [mem 0x00000000fc000000-0x00000000ffffffff] reserved May 17 15:07:51 web1 kernel: [ 0.000000] NX (Execute Disable) protection: active May 17 15:07:51 web1 kernel: [ 0.000000] SMBIOS 2.4 present. May 17 15:07:51 web1 kernel: [ 0.000000] Hypervisor detected: Xen May 17 15:07:51 web1 kernel: [ 0.000000] Xen version 4.2. May 17 15:07:51 web1 kernel: [ 0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. それ以外には、以下のような可能性も考えられる http://www.harumaki.net/2015/01/06/aws-ec2-rhel6-error-ttys0-messages/ 対処方法と思わしき記事はあるが、1台のみでの発生だったので関係ないかも https://access.redhat.com/ja/node/1218334 OS自体の不具合の可能性がある? 諸々をupdateしてコールドリブート(完全に停止させてからの起動)をするといいかも
■サーバが重い・サーバに繋がらない 11
Zabbixからサーバについての警告 突然web1サーバが停止した。SSHでもHTTPでもアクセスできない コンソールからEC2を再起動してみたが反応なし 次に停止させてみたが、「stopping」のまま反応なし…だったが、20分程度経ってから停止した。 停止を確認後、起動させると問題なくアクセスできるようになった。 調べてみる限り、AWSではときどき発生しているらしい。 サーバが入っているハードに何らかの問題が起きて、それが原因で正しく動作しなくなることがあるらしい。 サーバを起動し直すと物理的に別の場所にサーバが立ち上がるようで、一応はそれが定番の対応らしい。 サーバが停止しない場合、フォーラムでAWSに再起動を依頼する。 Amazon EC2 Micro Instanceが止まった場合の対処 | A-tak-dot-com http://a-tak.com/blog/2011/05/16/amazon-ec2-freeze/ AWS Developer Forums: EC2インスタンスが停止できない。 ... https://forums.aws.amazon.com/thread.jspa?threadID=84070 以下、問題があったときの /var/log/messages だが、特に問題は見られない Dec 7 20:19:00 web1 dhclient[2120]: DHCPREQUEST on eth0 to 10.0.0.1 port 67 (xid=0x2985c309) Dec 7 20:19:00 web1 dhclient[2120]: DHCPACK from 10.0.0.1 (xid=0x2985c309) Dec 7 20:19:02 web1 dhclient[2120]: bound to 10.0.0.129 -- renewal in 1421 seconds. Dec 7 20:19:02 web1 ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/06:de:57:6b:b3:6d/local-ipv4s Dec 7 20:19:02 web1 ec2net: [rewrite_aliases] Rewriting aliases of eth0 Dec 7 20:42:43 web1 dhclient[2120]: DHCPREQUEST on eth0 to 10.0.0.1 port 67 (xid=0x2985c309) Dec 7 20:42:43 web1 dhclient[2120]: DHCPACK from 10.0.0.1 (xid=0x2985c309) Dec 7 20:42:45 web1 dhclient[2120]: bound to 10.0.0.129 -- renewal in 1634 seconds. Dec 7 20:42:45 web1 ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/06:de:57:6b:b3:6d/local-ipv4s Dec 7 20:42:45 web1 ec2net: [rewrite_aliases] Rewriting aliases of eth0 Dec 7 21:22:25 web1 kernel: imklog 5.8.10, log source = /proc/kmsg started. Dec 7 21:22:25 web1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2216" x-info="http://www.rsyslog.com"] start Dec 7 21:22:25 web1 kernel: [ 0.000000] Initializing cgroup subsys cpuset Dec 7 21:22:25 web1 kernel: [ 0.000000] Initializing cgroup subsys cpu Dec 7 21:22:25 web1 kernel: [ 0.000000] Initializing cgroup subsys cpuacct Dec 7 21:22:25 web1 kernel: [ 0.000000] Linux version 4.4.51-40.60.amzn1.x86_64 (mockbuild@gobi-build-64010) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Wed Mar 29 19:17:24 UTC 2017 以下起動ログ
■サーバが重い・サーバに繋がらない 12
ZabbixからCPU負荷が高いという警告があった Zabbixを確認すると、負荷が上がった時間で「Incomming traffic」が上がっている 大量アクセスがあったか、重い画像が表示されたかと予想 アクセスログファイル /var/log/httpd/access_log で該当時間のアクセスを調べると、 以下のようなアクセスが大量にある。sitemapxmlというツールらしい 10.2.1.125 - - [13/Oct/2017:17:16:50 +0900] "GET /course/tennis/blog/?paged=59 HTTP/1.1" 200 33374 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sitemapxml.jp)" 1649868 219.94.192.62 http 10.2.1.125 - - [13/Oct/2017:17:16:50 +0900] "GET /course/tennis/blog/detail.php?id=13856 HTTP/1.1" 200 36560 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sitemapxml.jp)" 1661806 219.94.192.62 http 10.2.1.125 - - [13/Oct/2017:17:16:50 +0900] "GET /course/tennis/blog/detail.php?id=13827 HTTP/1.1" 200 36207 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sitemapxml.jp)" 1656114 219.94.192.62 http 10.2.1.125 - - [13/Oct/2017:17:16:50 +0900] "GET /course/tennis/blog/detail.php?id=13846 HTTP/1.1" 200 36508 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sitemapxml.jp)" 1655430 219.94.192.62 http 10.2.1.125 - - [13/Oct/2017:17:16:50 +0900] "GET /course/tennis/blog/detail.php?id=13814 HTTP/1.1" 200 39387 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; sitemapxml.jp)" 1654808 219.94.192.62 http サイト運営者に確認すると、「サイトマップ作成ツールを使いました」とのことなのでそれが原因。
■サーバが重い・サーバに繋がらない 13
サイトが突然503エラーになった AWSコンソールで確認すると、Webサーバが二台ともロードバランサーから外れていた WebサーバのCPU使用率やネットワークINは普段より多いものの、異常と言えるほどではない 10分ほど経つと自動で回復した 以下調査内容 RDSの状態を確認すると、15:50ごろから「DB接続(カウント)」がどんどん上がっている アプリケーション(Laravel)のログを確認すると、 Next exception 'Illuminate\Database\QueryException' with message 'SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction (SQL: update `stocks` set `deleted_at` = 2018-01-31 16:04:56, `updated_at` = 2018-01-31 16:04:56 where `stocks`.`deleted_at` is null and `id` = 469232)' in /var/www/w3package_v2/shared/vendor/laravel/framework/src/Illuminate/Database/Connection.php:624 と記録されている ・15:50ごろにロックが発生し ・RDS側で処理が詰まり ・16:04にようやくログとして記録された という状況だと思われる その間にもどんどんアクセスが来るので、nginxのアクセス数上限に達して503エラーが返された? それがもとでロードバランサーから外されてしまった? 設定ファイルでは以下のように設定されているので、「worker_processes * worker_connections」でnginxは1024の接続数を捌けるみたい /etc/nginx/nginx.conf - - - - - - - - - - - - - - - - - - - - user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } - - - - - - - - - - - - - - - - - - - - 2台のWebサーバがダウンしたことにより、アクセス元が無くなってロックが解除されたか もともと10分程度ロックし続ける処理で、それが終わったからロックが解除されたか …だと思われる 根本解決は難しいが、いったん 「どうしても長く処理すべき処理以外は、タイムアウトの時間を短くする」 で対応できるか検討する ・ロックした状態でPHPからSELECTするとどんな挙動になるか ・500番台のエラーになるのか、200番台で処理を返せるのか ・ロックを検知して強制解除はできるのか などは要検証 デッドロックおじさん戦記 - Mercari Engineering Blog http://tech.mercari.com/entry/2017/12/18/deadlock MySQLのデッドロックを意図的に発生させる http://linuxserver.jp/%E3%82%B5%E3%83%BC%E3%83%90%E6%A7%8B%E7%AF%89/db/mysql/%E3%83%87%E3%83%83%E3%8... MySQLのデッドロックを解除 http://fukuchiharuki.me/wiki/index.php?MySQL/%E3%83%AD%E3%83%83%E3%82%AF%E3%82%92%E8%A7%A3%E9%99%A4%... MySQLの障害解析方法。ロックについても触れられている https://qiita.com/muran001/items/14f19959d4723ffc29cc
■サーバが重い・サーバに繋がらない 14
auのAndroidスマートフォンからアクセスできないという問い合わせがあった 「ウイルスバスター for au」のようなソフトを入れられてるようで、その防御レベルを高に設定していると入れないらしい 「ウイルスバスター for au」簡易マニュアル https://www.au.com/content/dam/au-com/static/designs/extlib/pdf/mobile/service/smartphone/safety/vir... 上記にソフトのマニュアルがあり、P.8に規制対象のカテゴリがある 「高」にしているとかなりのサイトが規制対象になるため、「中」に設定してもらうように案内
■サーバが重い・サーバに繋がらない 15
7月6日10時ちょうどに、某学校サーバのプロセス数が急激に増えた ブラウザからアクセスしても、トップページが表示されない Zabbixで確認すると、ロードアベレージ・Network・プロセス数が、10時ちょうどに急激に上がっている SSHではアクセスできたので、直接ロードアベレージを確認 $ uptime 10:03:46 up 611 days, 13:40, 1 user, load average: 5.57, 5.47, 3.03 負荷はかなり高い プロセスを確認。httpdが大量にある(250行ほど表示された。通常なら100行ほどのサーバ) $ ps aux | grep httpd apache 475 0.1 0.7 114792 66292 ? S 09:37 0:03 /usr/sbin/httpd apache 713 0.1 0.7 115132 65492 ? S 09:42 0:02 /usr/sbin/httpd apache 725 0.2 0.7 115140 66224 ? S 09:42 0:03 /usr/sbin/httpd apache 739 0.2 0.7 114668 66040 ? S 09:43 0:03 /usr/sbin/httpd apache 780 0.2 1.0 131952 83556 ? S 09:43 0:03 /usr/sbin/httpd 〜略〜 apache 1576 0.3 0.7 115000 65516 ? S 09:59 0:01 /usr/sbin/httpd admin 1831 0.0 0.0 5096 800 pts/0 S+ 10:06 0:00 grep httpd root 3916 0.0 0.7 110452 66000 ? Ss 2016 78:09 /usr/sbin/httpd apache 20691 0.0 0.6 101556 55276 ? S Jul01 0:00 /usr/sbin/httpd apache 32399 0.1 0.7 114692 66188 ? S 09:26 0:04 /usr/sbin/httpd Apacheのアクセスログを確認 以下のようなログが大量に記録されている Apacheが処理を捌ききれなくなっていると思われる # vi /var/log/httpd/access_log ::1 - - [06/Jul/2018:09:56:23 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)" ::1 - - [06/Jul/2018:09:56:24 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)" ::1 - - [06/Jul/2018:09:56:25 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)" ::1 - - [06/Jul/2018:09:56:26 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)" ::1 - - [06/Jul/2018:09:56:27 +0900] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.2.3 (Red Hat) (internal dummy connection)" 単純にアクセスが多すぎて捌ききれなくなった可能性が高い ロードアベレージは徐々に下がりつつあったのでしばらく様子を見ていると、HTTPDでアクセスできるようになった トップページに「重要なお知らせ」として以下が掲載されている 恐らく学校が「休講に関する情報はホームページで確認してください」のアナウンスを出し、 これを確認するためにアクセスが集中したと思われる - - - - - - - - - - - - - - - - - - - - 2018/07/06 7月6日(金)大雨に伴う終日全学一斉休講について 2018/07/05 【緊急のお知らせ】7月6日(金)大雨に伴う全学一斉休講について - - - - - - - - - - - - - - - - - - - -
■ドメイン経由でサーバに繋がらない
ドメインの契約が切れていないか? ドメインやDNSの設定を変更していないか? などを確認する。それ以外に、以下のような原因も考えられる 規約の変更により、ドメインの認証が必要になることがある https://muumuu-domain.com/?mode=info&id=2927 以下のようなページでニュースを確認する(契約サービスのニュースを確認する) https://muumuu-domain.com/?mode=info DoS攻撃によりネームサーバに障害が発生することがある http://support.sakura.ad.jp/mainte/mainteentry.php?id=20072 以下のようなページでニュースを確認する(契約サービスのニュースを確認する) http://support.sakura.ad.jp/mainte/
■SSHで認証できない 1
以下を確認する ・接続情報が正しいか ・IP制限など、何らかの制限を解除し忘れていないか ・ホームディレクトリのパーミッションが777になっていないか ・authorized_keysを読み込む権限があるか(鍵認証の場合) ・/var/log/secure にエラーメッセージが記録されていないか
■SSHで認証できない 2
「突然SFTPで接続できなくなった」という連絡。ログを確認すると、以下のエラーが記録されている cat /var/log/secure Dec 19 10:46:45 web1 sshd[28546]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 10:47:00 web1 sshd[28548]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 10:47:06 web1 sshd[28550]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 10:47:16 web1 sshd[28552]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 10:47:27 web1 sshd[28554]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 10:47:38 web1 sshd[28556]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 10:53:03 web1 sshd[28592]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 11:07:00 web1 sshd[28790]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] Dec 19 13:19:08 web1 sshd[31606]: Received disconnect from 60.45.118.201: 11: do_connect error [preauth] 手元の環境で試すと認証でき、IP制限なども無い 原因不明だったが、接続側の設定ミスかもしれない 以下、解決したという内容のメッセージ 「一から再設定しましたら、接続できるようになりました。  恐らくどこかのタイミングでFTP設定欄の値を削ってしまったのかもしれません。」
■SSHで認証できない 3
何らかのトラブルで負荷が高くなりすぎて、SSHログインすらできなくなることがある 接続時、 ssh -v 203.0.113.1 のようにオプション v を付けるとデバッグ情報が表示される コントロールパネルなどからサーバを再起動できるなら試す
■特定のサービスが動作していない
psコマンドで起動しているか確認。起動していなければ起動させる # ps aux | grep httpd 自動起動の設定を行っていない場合、OS再起動時に停止してしまうので確認する # chkconfig --list httpd httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off … 2〜5が「on」になっていれば自動起動 自動起動に設定 # chkconfig httpd on
■アクセスログにHTTPステータスコード206が連続表示される
DoS攻撃とは限らないので注意。 HTTPステータスコード「206」について。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1192824606 ステータスコード206はバイトレンジリクエストなどと呼ばれているものです。 大きなバイナリデータを転送する際、全てではなく一部をキャッシュし、 再度アクセスする際に一部分だけをリクエストするという、チャンク通信の効率を上げるためのものです。 ですので、206がログに上がること自体はPDF参照においては正常な動作だと思います。
■topコマンドを使えない
Poderosaで発生。コマンドを実行すると 'kterm': unknown terminal type. と表示される。xtermに切り替えると使える 原因不明だが、xtermが標準的なターミナルエミュレータなので普段からxtermにしておくと良さそう
■SSLを設定しても「プライバシーが保護されません」などが表示される
中間証明書をインストールしていなかったり、正しくインストールできていない場合に表示されるみたい 「Androidでだけ警告が表示される」などがあるので、色々な環境で表示確認をしておく OS X でSSL証明書が壊れることがある。Yosemiteで発生することがあるみたい ブラウザにパスワードを記録したときに壊れることがあるらしい MacをOS X El CapitanにしたらApp StoreとかTwitterに繋がらなくなった時の解決方法 http://dev.classmethod.jp/etc/mac-os-x-el-capitan-app-store/
■Webページを書き換えられている
「ドメイン経由でサーバに繋がらない」を参照 問題なければ ・作業ミスで書き換えてしまっていないか? ・サーバに侵入されて書き換えられていないか? ・Webアプリケーションの管理画面に侵入されて書き換えられていないか? などを確認する
■PHPで Strict Standards: date() が表示される
タイムゾーンの設定が必要 date() It is not safe to rely on the systems timezone settings date関数で”Asia/Tokyo・・”なんかのエラーが出る件:PHP5.1.0以降 http://www.res-system.com/weblog/item/563
■PHPで Warning: strtotime() が表示される
タイムゾーンの設定が必要 PHPで「Warning: strtotime()〜」のエラーが出た時 http://ivystar.jp/programming/php/php%E3%81%A7%E3%80%8Cwarning-strtotime%EF%BD%9E%E3%80%8D%E3%81%AE%...
■PHPでPOSTデータの内容が途切れる
PHP5.3.9以降では max_input_vars という設定が設けられており、入力データ数が多すぎる場合は自動的にデータがカットされる 初期値は1000なので、入力欄を1500個並べても、PHP側で受け取れるのは1000個まで。 以下は2000個まで受け取るための設定例 # vi /etc/php.ini
max_input_vars = 2000
PHPのPOSTパラメータ数の上限トラップ - Qiita https://qiita.com/bami3/items/c23cd94a6e9297649610 max_input_vars対策にデータをまとめて送信 | refirio.org http://refirio.org/view/342
■PHPでファイルをアップロードできない / タイムアウトする
PHPの初期設定では2MBまでしか受け付けない。それ以上のサイズだと、ファイルを選択しなかったときと同じ扱いになる php.iniや.htaccessで、upload_max_filesizeとそれに関連する設定を変更する必要がある。 以下は256MBまで受け付けるための設定例 # vi /etc/php.ini
max_execution_time = 600 memory_limit = 512M post_max_size = 288M upload_max_filesize = 256M
PHPでファイルアップロードサイズの上限を変更 http://refirio.org/view/347 ■nginx Webサーバにnginxを使用している場合、「413 Request Entity Too Large」というエラーになる client_max_body_sizeの設定が必要 # vi /etc/nginx/nginx.conf
server { client_max_body_size 256M;
# service nginx reload Nginx での 413 Request Entity Too Large エラーの対処法 - Qiita https://qiita.com/takecian/items/639deeae094466de6546 また先の手順で php.ini を編集した後、以下のように php-fpm を再起動する必要がある # service php-fpm restart ■タイムアウト PHPのタイムアウト設定は、主に以下を確認する # vi /etc/php.ini
max_input_time = 60 … ユーザからのアップロードを受け付ける秒数 max_execution_time = 600 … スクリプト実行時間
Apacheの場合は以下も設定する # vi /etc/httpd/conf/httpd.conf
Timeout 60 … リクエストを受け取ってから処理完了までの待機時間
PHPでファイルをアップロードするときの設定 http://www.maidsphere.jp/archive/PHP%E3%81%A7%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E3%82%A2%... nginxの場合は以下も設定する(未検証) Nginx+PHP-FPMでタイムアウトを伸ばす - WP Advisor https://hacknote.jp/archives/2594/ ■データベース アップロードファイルをデータベースに保存する場合、データベースの設定にも影響を受ける サーバのログファイルに PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 7680 bytes) というエラーがあったり、アップロード時に画面に SQLSTATE[HY000]: General error: 2006 MySQL server has gone away と表示されたりする場合、データベースの設定が原因の可能性がある。 MySQLの場合、max_allowed_packetの上限を上げればいい。 通常のMySQLならmy.cnfで設定、RDSならパラメータグループの編集で対応できる。 (パラメータグループの反映にはRDSの再起動が必要と紹介されているが、再起動しなくても反映された。) インポート時に「MySQL server has gone away」が発生したときの対処 http://company.nankikumano.jp/contents/tech_info/104/ Amazon RDS編〜大きなデータのインポート(MySQL server has gone awayが発生した時)編〜 http://recipe.kc-cloud.jp/archives/3963
■PHPから MySQLに接続できない
何故か php-mysql の再インストールで直った サーバをほとんど触っていない時に対処したものなので、今後発生した場合はきちんとした原因究明を推奨 CentOSにPDOインストールするメモ http://d.hatena.ne.jp/toytools/20070813 # yum install php-mysql # service httpd restart
■MySQLに接続しようとすると Unknown table engine 'InnoDB' と表示される
/etc/my.cnf を編集してMySQLを再起動した直後に発生した 特定のファイルを削除し、MySQLを再起動する必要がある 【MySQL】Unknown table engine ‘InnoDB’。 http://note.onichannn.net/archives/1799 innodb_log_file_size を変えたら ib_logfile* の削除が必要 http://qiita.com/phanect/items/1e09925ade0190d713ca # rm /var/lib/mysql/ib_logfile* # service mysqld restart
■MySQLに接続しようとすると Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' と表示される
※未検証 常に発生するならMySQLの再起動を試す $ sudo /etc/init.d/mysqld restart それでも駄目なら、手動で mysql.sock を作るといいらしい $ sudo touch /var/lib/mysql/mysql.sock $ sudo chown mysql:mysql /var/lib/mysql/mysql.sock MySqlのソケットエラーを解決する - Qiita https://qiita.com/kanohisa/items/564035efd74d9c75bdcb ただし稼働中のサーバで、常にではなく時々発生している メモリ不足や同時接続数の問題で、たまたま mysql.sock を読み込めなかった…とかかも
■MySQLに接続しようとすると Lock wait timeout exceeded; try restarting transaction と表示される
トランザクションの途中で処理が終了してしまった際、 コミットもロールバックもされていないとロックを取得したまま処理が残ることがある 「SHOW PROCESSLIST」と「SHOW INNODB STATUS」でスレッドを調べ、「KILL」で終了させる transactionの途中でトランザクションが切れてしまった時にそのトランザクションを殺す方法 - Garbage in, gospel out http://libitte.hatenablog.jp/entry/20141129/1417254010 トランザクションを強制的に終了させる - HHeLiBeXの日記 正道編 https://hhelibex.hatenablog.jp/entry/20110329/1301421815
■MySQLのデータベース破損を修復
■mysqlcheckで修復 テーブルが壊れているかと思ったので、mysqlcheckで修復したときのメモ http://qiita.com/tachitechi/items/e8fd8f8fbf34a3bd884d mysqlcheck -c -u root -p --all-databases … すべてのデータベースを確認 mysqlcheck -c test -u root -p … testデータベースを確認 mysqlcheck -a -u root -p --all-databases … すべてのデータベースを分析 mysqlcheck -a test -u root -p … testデータベースを分析 mysqlcheck -o -u root -p --all-databases … すべてのデータベースを最適化 mysqlcheck -o test -u root -p … testデータベースを最適化 mysqlcheck -r -u root -p --all-databases … すべてのデータベースを修復 mysqlcheck -r test -u root -p … testデータベースを修復 ■SQLで修復 CHECK TABLE テーブル名; … 破損を確認 REPAIR TABLE テーブル名; … 破損していれば修復 CHECK TABLE テーブル名; … 再度確認
■MySQLで意図した値を参照できない
MySQLのトランザクション分離レベルはデフォルトで REPEATABLE READ となっていて、 この場合に意図しない挙動になることがある programming.txt の「MySQLで意図した値を参照できない」を参照
■FTPソフトで時差が発生する
# vi /etc/vsftpd/vsftpd.conf
use_localtime=YES … 設定があればコメントアウトする
■FTPソフトで.htaccessが表示されない
# vi /etc/vsftpd/vsftpd.conf
force_dot_files=YES … 最後に設定を追加する
# service vsftpd restart FileZillaなら、ソフトウェア側の設定で表示されることもある メニューの「サーバ → 強制的に隠しファイルを表示」にチェックを入れて試す
■メールを送信しても届かない / 迷惑メールとして処理される 1
Aレコード、SPFレコード、TXTレコードの設定などを行う 具体的な内容は aws.txt の「メールを送信する際、迷惑メール扱いされないための設定」を参照 送信元サーバ(アドレス)を改変している場合に、突然迷惑メール扱いされることが増えた場合、 そのドメインにSPF・TXTレコードが最近設定された可能性はある (以前は設定されていなかったが、迷惑メール対策に後から追加されることはある) 以下のようなコマンドで、SPF・TXTレコードが設定されているかどうかは判る $ dig refirio.net any そもそも送信元サーバの改変は非推奨だが、 どうしても改変が必要ならドメインの所有者にSPF・TXTレコードを設定してもらう必要がある
■メールを送信しても届かない / 迷惑メールとして処理される 2
サーバのホスト名を設定していない場合、メールの送信元ドメインも適切なものにならない これが原因で、環境によってはメールが届かないことがある(迷惑メール対策を厳しく行っている場合など) サーバ用にドメイン(もしくはサブドメイン)を用意し、 hostname /etc/hosts /etc/sysconfig/network でホスト名に設定する。(例えば test-server.refirio.net などを設定する) DNS側でも test-server A 203.0.113.1 のように設定しておく 送信されるメールのメールヘッダが Received: (from apache@localhost) by ip-172-31-22-116.ap-northeast-1.compute.internal (8.14.4/8.14.4/Submit) このような状態から Received: (from apache@localhost) by test-server.refirio.net (8.14.4/8.14.4/Submit) id u8E9t7Oc017547 のような状態になればOK メールが届くか様子を見る
■メールを送信しても届かない / 迷惑メールとして処理される 3
■IP拒否 その1 以下を参考に、受信拒否リストからの削除依頼で届くようになることがある リストから除外のポータルを使って、Office 365 の受信拒否リストから自分自身を削除する https://technet.microsoft.com/ja-jp/library/mt661881(v=exchg.150).aspx ■IP拒否 その2 企業が独自にIP拒否を行っている可能性がある(AWSサーバからの一斉拒否、など) その場合、IPアドレスを知らせて許可してもらう ■AOL AOLは一般的に届かないことが多いらしい 当社からのメールが受信できないお客様へ http://www.ats.co.jp/mailmissing.html マイクロソフトHotmail(MSN)のメールアドレスをご使用の方へ http://www.atn-pc.com/index-00000atnbuy3.html AOL曰く 「AOLでは対処方法を提示できませんので、対象の方との連絡については、別途の方法をご検討ください」 とのこと 一部のメールアドレスと送受信できない http://info.aol.jp/mail/help02401/ どうやらAOLは、AOLユーザ同士のやりとり以外を重視していないらしい 「AOLは届かないことが多いので、他のアドレスを使ってください」と案内しておくのが安全そう ■Hotmail Hotmailも届かないことが多いらしい 『ホットメールをお使いの皆様へ』-北海道.co.jp- http://www.origotou.net/hajimete/hotmail_faq.htm ■Ezweb ezweb.ne.jpも厄介らしい ・届く場合と届かない場合がある ・ezwebはエラーがあってもエラーを返さないので調査が困難 ・ドメイン指定受信以外に「なりすまし規制」設定の変更で届くことがある ・同じサーバから送っても、本文の差でなりすまし規制に引っかかった…という可能性はゼロではない Gmailからau(ezweb)にメールが届かない!原因と対策 - NAVER まとめ https://matome.naver.jp/odai/2147045052147274001 ■メールアドレスの存在確認 単純にメールの送信先を間違っている可能性がある 精度は不明だが、以下のツールでメールアドレスの存在を確認できる メールアドレス存在・生存・死活確認ツール http://address-kakunin.com/
■ZabbixでSSHを監視できない
SSHのポート番号を10022に変更している場合、以下の設定を行う 「設定 → ホスト → アイテム」で「Template_Linux:SSH server is running」を複製し、 説明 : SSH(10022) server is running キー : net.tcp.service[ssh,,10022] を作成する 「設定 → ホスト → トリガー」で「Template_Linux:SSH server is down on {HOSTNAME}」を複製し、 名前 : SSH(10022) server is down on {HOSTNAME} 条件式 : {refirio.net:net.tcp.service[ssh,,10022].last(0)}=0 を作成する これでSSHの監視対象が10022番ポートになる (「アイテム → トリガー」の順で作成しないとエラーになる) 補足: net.tcp.service[tcp,,10022] ではなく net.tcp.service[ssh,,10022] にしておくと、返ってきた値がsshとして正しいか判定する?
■ZabbixでFTPを監視できない
Zabbixは10055番ポートで対象サーバにアクセスし、そこから127.0.0.1として各サービスを監視する 従ってFTPにアクセス制限を設けている場合、ローカルからFTP接続できるようにする必要がある # vi /etc/hosts.allow
vsftpd: 127.0.0.1
421 Service not available. で FTP の get が失敗する http://tooljp.com/linux/faq/709FC95863056BEC49257CAC005F00B4.html
■Zabbixで管理画面が表示されない
Zabbix(Webフロントエンド)がデータを返さない http://blog.5v-gnd.net/archives/1070 WordPressで画面真っ白や502エラーの原因は「eAccelerator」だった http://www.multiburst.net/sometime-php/2010/06/eaccelerator/ php_flag eaccelerator.enable 0 php_flag eaccelerator.optimizer 0 この設定を追加すれば直ることがある zabbixのドキュメントルート /usr/share/zabbix それでも駄目ならhttpdの再起動で直ることがある。 # service httpd restart
■chkrootkitが誤動作する
chkrootkit 誤検知の対応方法 http://qiita.com/KoriCori/items/4094e79a7d7fc0329117 chkrootkit report in refirio.net Checking `bindshell'... INFECTED (PORTS: 37998) というCron実行メールが届く rootkitを仕掛けられた可能性があるが、誤検知の可能性があるので以下で様子を見る [root@web1 ~]# chkrootkit | grep INFECTED … サーバ上で再度確認 Checking `bindshell'... INFECTED (PORTS: 37998) [root@web1 ~]# lsof -i -P | grep 37998 … 該当ポートを使用しているプロセスを確認 rpc.statd 2125 rpcuser 10u IPv6 9324 0t0 TCP *:37998 (LISTEN) [root@web1 ~]# netstat -anp | grep 37998 tcp 0 0 :::37998 :::* LISTEN 2125/rpc.statd [root@web1 ~]# ls /etc/init.d/ | grep rpc rpcbind rpcgssd rpcidmapd rpcsvcgssd AWSのマウントでハマった時のメモ http://qiita.com/shoya/items/009ca1e06d6d9c9f2e67 rpcbindを再起動すると直るかも? 今回は原因不明だったが、yumですべてをアップデートしてサーバを再起動すれば表示されなくなった
■Clam AntiVirus(アンチウィルスソフト)からログファイルがロックされているとエラーが来る
以下の内容が大量に記録されたCron実行メールが届く ERROR: /var/log/freshclam.log is locked by another process ログを確認すると、以下のメッセージが何度も記録されていた # vi /var/log/freshclam.log
[LibClamAV] cli_loadldb: logical signature for Email.Trojan.Toa-5493297-0 uses PCREs but support is disabled, skipping
Clam AntiVirus 自体の問題かもしれないが、アップデートすればエラーが出なくなった # yum update clamav AWSのClamavとPCRE http://d.hatena.ne.jp/tetsuya_odaka/20160927/1474957752 その他参考になりそうなページ /var/log/freshclam.log is locked by another process https://www.shigizemi.com/2012/12/23/freshclam-log-is-locked-by-another-process/ Clam AV http://takeshou.blogspot.jp/2009/10/clam-av.html Debian 8 (Jessie) - アンチウイルスソフト導入! http://www.mk-mode.com/octopress/2015/05/29/debian-8-anti-virus-installation/ freshclam の更新がうまくいきません。 https://forums.ubuntulinux.jp/viewtopic.php?pid=112772 ClamAVがアップデートした際にfreshclamが正常に動かない http://www.sys-cube.co.jp/blog/995.html
■yumを実行できない
/etc/yum.conf に例えば以下の設定がある場合、yum install php-xml など、追加インストールも行えなくなる (依存性を解決できない、と言われたりする) いったん設定を無効にしてyumを実行する [main] exclude=gcc* glibc* kde* openssh* kernel* httpd* php* mysql*
■ディスク容量が残り少ない
根本解決にはディスクの容量アップが必要だが、不要ファイルを削除することで対処できることがある /var/cache/yum の容量は大きくなりがちなので、クリーンすることで容量を減らすことができる /var/cache/ 内のデータをすべて削除するのは危険 # du -s /var/cache/* | sort -nr 2226060 /var/cache/yum 1792 /var/cache/man 48 /var/cache/fontconfig 28 /var/cache/ldconfig 12 /var/cache/rpcbind 4 /var/cache/mod_ssl 4 /var/cache/mod_proxy 4 /var/cache/logwatch # yum clean all 読み込んだプラグイン:fastestmirror, priorities, update-motd, upgrade-helper リポジトリーを清掃しています: amzn-main amzn-updates Cleaning up everything Cleaning up list of fastest mirrors # du -s /var/cache/* | sort -nr 34660 /var/cache/yum 1792 /var/cache/man 48 /var/cache/fontconfig 28 /var/cache/ldconfig 12 /var/cache/rpcbind 4 /var/cache/mod_ssl 4 /var/cache/mod_proxy 4 /var/cache/logwatch /var/cache 下のファイルは消して良いのか http://qiita.com/amedama/items/eee14483b86de2842c42 ディスク容量がいっぱいの時にやる事 http://qiita.com/oshou/items/2630f9f1c1131beb748e
■inodeが残り少ない
Linuxではファイルやディレクトリに重複しない番号が割り振られていて、これをinodeと呼ぶ この番号は、パーティションサイズにより上限が定められている つまりサイズの小さいファイルを大量に作成すると、 データ領域の容量に余裕があっても新規にファイルやディレクトリを作成できなくなる 古いログファイルは削除するなどして、容量を確保する $ df -ih … ファイル削除前にinodeを確認(91%使用) ファイルシス Iノード I使用 I残り I使用% マウント位置 /dev/xvda1 2.0M 1.9M 199K 91% / devtmpfs 248K 428 248K 1% /dev tmpfs 251K 1 251K 1% /dev/shm # df -ih … ファイル削除後にinodeを確認(55%使用) ファイルシス Iノード I使用 I残り I使用% マウント位置 /dev/xvda1 2.0M 1.1M 928K 55% / devtmpfs 248K 428 248K 1% /dev tmpfs 251K 1 251K 1% /dev/shm 以下のようにすれば、カレントディレクトリ以下のinode使用量をディレクトリごとに表示できる ただしrootディレクトリなど対象ファイルの多い場所で実行すると遅い # for i in `ls -1`;do echo "`find ./$i -type f |wc -l` ... $i" ;done | sort -nr 例えば /var/log/command/uptime 内に 20160401, 20160402, 20160402 のようなディレクトリごとにログファイルを記録している場合、 それらをまとめて 2016.zip としてバックアップしてから2016年のデータを削除するには以下のようにする # cd /var/log/command/uptime # zip -r 2016.zip 2016*/ # rm -rf 2016*/ iノード(inode)とは http://kazmax.zpp.jp/linux_beginner/inode.html Linuxでファイル名が文字化けして消せないファイルを、inode番号を指定して削除する方法 http://hamamuratakuo.blog61.fc2.com/blog-entry-1025.html inodeとは/inode消費が多いディレクトリの確認 http://tagutagu.com/?page_id=985
■AWSでPHPからMySQLに接続するための命令をインストールできない
sudo yum install php-mysql を実行して Error: php55-common conflicts with php-common-5.3.29-1.7.amzn1.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest のようなエラーになる場合、 Full Update to PHP5.5 on Amazon Linux http://serverfault.com/questions/566662/full-update-to-php5-5-on-amazon-linux などを参考にしつつ以下のコマンドを入力 sudo yum remove php-common sudo yum install php55 sudo yum install php55-mysqlnd sudo service httpd restart PHPからmysql_connect()とPDOの両方で接続できるようになった 他の人が管理しているサーバだったので、PHPを正しく設定できていなかっただけかも sudo yum install php55-mysqlnd sudo service httpd restart だけでも良かったかも(要検証)
■ミドルウェアなどを起動できない
はじめからインストール&起動されていないか確認する 例えば # ps aux | grep http とすれば、httpが起動しているかどうか確認できる
■/var/log/messages に「kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }」と記録される
ハードディスクへの書き込みエラー ハードディスクが物理的に故障している可能性がある エラーログで障害原因を突き止めろ! | Think IT(シンクイット) https://thinkit.co.jp/article/736/1
■さくらの専用サーバで再起動できない
コンソールでシャットダウンを押してもシャットダウンが始まらない。 15分ほど待っても何も起きないのでさくらに再起動を依頼。 機器リブート(サーバ再起動) http://www.sakura.ad.jp/function/security/reboot.html さくらのID、自身の名前、対象サーバのIPアドレスを連絡する必要がある。 依頼してから15分後くらいに連絡があり、再起動をしてくれた。 諸々の確認作業があるので、即座に再起動はできないらしい。 シャットダウンが始まらなかった原因は不明。