奈酢美の部屋　別館

VCSA5.5に任意のパッケージをインストールするための方法

VCSA5.5のBaseとなっているOSを確認してみると

#cat /etc/SuSE-rekease
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
#

SuZEの11.2らしい

ただ、SNMP Trapコマンドが標準では言っていないので
YASTを使ってインストールする必要がありますが、
OSに対応したレポジトリを登録する必要があります。

http://download.opensuse.org/distribution/11.2/repo/oss/

http://ftp.twaren.net/Linux/OpenSuSE/repositories/net-snmp:/factory/SLE_11_SP2/

あとはyastコマンドでSNMPコマンドをインストールすればよいのですが、
SNMPで検索しても、net-snmp-utilパッケージが一覧でないのでちょっと戸惑いましたが、net-snmpパッケージにｓｎｍｐｔｒａｐコマンドが含まれているそうです。

また、SNMP ManagerがUTF-8を受け付けない場合があるので
その場合は、そのSNMP Managerが受け付けてくれる文字コードに変換する必要があります。

文字コードの変換にはiconvコマンドが標準に入っていたのでコレが使えます。

# echo aaaあああ | iconv -f UTF-8 -t SHIFT-JIS
aaaあああ
# str=`echo aaaあああ | iconv -f UTF-8 -t SHIFT-JIS`
# echo $str
aaaあああ
# snmptrap -v 2c -c public 192.168.50.99 '' .1.3.6.1.4.1.8072.100 .1.3.6.1.4.1.8072.100.1 s $str
#

あとはコレを組み合わせれば．．．．．

参考

https://community.spiceworks.com/how_to/101544-how-to-enable-snmp-on-vmware-vcenter-server-appliance

http://xysoft.rsucopy.com/yast-install-snmp.html

http://note.kurodigi.com/linux-charconv/

本当に参考レベルのスクリプト

#!/bin/sh
# Alarmには、以下のように登録します。
# /root/vcscript/VCTrap.sh "{eventDescription}" "{triggeringSummary}" "{newStatus}"


#送信設定
nnmIP = "10.51.100.60"
specificType = "201"


#コマンドラインパラメータ取得
eventDescription = $1
triggeringSummary = $2
newStatus = $3
#メッセージ編集
str=`echo $eventDescription ($triggeringSummary) [$newStatus]" | iconv -f UTF-8 -t SHIFT-JIS`

#SNMPTrapメッセージ送信

snmptrap -v 2c -c public $nnmIP '' .1.3.6.1.4.1.6876.4.3.6.$specificType 1.3.6.1.4.1.6876.4.3.306 s $str


#プログラム終了
exit 0

Views: 32

LinuxでDisk不足となったときの対策メモ

Zabbixで確認したら、いつのまにか /　が結構いっぱいに

実機で使用率を確認したら、

[root@QS003 ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_qs003-lv_root
 14225776 12603072 893412 94% /
tmpfs 4031236 0 4031236 0% /dev/shm
/dev/sda1 487652 81813 380239 18% /boot
[root@QS003 ~]#

/ が 94%使用中でのこり900MB前後になってました。

この時点では、どのファイルが容量を専有しているのかわからなかったので
フォルダごとのファイルサイズを確認してみると

[root@QS003 ~]# du / | sort -n -r | more
12647184 /
8440184 /var
8179000 /var/crash
3471768 /usr
2054784 /var/crash/127.0.0.1-2016-01-09-12:41:04
2049724 /var/crash/127.0.0.1-2016-01-09-13:03:28
2037424 /var/crash/127.0.0.1-2016-01-09-13:11:25
2037064 /var/crash/127.0.0.1-2016-01-09-13:24:44
1422904 /usr/share
1201232 /usr/lib64
535508 /usr/lib
412468 /usr/share/locale
368092 /usr/lib64/libreoffice
288380 /lib
233216 /usr/lib64/libreoffice/program
224476 /lib/modules
203308 /usr/lib/vmware-tools
196672 /usr/lib/jvm
175280 /usr/lib64/valgrind
174292 /usr/bin
157352 /quadstor
151240 /usr/share/doc
143980 /usr/share/gnome

/var/crashがいっぱい使っているようだ
中身を確認してみる

[root@QS003 ~]# cd /var/crash/
[root@QS003 crash]# ls
127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25
127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44
[root@QS003 crash]# ls -al
合計 24
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 .
drwxr-xr-x. 22 root root 4096 12月 30 22:38 2015 ..
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 127.0.0.1-2016-01-09-12:41:04
drwxr-xr-x 2 root root 4096 1月 9 13:05 2016 127.0.0.1-2016-01-09-13:03:28
drwxr-xr-x 2 root root 4096 1月 9 13:12 2016 127.0.0.1-2016-01-09-13:11:25
drwxr-xr-x 2 root root 4096 1月 9 13:26 2016 127.0.0.1-2016-01-09-13:24:44

このフォルダは、OSがクラッシュしたときにその履歴を保存する場所なので、
一応原因調査して削除して対応

そういえば、この時期にCentOS6.7でQuadStorを試していて、
ある特定条件でOSがPanicを起こして再起動してしまっていたので、
いろいろ調査のため何度も再現性テストをしていたのを思い出した。

そのせいでPanicのたびにダンプファイルを生成していたため
/ を圧迫してしまったようだ。

とりあえず、直近のデータ以外を残して、削除して対応。

[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al
合計 2054788
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..
-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore
-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# cd ..
[root@QS003 crash]# ls
127.0.0.1-2016-01-09-12:41:04 127.0.0.1-2016-01-09-13:11:25
127.0.0.1-2016-01-09-13:03:28 127.0.0.1-2016-01-09-13:24:44
[root@QS003 crash]#
[root@QS003 crash]#
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-12\:41\:04/
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:11\:25/
[root@QS003 crash]# rm -rf 127.0.0.1-2016-01-09-13\:03\:28/
[root@QS003 crash]#
[root@QS003 crash]#
[root@QS003 crash]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vg_qs003-lv_root
 14225776 6461148 7035336 48% /
tmpfs 4031236 0 4031236 0% /dev/shm
/dev/sda1 487652 81813 380239 18% /boot

結果、94% -> 48% まで使用率を減らせることができました。

ちなみにPanic理由の一番単純な調査方法は以下のとおり

/var/crashフォルダに移動して、

[root@QS003 crash]# cd 127.0.0.1-2016-01-09-12\:41\:04/
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls
vmcore vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]# ls -al
合計 2054788
drwxr-xr-x 2 root root 4096 1月 9 12:42 2016 .
drwxr-xr-x. 6 root root 4096 1月 9 13:24 2016 ..
-rw------- 1 root root 2103911343 1月 9 12:42 2016 vmcore
-rw-r--r-- 1 root root 174202 1月 9 12:41 2016 vmcore-dmesg.txt
[root@QS003 127.0.0.1-2016-01-09-12:41:04]#

原因の概要をしらべるために、vmcore-dmesg.txtをviewで開いて、
/call Trace
で検索してみると・・・・

<6>[ 3040] 89 3040 20237 1 1 0 0 pickup
<3>Out of memory: Kill process 1850 (rsyslogd) score 1 or sacrifice child
<3>Killed process 1850, UID 0, (rsyslogd) total-vm:249092kB, anon-rss:0kB, file-rss:4kB
<4>postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
<6>postgres cpuset=/ mems_allowed=0
<4>Pid: 29033, comm: postgres Not tainted 2.6.32-573.12.1.el6.x86_64 #1
<4>Call Trace:
<4> [<ffffffff810d6d71>] ? cpuset_print_task_mems_allowed+0x91/0xb0
<4> [<ffffffff8112a570>] ? dump_header+0x90/0x1b0
<4> [<ffffffff81232ffc>] ? security_real_capable_noaudit+0x3c/0x70
<4> [<ffffffff8112a9f2>] ? oom_kill_process+0x82/0x2a0
<4> [<ffffffff8112a931>] ? select_bad_process+0xe1/0x120
<4> [<ffffffff8112ae30>] ? out_of_memory+0x220/0x3c0
<4> [<ffffffff8113780c>] ? __alloc_pages_nodemask+0x93c/0x950
<4> [<ffffffff81166b38>] ? swap_entry_free+0x128/0x1c0
<4> [<ffffffff8117035a>] ? alloc_pages_current+0xaa/0x110
<4> [<ffffffff81127967>] ? __page_cache_alloc+0x87/0x90
<4> [<ffffffff8112734e>] ? find_get_page+0x1e/0xa0
<4> [<ffffffff81128907>] ? filemap_fault+0x1a7/0x500
<4> [<ffffffff8105a4b7>] ? wakeup_preempt_entity+0x47/0x50
<4> [<ffffffff81151ee4>] ? __do_fault+0x54/0x530
<4> [<ffffffff81153179>] ? handle_mm_fault+0x299/0x3d0
<4> [<ffffffff811524b7>] ? handle_pte_fault+0xf7/0xb20
<4> [<ffffffff8108ec0d>] ? __sigqueue_free+0x3d/0x50
<4> [<ffffffff81092332>] ? __dequeue_signal+0x102/0x200
<4> [<ffffffff81153179>] ? handle_mm_fault+0x299/0x3d0
<4> [<ffffffff8104f156>] ? __do_page_fault+0x146/0x500
<4> [<ffffffff8129c5f6>] ? copy_user_generic_unrolled+0x86/0xb0
<4> [<ffffffff811a94b8>] ? poll_select_copy_remaining+0xf8/0x150
<4> [<ffffffff810e884e>] ? __audit_syscall_exit+0x25e/0x290
<4> [<ffffffff8153ef3e>] ? do_page_fault+0x3e/0xa0
<4> [<ffffffff8153c2e5>] ? page_fault+0x25/0x30
<6>Mem-Info:

原因はメモリ不足だったので、メモリを増やして解決したです。

Views: 14