2015/07/27(月)春M(SpringM)でSusie Plug-inが使用できない

2015/07/27 15:00 PC(全般)
春M(SpringM)で、Susieプラグインが使えなくなった問題。

以下前提。

SpringMの組み込み画像ビューア(pview)は、自動的にSusieプラグインを読み込んで使用してくれる。

プラグインのディレクトリはオプション等で指定出来ない。
SpringM上でハードコーディングされたSusieのレジストリを見にいっているようだ。

で、本題。

現在、Susieのサイトで更新されている最新β版Susie

Susie 0.50 beta3(Jan 15,2013)

は内部的にはSusie2扱いで、レジストリの場所・構造・生成タイミングが旧Susie(~0.47)と違う。

[~0.47]
HKEY_CURRENT_USER\Software\takechin\Susie
※起動初回に生成

[0.50~]
HKEY_CURRENT_USER\Software\takechin\Susie2
※インストール時に生成

SpringMは旧Susie(~0.47)のレジストリしか見に行かないため、SpringMでSusieプラグインを使用する場合は1度旧Susieを1回起動してやる必要がある。それから新Susie(0.50~)に更新するか、新Susieとは別に旧Susieを入れっぱなしにしておくかは任意。

幸にして、まだSusie32 ver0.47bが公開されているのでこれを利用すること。

一度旧Susieを起動してしまえば、レジストリには残りっぱなしなのでディレクトリ移動をしない限り問題は起きない。
Windows再インストールの時など、環境作り直し時にはまる可能性があるので注意。

2015/07/09(木)logbackでサイズローテートしない

logbackでログがファイルサイズでローテートしない問題。

Java1.7 + logback-1.1.3

条件は実行時間が短いバッチのようなプログラム。

もともと↓の記述にしていたのだが、ローテートしてくれなかった。
[logback.xml]
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>./logs/hoge.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
      <fileNamePattern>./logs/hoge.%i.log.zip</fileNamePattern>
      <minIndex>1</minIndex>
      <maxIndex>3</maxIndex>
    </rollingPolicy>
    
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
      <maxFileSize>5MB</maxFileSize>
    </triggeringPolicy>
    <encoder>
      <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger\(%F[%L]\) - %msg %n</pattern>
      <charset>Shift_JIS</charset>
    </encoder>
  </appender>
調べてみると、logbackのSizeBasedTriggeringPolicyはI/O負荷対策のためファイルサイズを毎度チェックしにいかない。デフォルトでは16回に1回であり、16回ログ出力して初めてサイズチェックに行く。ログ出力の頻度が多いと間隔を開け、頻度が少ないと間隔を狭める。

今回のプログラムは16回ログを出すフローがほとんどない。実行時間も短いため、間隔調整の恩恵も受ける暇がない。親切ではあるのだが、プロセス内の初回はチェックするなど対策が必要に思う。

このプログラムごく短時間で起動->終了し、ログの出力回数・起動頻度とも高くない。毎回チェックとしたい。

[logback.xml]
    <triggeringPolicy class="foo.bar.CustomSizeBasedTriggeringPolicy">
[カスタムクラス]
package foo.bar;

import java.io.File;

import ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy;
import ch.qos.logback.core.util.FileSize;

public class CustomSizeBasedTriggeringPolicy<E> extends SizeBasedTriggeringPolicy<E> {

	String maxFileSizeAsString = Long.toString(DEFAULT_MAX_FILE_SIZE);
	FileSize maxFileSize;

	public CustomSizeBasedTriggeringPolicy() {
	}

	public CustomSizeBasedTriggeringPolicy(final String maxFileSize) {
		setMaxFileSize(maxFileSize);
	}

	@Override
	public boolean isTriggeringEvent(final File activeFile, final E event) {
		//オリジナルのisTriggeringEventでは発火しないことがあるため、ログ書き出しごとにチェックする
		return (activeFile.length() >= maxFileSize.getSize());
	}

	@Override
	public String getMaxFileSize() {
		return maxFileSizeAsString;
	}

	@Override
	public void setMaxFileSize(String maxFileSize) {
		this.maxFileSizeAsString = maxFileSize;
		this.maxFileSize = FileSize.valueOf(maxFileSize);
	}
}
isTriggeringEventだけいじったクラスを作成してやって、logback.xmlでそちらを見るようにしてやる。

とりあえずこれで動くことは動く。

2015/07/09(木)LogbackでプロセスIDを出力

logbackでプロセスIDを出す方法。

Java1.7 + logback-1.1.3

あまりいい方法が見つからなかったが、とりあえず出りゃいいやまではできた。

起動コマンドなりスクリプトなりがいじれるのなら、SystemProperty経由で設定・取得する方法が使える。

[起動コマンド]
exec java -Dpid=$$ -jar /foo/bar.jar
[logback.xml]
<pattern>%d{yyyy/MM/dd HH:mm:ss} [${pid}] %level %msg%n</pattern>
-Dpid=$$で、プロパティ:pidにプロセスIDをセット、patternに${pid}と記述してやるとlobackの機能で出力できる。
もちろんUnix環境限定。

なお、シェル側のプロセスIDがほしい場合は、execを外し直接javaコマンドをたたく。
java -Dpid=$$ -jar /foo/bar.jar
Webアプリケーションで動いている場合は、何がしかプロセスIDに相当するものがSystemPropertyにいると思うので${}でそれを拾えばいい(はず)。

本当なら、ManagementFactory.getRuntimeMXBean()で取得するのが正解のようだが、その場合PatternLayoutをカスタムしてコンバータをいじって… とやらなければいけない気がする。規模によってはさすがに大仰か。

[参考]
Igor Minar's Blog: How a Java Application Can Discover its Process ID (PID)

2015/06/28(日)jessieで起動しない

2015/06/28 19:14 PC(Linux)
jessieにアップグレードした際に起動周りで色々問題が起きたのでメモ。

一部解決、かなり未解決。

段階的に修正していくしかなさそう。

grub起動時、コンソールにFile not foundが3回出力される

→解決
#grub-install /dev/sda
#update-grub 
で改善した(他に色々作業していたので、別の処置で改善した可能性も)

systemdで起動しない

→解決

jessieではgrubにsystemdとsysvinitが両方登録される。
wheezy時代には起動していたカーネルのsystemd版は起動しない。sysvinit版だと起動する。

jessieからinit周りがsystemdに切り替わるため、init.dでカスタマイズしたサービスが動かないとは聞いていたが起動しないとは想定外。

原因はfstabにあった。
どうやら、systemdではfstabの記述を厳密に解釈するらしい。usb外付けで繋いでいたドライブ(今は繋いでいない)のoptionsが
defaults
になっていた。
user,noauto
に修正して改善。

3.16.0-4-686-paeで起動しない

未解決解決

wheezyで入っていた3.2.0-4-686-paeは起動するのだが、3.16.0-4-686-paeで起動しない。
gave up waiting for root device 

alert /dev/disk/by-uuid/~~ does not exist
が出る。
busyboxのシェルであれこれ試してみると、
・/dev/disk/by-uuid/が無い
・そもそも/dev/sda1が無い
・cat /proc/modules は空

全くドライバが読めていないっぽい。

起動するカーネル(3.2.0-4-686-pae)のinitrdは12MB
起動しないカーネル(3.16.0-4-686-pae)のinitrdは4MB

lsinitramfsでのぞくと、3.16の方は/lib/modules/3.16.0-4-686-pae/kernel配下がまるごと無い

update-initramfs -uで症状変わらず
起動オプションrootdelay=90等で症状変わらず
depmod -a 3.16.0-4-686-paeでも症状変わらず
ここで今回の調査は断念。

initramfs-toolsのバグだか考慮漏れだかに当たっているような気がしている。

自分でカーネル作り直せば確実なのは分かっているが、そもそも管理コストを下げるためにカーネルもdebian標準にしたいというのが方針なので、しばらく標準でのinitrd正常化方策を探すことにする。といってもかなり色々試してはいるので、調べ方変えるか時間に解決してもらうかじゃないとちょっと無理そう。
[2015/07/28 追記]
時間が取れたので、ひたすら人力で調べてみた。

まずupdate-initramfs内で呼び出しているmkinitramfsを直に叩いてみるが、やはりmodulesが抜ける。
#mkinitramfs -o /boot/initrd.img-3.16.0-4-686-pae.new 3.16.0-4-686-pae
mkinitramfsをたどっていくと、/usr/share/initramfs-tools/hook-functions内のmanual_add_modulesでmodprobeの結果を元にループを回している箇所がある。ここが3.2では動いているのに3.16では動いていない。はて。

スクリプト内で使用しているコマンドをログインシェルで叩いてみるが、いずれのバージョンも問題がない。
#modprobe --all --set-version=3.2.0-4-686-pae --ignore-install --quiet --show-depends eql
insmod /lib/modules/3.2.0-4-686-pae/kernel/drivers/net/eql.ko

#modprobe --all --set-version=3.16.0-4-686-pae --ignore-install --quiet --show-depends eql
insmod /lib/modules/3.16.0-4-686-pae/kernel/drivers/net/eql.ko
とすると、mkinitfamfs内の環境変数が原因か。

で、調べたところ、
#export PATH=/usr/bin:/sbin:/bin
で動きが変わることが分かった。げーっ。実行ファイルゴースト問題だー。

結局のところ、modprobeもdepmodも/sbinと/usr/local/sbinの両方にありログインシェルでは/usr/local/sbinを見ていた。
/usr/local/sbinの方のタイムスタンプは2004年、うぉう。

あとは推測だが、aptでカーネルイメージを入れた際に/usr/local/sbinの古いdepmodを呼んでしまうようだ。古いdepmodは、/lib/modules/<< version >>/modules.dep.binを生成しない。同じく/usr/local/sbinの古いmodprobeはこれで動くのだが、新しい/sbinのmodprobeは
#/sbin/modprobe --all --set-version=3.16.0-4-686-pae --ignore-install --show-depends eql

modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/3.16.0-4-686-pae/modules.dep.bin'
となってしまう(quiet無しだとエラーが出る。ありだと何も出ない)。

3.2は何かのタイミングで新しいmodprobeを発火するタイミングがあった模様で、modules.dep.binがいた。そんな状態で良く動いてたな。

ということで、depmodもmodprobeも新しい方を使ってやればよい。
#/sbin/depmod -v 3.16.0-4-686-pae
これで
/lib/modules/3.16.0-4-686-pae/modules.dep.bin
ができた。

あとはこれでinitrdを作ってやる。
#update-initramfs -u -k 3.16.0-4-686-pae
丸々と太った健康そうな16MBのinitrdができた。

うーん、やっぱりwoodyのアップグレード&アップグレードじゃ限界あるなあ。

grub上でメニューいじったときにunaligned pointer 0x8が出る

→未解決

grub起動時にオプションをeで変えると、
unaligned pointer 0x8
が出る。

GRUBのバグかなあ。

デフォルト起動カーネル切り替え

ということで、しばらくwheezy時代のsysvinitカーネルを使用する。systemdにするためには洗い出しが必要なので3.16が動くようになってからにしたい。

/etc/default/grub
GRUB_DEFAULT="Debian GNU/Linux, with Linux 3.2.0-4-686-pae (sysvinit)"
最初上記形式で書いたが、update-grubしたらwarningが出たので、
/etc/default/grub
GRUB_DEFAULT="gnulinux-advanced-~~>gnulinux-3.2.0-4-686-pae-init-sysvinit-~~"
に変更して、update-grub。

これでとりあえず再起動しても特に操作せずに起動するようになった。
うーん、サーバつぶした方がいいんだろうか。
こういうドハマリは維持意欲を削ぐ。

このサーバはwoodyからの10年選手なので64bit化も含め再インストール時期ではあるのだが……

2015/04/12(日)https通信が出来なくなる

2015/04/12 15:20 PC(全般)
4/3くらいからWindows7(64bit)のhttps通信が死んでいた問題。
とりあえず、回復したのでメモだけ。

[症状]
・PC1では問題あり、PC2では問題なし
・Chrome, IE, OpenTween, Tween, Windows Update, リモートデスクトップで全https通信がタイムアウトする
・Firefox, Twitamaだと問題なし
・ChromeだとエラーメッセージERR_TIMED_OUT
・OpenTweenは起動後ハング
・リモートデスクトップは 「リモート接続を保護しています」の画面でハング
・セーフモードだと上記いずれもタイムアウトしない(!?)

[確認したこと]
・Windows Firewall問題なし
・アンチウイルスソフトON/OFF症状変わらず
・スパイウェア対策ソフトON/OFF症状変わらず
・最初証明書を疑ったが、証明書ではないっぽい
・ウイルス・マルウェアを疑ったが、とりあえず検出されずそれっぽい挙動も見えず
・パケットキャプチャすると、正規のプロセスがちゃんと通信し始めてるのだが、通信の途中で途絶してTCP/IPタイムアウトでRSTが走っている

[対処]
・デバイスマネージャーから"Realtek PCIe GBE Family Controller"を削除してOS再起動→自動認識させたところ、通信ができるようになった

[参考]
PC Gamer リスト更新中 : Chromeで一部サイトのみSSL接続がタイムアウトするようになってしまった

ちゃんとパケットキャプチャを取っておかなかったのだが、Windows Updateなどによりフレームの分割数・サイズがドライバのバグに当たった、もしくはドライバそのものが何かに感染したのだろうか。

なんとなく
Win7 -> WinXPファイルコピー問題
これと同様の問題の気配。

httpsだけというのははじめてだったのでかなりハマった。

蟹ドライバがevilだったかどうかは確定できなかったが、やっぱり蟹は極力視界から排除した方がいいように思う。
OK キャンセル 確認 その他