てけらぼ

■[ubuntu][debian]pop-before-smtpの動作がおかしい、というか(2)

Debian(sarge)で作った（こちらは趣味では無い、業務で使われるイントラネットサーバ）のpop-before-smtpはちゃんと動いている....とおもったら、こちらも止まっていた。

Mar 31 07:36:57 home syslog-ng[1801]: STATS: dropped 59
Mar 31 07:37:18 home syslog-ng[1801]: SIGHUP received, restarting syslog-ng

3/31の午前7時37分ごろ以降停止。調べたらあちこち。他のDebianでもUbuntu Serverでも。

syslog-ngがSIGHUPを受けたあと、そのまま落ちている。

なんだこれ....orz

Permalink | コメント(0) | トラックバック(0) | 12:40

■[ubuntu][debian]syslog-ng SIGHUP problemなど

いくつかネット上を眺めていたが、syslog-ngに関しては、設定をリロードするのはSIGHUPでいいようなのだが、ログのローテートに際してはSIGHUPではなく再起動を勧める記載が多い。たとえばこちら、Web屋のネタ帳：syslogとswatchからsyslog-ng乗り換えについて雑多メモ。

あと、SIGHUPがsyslog-ngをころしてしまうと言う件は、かなり以前にひとくされ合った模様。現在は直っているはずなんだが。

さて、/etc/logrotate.d/syslog-ngを眺めてみる。

/var/log/auth.log {
   rotate 4
   missingok
   notifempty
   weekly
   compress
}
|
/var/log/syslog {
   rotate 7
   daily
   compress
   postrotate
      /etc/init.d/syslog-ng reload >/dev/null
   endscript
}

最後に、reloadかけている。/etc/init.d/syslog-ng を覗くと、

syslogng_reload() {
    start-stop-daemon --stop --signal 1 --quiet --exec "$SYSLOGNG" --pidfile "$PIDFILE" || return 1
    return 0
}

ここで、start-stop-daemon の --signal 1 というのはSIGHUPの事なので、pidfileで指定されたプロセスがあれば、それにSIGHUPを送るという指示になる。が、ここでおかしくなっている可能性がある。ということで、上記のpostrotateの中を次のように修正してみることにする。

   postrotate
      /etc/init.d/syslog-ng restart >/dev/null

Permalink | コメント(0) | トラックバック(0) | 13:33

■[python]ppkf.py作成経過 070402

utf16とutf32の識別を追加。

Source String = 残るSJIS EUC UTF-8の判別

shift_jis -> (reliablity:1.00) shift_jis

iso2022_jp -> (reliablity:1.00) iso2022_jp

utf_8 -> (reliablity:1.00) utf_8

euc_jp -> (reliablity:0.47) euc_jp

utf_16 -> (reliablity:1.00) utf_16_le

Source String = 椎名林檎

shift_jis -> (reliablity:1.00) shift_jis

iso2022_jp -> (reliablity:1.00) iso2022_jp

utf_8 -> (reliablity:1.00) utf_8

euc_jp -> (reliablity:0.38) euc_jp

utf_16 -> (reliablity:1.00) utf_16_le

Source String = ダイナマイト

shift_jis -> (reliablity:1.00) shift_jis

iso2022_jp -> (reliablity:1.00) iso2022_jp

utf_8 -> (reliablity:1.00) utf_8

euc_jp -> (reliablity:1.00) euc_jp

utf_16 -> (reliablity:1.00) utf_16_le

Source String = ﾊﾝｶｸｶﾅｷﾀｰ

shift_jis -> (reliablity:0.40) euc_jp

utf_8 -> (reliablity:1.00) utf_8

euc_jp -> (reliablity:1.00) euc_jp

utf_16 -> (reliablity:1.00) utf_16_le

Source String = ﾊﾝｶｸｶﾅ日本語alphabet美乳

shift_jis -> (reliablity:1.00) shift_jis

utf_8 -> (reliablity:1.00) utf_8

euc_jp -> (reliablity:1.00) euc_jp

utf_16 -> (reliablity:1.00) utf_16_le

Source String = Hotel Carifornia

shift_jis -> (reliablity:1.00) ascii

iso2022_jp -> (reliablity:1.00) ascii

utf_8 -> (reliablity:1.00) ascii

euc_jp -> (reliablity:1.00) ascii

utf_16 -> (reliablity:1.00) utf_16_le

Source String = #1$%

shift_jis -> (reliablity:1.00) ascii

iso2022_jp -> (reliablity:1.00) ascii

utf_8 -> (reliablity:1.00) ascii

euc_jp -> (reliablity:1.00) ascii

utf_16 -> (reliablity:1.00) utf_16_le

pythonでutf_16を指定すると、utf_16_leでエンコードされる。というか、これは環境依存か。

utf16はBE/LEを想定してチェックする。utf32は識別は作りこんでみたが、pythonの標準codecにまだ対応されていないのでテストしていない。

utf16は動いているように思う。

こちらのC#で書かれた実装がとても参考になる。

さて、その他のcodec対応をどうしようかな。とりあえずkoi8_rとかbig5の識別あたりからやってみるか。

しかし、日本語以外の言語環境の対応となるとまた難しい模様。というのも、

>>> print unicode(u"残るSJIS EUC UTF-8の判別".encode("sjis"),"latin-1")
céSJIS EUC UTF-8Ì»Ê
>>> print unicode(u"Анна Каренина".encode("koi8_r"),"latin-1")
áÎÎÁ ëÁÒÅÎÉÎÁ

なんてのがエラーなしに走る訳です。

Permalink | コメント(0) | トラックバック(0) | 17:05