libhoge0.rpm であれば
武山です 忙しさで反応が遅めですみません IRC でスタックトレースと言いましたが、y2log だけでも、大丈夫かもしれません。 # スタックトレースがあれば、あるで有用なんですが 一般的な YaST のバグを報告する方法を書いておきます 1. Bugzilla で既に報告済みではないかをチェック - http://bugzilla.novell.com - 苦労が水の泡にならないように - Bugzilla の検索機能は弱いので、Google 検索も併用すると良いと思います site:opensuse.org で Bugzilla の内容は ML にも転送されているので、ML のログもヒットします。 2. Bugzilla にレポートするときは /var/log/Yast/y2log を添付する - 長いので、必要そうな部分だけ切り出しても OK です - 何か関連するログが残っていないかチェックして、もしあればレポートの本文に書きましょう - LANG=c で YaST を実行しておかないと、相手が日本語が読めずに困ることがあります。 # ここ最近の SuSEconfig がらみだと、command not found と普通に出てたり… また、アプリケーションがクラッシュしたときはスタックトレースがあると、 原因の追及に役立ちます。 # KDE とかも、独自で crash ハンドラを持っています core ファイルをとっても良いのですが、gdb でも直接出せます。 $ gdb プログラム名 (gdb) run 引数 で実行して、クラッシュしたら、gdb を起動した端末に戻って (gdb) bt とすると、バックトレースが出ます。 単純にスタックトレースを出すと、関数名など一部の情報しか出力されません。 デバッグに必要な情報は -debuginfo が後ろに付いたパッケージに入っていて、 有用なスタックトレースを出すには、落ちたライブラリ等の debuginfo が必要です。 OSS リポジトリのパッケージの debuginfo は repo-debug リポジトリに入っています。 $ sudo zypper mr -e repo-debug でインストールする前に有効にしてあげて下さい。 # repo-debug-update は Update リポジトリのパッケージ用 例えば、libhoge.so.0.0.0 で落ちたような情報があれば（落ちる前後の情報も必要ですが） $ rpm -qf /usr/lib64/libhoge.so.0.0.0 でパッケージを特定して、出力が libhoge0-debuginfo.rpm をインストールしてから、スタックトレースを採取してみて下さい。 -- Fuminobu TAKEYAMA (2013/02/25 12:14), 1xx wrote:
2013年2月25日 8:02 Yasuhiko Kamata <belphegor@belbel.or.jp>:
上記をダイレクトに回答すると、 "/etc/security/limits.conf" 内に "* soft core unlimited" という行を追記してシステムを再起動すると、 coreファイルを吐く (= "ulimit -c" で "unlimited" になる) ように なります (openSUSEだけでなく、他のLinuxでも使える方法です) 。
ただし、このままだとプロセス実行時のカレントディレクトリに出力されて しまうので、 "echo /var/crash/core.%e.%u.%t > /proc/sys/kernel/core_pattern" のように出力先のテンプレートを設定しておくと、もっと便利になるでしょう (ただしこちらはシステムを再起動すると元に戻ってしまいます)。
回答ありがとうございます。 合わせ技で/etc/sysctl.d/にファイルを作ることで ブート時に自動的に/var/crash/へcoreを吐くよう設定を変更することにしました。
やったことをテスト手順にしました。
とりあえずこの後Software Managerが落ちる問題に関して まずはhttps://bugzilla.novell.com/ に同様の問題が 既に報告されていないか調べてみたいと思います。
-------- core fileを出力するディレクトリを変更するテスト -------- * ulimit -c unlimited を実行する。 ulimit -a でcore file sizeがunlimitedになったか? 2013-02-25 OK * cat を起動し<Ctrl>+\と入力したときcoreが生成されるか? 2013-02-25 OK
* sudo /sbin/sysctl -w kernel.core_pattern='/var/crash/core.%e.%u.%t' で、/proc/sys/kernel/core_patternが/var/crash/core.%e.%u.%tに書き換わるか? 2013-02-25 OK
* sudo chmod o+w /var/crash で /var/crashのパーミッションが drwxr-xrwx に変わるか? 2013-02-25 OK
* cat を起動し<Ctrl>+\と入力したとき/var/crash/ にcoreが吐かれるか? 2013-02-25 OK
* 以下の手順でリブート後に/var/crash/にcoreが生成されるようになるか? 1) /etc/security/limits.confに「* soft core unlimited」と書く。 2) /etc/sysctl.dにcore_pattern.confというファイルを以下の内容で作る。 kernel.core_pattern =/var/crash/core.%e.%u.%t
3) 古いcoreを消す。 sudo rm /var/crash/core.* 4) マシンリブート 5) cat を起動し<Ctrl>+\と入力
2013-02-25 OK
* 以上の操作で/var/crashにテスト用のcore以外にcoreが生成されていないか? 2013-02-25 NG "core.dconf worker.1000.1361758042"というcoreファイルが生成されている。
-------- 問題 --------
* 2013-02-25 "core.dconf worker.1000.1361758042"という coreファイルが生成されている。 fileコマンドによれば from '/usr/bin/gnome-keyring-daemon --start --components=secrets' とのこと。
もう一度rebootしたが、再現しない。
--------
-- 1xx <ItSANgo@gmail.com> <https://twitter.com/ItSANgo> <http://d.hatena.ne.jp/Itisango/>
-- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ja+owner@opensuse.org