俺メモ
cronの実ファイルの場所は
/var/spool/cron/[ユーザ名]
で確認。各ユーザにてcrontab -l で内容を取得
hourly等の確認も併せると以下の様にして確認している
crontab -l
ll /var/spool/cron/
ls -la /etc/cron.d
ll /etc/cron*
# バックアップ
su -
crontab -l -u fuga > /hoge/fuga_cron.txt
など
俺メモ
cronの実ファイルの場所は
/var/spool/cron/[ユーザ名]
で確認。各ユーザにてcrontab -l で内容を取得
hourly等の確認も併せると以下の様にして確認している
crontab -l
ll /var/spool/cron/
ls -la /etc/cron.d
ll /etc/cron*
# バックアップ
su -
crontab -l -u fuga > /hoge/fuga_cron.txt
など
RAID1でミラーリングしていたI-O DATA HDS2-UTX8の、HDD2のランプが赤点灯。
http://www.iodata.jp/lib/manual/pdf2/hds2-utx_hdd_b-manu202222_m-manu201471.pdf
こちら「HDD故障時の対応」によれば、「該当のHDDが故障しています」とのこと。
「交換用HDDは必ず弊社製オプション品の交換用HDDをご使用ください。」とあるが、
交換用のディスク「HDUOPX-4」は直販サイトwww.ioplaza.jpだと
¥ 38,664
とかだった。故障したHDD引っこ抜いてみてみたらSeagateのST4000DM004
http://amzn.to/2HMymkl
¥ 9,150
だったのでこれを注文(BUFFALOといいI-Oといい、NAS周りの「正規」交換用HDDの値付けは謎が多い)。
上記故障時の対応のHDD交換方法に従い、
→再構築完了までは約8.0時間
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
いけてる