ホーム » コンピュータ (ページ 66)

「コンピュータ」カテゴリーアーカイブ

システム

最近の投稿

アーカイブ

カテゴリー

squidの設定見直し

2015-09-14

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

サーバの不調(part2)

2015-09-10

今朝も再びサーバが不調となった。

不調時のkernel log

改めて、不調となる時間帯の 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

一応 xfs の repair も実行

最近の不調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 を入れてみた。 その後は、ひとまず安定している様子だ。

STB1000の電池交換

2015-09-07

最近は、Bluetooth連携機能のあるCASIO STB-1000を愛用しているが、 バッテリー低下の表示が出て、携帯とのリンクが切れた。

といっても、10ケ月で2回目。今後も頻繁に変える可能性もあり、 自分で CR2032 を購入し、電池交換方法を解説している ページを参考に、交換。 ボタン電池カバーのフックや、電池を浮かせるためには、 針が必須。

説明書には、ボタン電池で2年持つとか書いてあるけど、 ほぼ5か月での交換。交換後の再設定で通知方法を 電子音から『振動』に変更するとき 「電池の消耗が早くなる…」との注意表示もあるし、 説明書の2年というのは、電子音だけの場合なんだろう。

このため、改めて通知設定を電子音に変更しようと、 設定を改めて確認してみる。 しかし、STB-1000を導入した理由自体、「通知を人知れず 確認したい」からであり、振動を使うのが前提。 通知を電子音に変えたいものが無い。

 

サーバの不調

2015-09-07

子供を連れて遊びに出ている中、サーバの管理ソフトから、 色々と警告が届く。

load averageが、10を超え、プロセス数も増えている。 同じような症状は、数日前にも発生している。(その時は数十分後にreset…)

この雰囲気は、自宅サーバのマザーボードあたりが 不調と思われる。

自宅に戻り、サーバを確認するが、コンソールには何も表示されない。 再起動時の fsck も、簡単に終わったし、HDDではないと思われる。

前回のサーバ更新

前回のサーバ更新は2010年からすると、ほぼ5年目。 マザーボードあたりが壊れても仕方がない時期ではある。

そろそろ次のマシンを物色するかな…。

LOG

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

NTPの同期間隔を短く

2015-08-22

Windows10に更新して、そろそろ雰囲気にも慣れてきた。 でも、時計を見るとサーバと1分ほど時計がずれている。

Windowsのインターネット時計の設定では、同期周期が1週間らしい。 1週間で1分ずれるのも酷いけど、長く使っているPCなので我慢。

regedit を起動して、

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\W32Time\TimeProviders\NtpClient
SpecialPollInterval 604800(10進) 1週間

の値を、1日 86400(秒) に変更。

Windows Updateの配信の最適化

2015-08-20

へぇ、Windows10 のUpdateって、配信されたUpdateファイルを、 同一ネットワーク内に再配信する機能あるんだ。

だけど、早々に悪用されそうな心配をしてしまう…

1508202238_471x479.png

Windows 10にしてモニタが原因のノイズ解消×

2015-08-13

Windows 10にしてモニタが原因と思われるノイズがなくなった。

我が家のメインマシンとして使っているオールインワン型の パソコンだけど、Windows 8 にしてから、 スリープ状態になるとスピーカーからひどいノイズが出るようになっていた。

原因がわからなかったけど、スリープ状態で「モニタを消さない」設定に したら、ノイズは無くなった。

でも、今回Windows 10にしたので、モニタのドライバが新しくなった訳だし、 モニタの設定を「モニタを消す」にしてみた。 んで、今のところ「ノイズ」問題が発生していない。

やっぱり、ダメだった….

ママパソもWindows10に

ひとまず、我が家ではWindows10の導入は順調なので、 奥さんのノートパソコンもWindows10に移行。

といっても、相変わらず時間はかかったけど、特に問題なくアップグレード完了。 あるとしたら、タッチパッドのドライバが、アップグレード後の自動更新がかかった程度。

Windows10がようやく…

2015-08-02

色々と失敗があったけど、ようやくWindows10がインストールできた。

復活したメニューも、アイコンを「小」にしたら少しずれて表示されたりと、 ちょっと変なところもあるな。

古いコントロールパネルと、PC設定で、同じなのか微妙に違うのか、 Windows Updateを探すのに苦労した…

1508022040_586x626.png

Windows10のアップグレードに失敗

2015-08-02

Windows10へのアップグレードを試してみた。 延々と待たされた挙句、 0x8007002C – 0x4000D のエラーメッセージで失敗。

Webで調べると、同様の症状の人に、Microsoft アカウントとの連動が原因って 書いてあったから、一旦解除。

また、アップグレードはかける前、ウィルスバスタークラウド10を入れた後に、 Windows Update で 0x80070005 – KB2267602 (Windows Defenderの更新)で、 失敗していたので、一旦ウィルスバスター10を止めて Windows Updateを適用。

さて、今からアップグレード再挑戦。

1508021618_716x562.png

Windows10インストール再挑戦

2015-08-02

先日は、プロダクトキー入力で失敗したので、 再挑戦。

1508021046_1400x800.png

投稿ナビゲーション

← 過去の投稿 新しい投稿 →

Google 検索

My Google   Yahoo

Microsoft

ファンサイト

メタ情報