福井にできた新しい猫カフェの「福ねこ」さんに遊びに行ってきました。
オッドアイの若いオス。我が家で白猫を飼っていたので、 やっぱり遊んでみたい子でした。
2日前の午後にも行ってみたのですが、開店したてというのもあり、お客さんが一杯でした。 人がたくさんだと、猫とも触れ合えないので諦めました。 今日はリベンジということで朝イチを狙って出かけました。
猫エサのおやつをもらっての入店でしたが、 朝イチだとお腹もふくれていないし、 お客さんと遊んで疲れているということもなく、 餌おねだりで寄ってきたり猫オモチャでも遊んでくれる。 でも、1時間ほどすると猫もある程度お腹もふくれてくるし、遊び疲れてくるみたいで、 屋根のキャットウォークの隅に皆固まって休憩しだしてきた。
この福ねこさんは雑種の子ばかりで、半分以上が1,2歳の若い子猫ばかりなのもあり、 お客さんともよく遊んでくれたけど、2歳以上の大きな猫は落ち着いているし、最初から 休憩スペースに固まっていたり。
結石で腎臓が張る痛み。
最近は、石が移動してチクチクする痛みは、 一月おきぐらいの頻度でくるけど、 腎臓が張って寝付けない痛みは、数年ぶり。 七転八倒するほどではないけど……
水分は沢山摂るようにしてるんだけどなぁ〜
最近Windows環境から、自宅サーバに rlogin.exe で ssh 接続しようとすると 「get msg global request hotkeys 00@openssh.com」みたいな 警告メッセージが表示されるようになった。
調べてみると、rlogin のバージョン(2.17.x)の問題っぽい。 早々に、最新の(2.19.1) に入れ替えたら問題解決。
http://nanno.dip.jp/softlib/man/rlogin/
iPad Airなら2画面同時のスプリット機能が、使えるらしい。 でもこのiPad mini3では、スライドオーバーでの2画面。
自宅サーバ及び職場の自分用Debianサーバは、testingにて運用し、 定期的に "aptitude update ; aptitude safe-upgrade" を行っている。 でも、safe-upgrade だと、新しいパッケージが入らないままになることも多い。 このため、"aptitude full-upgrade" を行っているが、 今回は、競合パッケージがちょっと多くて、競合チェックに失敗する。
(( 定番の更新 )) # aptitude update ; aptitude safe-upgrade (( 不要パッケージの消去 )) # aptitude purge `deborphan` # aptitude install gcc-5-base libstdc++6 libgcc1 gimp gimp-data # aptitude install aptitude kdelibs-bin libopencv-core2.4v5 # aptitude install libtag1v5-vanilla libmagick++-6.q16-5v5 libtag1v5 (( ようやくfull-upgradeでの競合チェックに成功 )) # aptitude full-upgrade (( 競合でtexliveが消えちゃったので再インストール )) # aptitude install texlive-full
logrotate時の警告メッセージで下記のようなものが出ていたので、 調べてみると、squid 2.7系から3.4以降に変更の際には /etc/squid/squid.conf の修正が必要な様子。
2015/09/13 07:47:16| WARNING: (B) '::/0' is a subnetwork of (A) '::/0' 2015/09/13 07:47:16| WARNING: because of this '::/0' is ignored to keep splay tree searching predictable 2015/09/13 07:47:16| WARNING: You should probably remove '::/0' from the ACL named 'all' 2015/09/13 07:47:16| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1' 2015/09/13 07:47:16| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable 2015/09/13 07:47:16| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost' 2015/09/13 07:47:16| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1' 2015/09/13 07:47:16| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable 2015/09/13 07:47:16| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost' 2015/09/13 07:47:16| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8' 2015/09/13 07:47:16| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable 2015/09/13 07:47:16| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost' 2015/09/13 07:47:16| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0' 2015/09/13 07:47:16| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable 2015/09/13 07:47:16| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost' 2015/09/13 07:47:16| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0' 2015/09/13 07:47:16| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable 2015/09/13 07:47:16| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost' 2015/09/13 07:47:16| ERROR: Directive 'hierarchy_stoplist' is obsolete. 2015/09/13 07:47:16| ERROR: Directive 'upgrade_http0.9' is obsolete. 2015/09/13 07:47:16| ERROR: Directive 'broken_vary_encoding' is obsolete. 2015/09/13 07:47:16| ERROR: Directive 'extension_methods' is obsolete.
Warningについては、localhost とか all は、ACL を squid.con で定義しなくて良いみたいなので、 コメントアウトする。後半のErrorについても、古い設定項目なので、同様にコメントアウト。
(( /etc/squid/squid.conf )) #Recommended minimum configuration: - acl all src all + # acl all src all # acl manager proto cache_object # Commented out on upgrade to 3.4 - acl localhost src 127.0.0.1/32 - acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 + # acl localhost src 127.0.0.1/32 + # acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 - hierarchy_stoplist cgi-bin ? + # hierarchy_stoplist cgi-bin ? # Don't upgrade ShoutCast responses to HTTP - acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9] - upgrade_http0.9 deny shoutcast + # acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9] + # upgrade_http0.9 deny shoutcast # Apache mod_gzip and mod_deflate known to be broken so don't trust # Apache to signal ETag correctly on such responses - acl apache rep_header Server ^Apache - broken_vary_encoding allow apache + # acl apache rep_header Server ^Apache + # broken_vary_encoding allow apache # TAG: extension_methods # Squid only knows about standardized HTTP request methods. # You can add up to 20 additional "extension" methods here. - extension_methods REPORT MERGE MKACTIVITY CHECKOUT + # extension_methods REPORT MERGE MKACTIVITY CHECKOUT
この記事は
地域の洪水ハザードマップを調べてみたら、 一応 0.5m の浸水の可能性ありの場所になってる。
かといって、浸水の可能性のない領域の中に、 赤丸のついている浸水実績箇所もチラホラ。
今朝も再びサーバが不調となった。
改めて、不調となる時間帯の syslog, messages あたりを眺めてみると、 異常動作が始まる前に、共通して以下のようなLOGが出力されている。 どうも、kernel の cron あたりで発生。
Sep 10 09:33:50 perrine kernel: [231581.206381] cron D ffff880077456900 0 4305 1169 0x00000000 Sep 10 09:33:50 perrine kernel: [231581.206387] ffff880070e60050 0000000000000018 ffff8800744d2a20 ffffffff81466362 Sep 10 09:33:50 perrine kernel: [231581.206391] ffff880072bb8000 ffffffff8185f644 ffff880070e60050 00000000ffffffff Sep 10 09:33:50 perrine kernel: [231581.206395] ffffffff8185f648 0000000000000074 ffffffff81571eef ffffffff8185f640 Sep 10 09:33:50 perrine kernel: [231581.206398] Call Trace: Sep 10 09:33:50 perrine kernel: [231581.206409] [<ffffffff81466362>] ? __kmalloc_reserve.isra.27+0x32/0x90 Sep 10 09:33:50 perrine kernel: [231581.206415] [<ffffffff81571eef>] ? schedule+0x2f/0x80 Sep 10 09:33:50 perrine kernel: [231581.206418] [<ffffffff8157220e>] ? schedule_preempt_disabled+0xe/0x20 Sep 10 09:33:50 perrine kernel: [231581.206422] [<ffffffff81573df5>] ? __mutex_lock_slowpath+0x95/0x110 Sep 10 09:33:50 perrine kernel: [231581.206427] [<ffffffff814a750b>] ? __netlink_lookup+0xab/0xe0 Sep 10 09:33:50 perrine kernel: [231581.206430] [<ffffffff81573e8b>] ? mutex_lock+0x1b/0x30 Sep 10 09:33:50 perrine kernel: [231581.206435] [<ffffffff81107be8>] ? audit_receive+0x18/0xa0 Sep 10 09:33:50 perrine kernel: [231581.206438] [<ffffffff814a9847>] ? netlink_unicast+0x107/0x1a0 Sep 10 09:33:50 perrine kernel: [231581.206441] [<ffffffff814a9dce>] ? netlink_sendmsg+0x4ee/0x610 Sep 10 09:33:50 perrine kernel: [231581.206447] [<ffffffff8145e3bc>] ? sock_sendmsg+0x3c/0x50 Sep 10 09:33:50 perrine kernel: [231581.206451] [<ffffffff8145e82b>] ? SYSC_sendto+0xdb/0x170 Sep 10 09:33:50 perrine kernel: [231581.206455] [<ffffffff8145bb8a>] ? sock_alloc_file+0x9a/0x120 Sep 10 09:33:50 perrine kernel: [231581.206461] [<ffffffff811e7a42>] ? set_close_on_exec+0x32/0x70 Sep 10 09:33:50 perrine kernel: [231581.206466] [<ffffffff811dc5d5>] ? SyS_fcntl+0x3d5/0x600 Sep 10 09:33:50 perrine kernel: [231581.206469] [<ffffffff8145efea>] ? SyS_socket+0x8a/0xd0 Sep 10 09:33:50 perrine kernel: [231581.206475] [<ffffffff81576132>] ? system_call_fast_compare_end+0xc/0x6b
最近の不調3回のうち、2回については、上記LOGの前に、XFS の unmount のメッセージも出ていた。
XFSを使っているのは、外付け USB-HDD なので、一応、fsck.xfs を実行させておく方がいいかな...
ただ、実行させたら、代わりに xfs_repair コマンドを使えとの警告。
# umount /dev/sdc1
# xfs_repair /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 1
- agno = 0
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
前述のメッセージをみるからに、kernel の問題も考えられる。 そこで、linux-image-4.1.x を使っていたが、linux-image-4.0.x にバージョンを落とす。
i A linux-image-4.0.0-2-amd64 p linux-image-4.1.0-2-amd64
最初はマザーボードの不調かと思っていたけど、カーネルの問題っぽくって、バージョンを落としていたけど、 色々と新しい update を適用していたら、異常停止の症状が出ていない。 多少不安はあったけど、改めて linux-image-4.1 を入れてみた。 その後は、ひとまず安定している様子だ。
最近は、Bluetooth連携機能のあるCASIO STB-1000を愛用しているが、 バッテリー低下の表示が出て、携帯とのリンクが切れた。
といっても、10ケ月で2回目。今後も頻繁に変える可能性もあり、 自分で CR2032 を購入し、電池交換方法を解説している ページを参考に、交換。 ボタン電池カバーのフックや、電池を浮かせるためには、 針が必須。
説明書には、ボタン電池で2年持つとか書いてあるけど、 ほぼ5か月での交換。交換後の再設定で通知方法を 電子音から『振動』に変更するとき 「電池の消耗が早くなる...」との注意表示もあるし、 説明書の2年というのは、電子音だけの場合なんだろう。
このため、改めて通知設定を電子音に変更しようと、 設定を改めて確認してみる。 しかし、STB-1000を導入した理由自体、「通知を人知れず 確認したい」からであり、振動を使うのが前提。 通知を電子音に変えたいものが無い。
子供を連れて遊びに出ている中、サーバの管理ソフトから、 色々と警告が届く。
load averageが、10を超え、プロセス数も増えている。 同じような症状は、数日前にも発生している。(その時は数十分後にreset...)
この雰囲気は、自宅サーバのマザーボードあたりが 不調と思われる。
自宅に戻り、サーバを確認するが、コンソールには何も表示されない。 再起動時の fsck も、簡単に終わったし、HDDではないと思われる。
前回のサーバ更新は2010年からすると、ほぼ5年目。 マザーボードあたりが壊れても仕方がない時期ではある。
そろそろ次のマシンを物色するかな...。
Service: Current Load State: WARNING Host: localhost Address: 127.0.0.1 Date/Time: Tue Sept 1 04:39:17 JST 2015 WARNING - load average: 7.44, 4.97, 2.46 Service: Current Load State: CRITICAL Host: localhost Address: 127.0.0.1 Date/Time: Tue Sept 1 04:44:17 JST 2015 CRITICAL - load average: 11.96, 9.23, 4.97 Service: No-DHCP State: CRITICAL Host: homespot Address: 192.168.11.201 Date/Time: Tue Sept 1 05:17:37 JST 2015 CRITICAL - Plugin timed out after 11 seconds Service: Total Processes State: WARNING Host: localhost Address: 127.0.0.1 Date/Time: Tue Sept 1 06:27:57 JST 2015 PROCS WARNING: 320 processes
Service: No-DHCP State: CRITICAL Host: homespot Address: 192.168.11.201 Date/Time: Mon Sept 7 11:04:48 JST 2015 CRITICAL - Plugin timed out after 11 seconds Service: Current Load State: CRITICAL Host: localhost Address: 127.0.0.1 Date/Time: Mon Sept 7 11:07:08 JST 2015 CRITICAL - load average: 10.81, 6.52, 2.91 Service: Total Processes State: WARNING Host: localhost Address: 127.0.0.1 Date/Time: Mon Sept 7 12:27:48 JST 2015 PROCS WARNING: 309 processes Service: Total Processes State: CRITICAL Host: localhost Address: 127.0.0.1 Date/Time: Mon Sept 7 14:42:48 JST 2015 PROCS CRITICAL: 461 processes
この記事は
