df -h Filesystem Size Used Avail Use% Mounted on /dev/vda3 18G 12G 5.5G 68% / tmpfs 939M 0 939M 0% /dev/shm /dev/vda1 94M 84M 4.6M 95% /boot yum install yum-utils package-cleanup --oldkernels --count=2 Removed: kernel.x86_64 0:2.6.32-431.el6 kernel-devel.x86_64 0:2.6.32-431.el6 df -h Filesystem Size Used Avail Use% Mounted on /dev/vda3 18G 12G 5.6G 67% / tmpfs 939M 0 939M 0% /dev/shm /dev/vda1 94M 61M 28M 69% /boot
タイトルの通り。
総SSL化したWordpressでBackWPupが止まっていることに気づいた。
BackWPupの[情報]に曰く、
cURL のバージョン 7.19.7 cURL SSL のバージョン NSS/3.27.1 WP-Cron URL: https://hogehoge.com/wp-cron.php サーバーの自己接続: 期待された HTTP レスポンスではありません: WP Http エラー: cURL error 35: SSL connect error
実際にシェルからcurlで自URLをたたくと以下のエラーが出る
curl https://hogehoge.com/wp-cron.php curl: (35) SSL connect error
総SSLサイトで、自分自身を呼び出している処理について、nss（Network Security Services）のバージョンが古くて自分自身が正常に呼び出せなかった模様。
yum update nss # Updated: # nss.x86_64 0:3.28.4-4.el6_9 # # Dependency Updated: # nspr.x86_64 0:4.13.1-1.el6 # nss-sysinit.x86_64 0:3.28.4-4.el6_9 # nss-tools.x86_64 0:3.28.4-4.el6_9 # nss-util.x86_64 0:3.28.4-1.el6_9
# 確認
curl https://hogehoge.com/wp-cron.php
→エラーは出なくなった
# BackWPupが動作するか？
php-fpmの再起動で動作するようになった。
https://qiita.com/shunsuke_takahashi/items/a1c3655584530c76fbe0
CentOS6.xのlibcurlが古くてcurl: (35) SSL connect errorが発生する件
http://wpblogdiy.com/domain/1027sslbackwpuperror/
SSLを回避している人
http://thr3a.hatenablog.com/entry/20170623/1498159546
どうやらNSSが悪い
さくらのVPSの開発環境のネットワーク送出がハネてるなとおもったらさくらから警告あり。
https://www.sakura.ad.jp/news/sakurainfo/newsentry.php?id=1885www.sakura.ad.jp
memcached の設定によっては、意図せずインターネットからアクセス可能な状態になっており、
（中略）攻撃の踏み台にされたり、memcached が保持する情報へアクセスされたりする可能性があります。
CentOS6環境だったので以下で対応
# 事前確認
netstat -nlp | grep memcached tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN 1388/memcached tcp 0 0 :::11211 :::* LISTEN 1388/memcached udp 0 0 0.0.0.0:11211 0.0.0.0:* 1388/memcached udp 0 0 :::11211 :::* 1388/memcached
less /etc/init.d/memcached
→/etc/sysconfig/memcacehdの設定が後から読み込まれてたのでこちらを修正する
cp -p /etc/sysconfig/memcached /etc/sysconfig/memcached_bak
Docker上で動かしていたcollabora onlineで巨大なスプレッドシートを開いたらメモリ＋swapを一気に使い尽くしてOSごとお亡くなりになった。
dockerのメモリソフトリミット（--memory-reservation）セットして再挑戦したらいけた。
# メモリのソフトリミット1GB
docker run -td --memory-reservation 1g hogefuga
# 確認
dovker stats
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS xxxxxxxxxxxx 0.78% 1.005 GiB / 3.86 GiB 26.03% 480 MB / 1.64 GB 28.9 GB / 761 MB 0
いけてる
duコマンドは、ファイルサイズではなくブロックサイズで表示するので正確な数値が表示されない。
http://sonic64.com/2004-05-26.html
http://blue-red.ddo.jp/~ao/wiki/wiki.cgi?page=%A5%C7%A5%A3%A5%EC%A5%AF%A5%C8%A5%EA%A4%CE%CD%C6%CE%CC%A4%F2%C4%B4%A4%D9%A4%EB
find ./ -type f -printf "%s\n" |awk '{ sum += $1; }; END { print sum }'で正確なファイルサイズの合計が表示される
du -hとしたらサーバAとBでサイズが違う
du -h [サーバA] 8.0K ./sample/jnlp/servlet/src/classes/jnlp/sample/jardiff/resources 52K ./sample/jnlp/servlet/src/classes/jnlp/sample/jardiff 16K ./sample/jnlp/servlet/src/classes/jnlp/sample/util 8.0K ./sample/jnlp/servlet/src/classes/jnlp/sample/servlet/resources 124K ./sample/jnlp/servlet/src/classes/jnlp/sample/servlet 196K ./sample/jnlp/servlet/src/classes/jnlp/sample 200K ./sample/jnlp/servlet/src/classes/jnlp 204K ./sample/jnlp/servlet/src/classes 1.4M ./sample [サーバB] 16K ./sample/jnlp/servlet/src/classes/jnlp/sample/jardiff/resources 80K ./sample/jnlp/servlet/src/classes/jnlp/sample/jardiff 28K ./sample/jnlp/servlet/src/classes/jnlp/sample/util 16K ./sample/jnlp/servlet/src/classes/jnlp/sample/servlet/resources 184K ./sample/jnlp/servlet/src/classes/jnlp/sample/servlet 300K ./sample/jnlp/servlet/src/classes/jnlp/sample 308K ./sample/jnlp/servlet/src/classes/jnlp 316K ./sample/jnlp/servlet/src/classes 2.2M ./sample
find ./sample -type f -printf "%s\n" |awk '{ sum += $1; }; END { print sum }'
[サーバA]
861865
[サーバB]
861865先人の知恵に感謝しつつリブログ
