processが勝手にKillされる
Masahiro EGUCHI
こんにちは、
FreeBSD2.2.8を使用していますが、最近processが勝手にKillされることがありま
す。メモリは64MBですが、topコマンドで見る限り、空きスワップ、空きメモリがあ
るように見えます。
何か、原因になるようなことが予想されましたら教えていただけませんでしょうか？
よろしくお願いします。
NAKAMURA Kazushi
e...@tv-asahi.co.jp writes:
>FreeBSD2.2.8を使用していますが、最近processが勝手にKillされることがありま
killされた、とはどうやって確認しました？
>何か、原因になるようなことが予想されましたら教えていただけませんでしょうか？
>よろしくお願いします。
/var/log/messagesに何かログが吐かれてませんか？
--
中村和志＠神戸 <mailto:k...@kobe1995.net>
NAKAMURA Kazushi@KOBE <http://kobe1995.net/>
Masahiro EGUCHI
こんばんは、
> >FreeBSD2.2.8を使用していますが、最近processが勝手にKillされることがありま
> killされた、とはどうやって確認しました？
muleを立ち上げて、しばらくしたところkilledと出て終了してしまったり、また、ま
だ仕事が終わっていないのにpsしたときにprocessがなくなっていたりしました。
> >何か、原因になるようなことが予想されましたら教えていただけませんでしょう
か？
> >よろしくお願いします。
> /var/log/messagesに何かログが吐かれてませんか？
関係ないかもしれませんが、
Jul 3 22:08:29 hoge inetd[149]: /usr/libexec/comsat[13614]: exit status 0x9
が出ていました。
何か、参考になりますでしょうか？
また、よろしくお願いします。
NIDE Naoyuki
e...@tv-asahi.co.jp writes:
> muleを立ち上げて、しばらくしたところkilledと出て終了してしまったり、また、ま
> だ仕事が終わっていないのにpsしたときにprocessがなくなっていたりしました。
その手の謎な現象が起こる場合、可能性の1つとしてメモリの異常ということ
があるかも知れません。
私のLinux boxがtar.gzの展開時にCRC Errorを出すようになった時も、これで
した。中を開けてメモリをボードに差し直したら直ったのですが…
Masahiro EGUCHI
こんばんは、ありがとうございます。
以前、Webでこのことを調べたときに、プロセス番号の何番か以下はkillされないよ
うになっていると書いてあったページがあったような気がします。それには、ソース
の位置も書いてあり、確認したことがあります。
FreeBSDは、ある条件が調ったときprocessをkillするようなしくみがあるのでしょう
か？
Yoshisato Yanagisawa
柳澤@is.titech.ac.jp 学部3年と申します。
<9i1kor$e3g$1...@bgsv5906.tk.mesh.ad.jp>の記事において
e...@tv-asahi.co.jpさんは書きました。
>> 以前、Webでこのことを調べたときに、プロセス番号の何番か以下はkillされないよ
>> うになっていると書いてあったページがあったような気がします。それには、ソース
>> の位置も書いてあり、確認したことがあります。
たしかに、ここら辺がSIGKILLを受け取ったら恐ろしいものがあるかも(^^;
0 ?? DLs 0:00.02 (swapper)
1 ?? ILs 0:00.03 /sbin/init --
2 ?? DL 0:02.05 (pagedaemon)
3 ?? DL 0:00.54 (vmdaemon)
4 ?? DL 0:00.13 (bufdaemon)
5 ?? DL 0:01.80 (syncer)
>> FreeBSDは、ある条件が調ったときprocessをkillするようなしくみがあるのでしょう
>> か？
killされるようなsignal(e.g. SIGKILL)を受け取るとか。
...という問題ではないのでしょうか?
----------------------------------------------
Yoshisato YANAGISAWA<yana...@is.titech.ac.jp>
Tokyo Insitute of Technology
Information Science
=Hacker is not Cracker=
----------------------------------------------
Mori Kouji
> FreeBSDは、ある条件が調ったときprocessをkillするようなしくみがあるのでしょう
> か？
確か FreeBSD 3.x のときに調べたのですが、
overcommit した仮想メモリが本当に足りなくて困ったときに kill します。
今でも overcommit してるかどうかは知りません。
--
森 浩二 (MORI Kouji)
(株)淺沼組 技術研究所
E-mail: mo...@tri.asanuma.co.jp
Masahiro EGUCHI
こんばんは、ありがとうございます。
> > FreeBSDは、ある条件が調ったときprocessをkillするようなしくみがあるので
しょう
> > か？
>
> 確か FreeBSD 3.x のときに調べたのですが、
> overcommit した仮想メモリが本当に足りなくて困ったときに kill します。
> 今でも overcommit してるかどうかは知りません。
いま、/usr/src/sys/vmのディレクトリで
$ egrep kill *.c
としたところ、vm_pageout.c
にそのような仕組みが組み込まれているみたいです。
それによると、48番以下、システムプロセス？はkillされないように読めますが、や
はりメモリが足りないと言うことなんでしょうか？
topでは、まだ残っている表示されているし、さらにkillされるものには
telnetd?(telnetが切断される)が選ばれることがあります。telnetdはそんなに大き
いものではないように思います。
やはり、他を疑った方がよいのでしょうかねぇ？
引き続きお願いします。
Atsuo Kobayashi
Masahiro EGUCHI wrote:
>
> やはり、他を疑った方がよいのでしょうかねぇ？
> 引き続きお願いします。
>
ハードウェアの問題だと，メモリ周りの不具合でも起こり得ますが。
"最近"ということなので，プロセッサ，チップセット周りの温度が
高くなって動作が不安定になっていることも考えられます。
(あちこち真夏日続きですし)
メモリを挿し直しして，やけどに注意しながらあちこち
発熱具合を触ってみながら様子を見てはいかがでしょう。
>
> ---
> e...@tv-asahi.co.jp
--
Atsuo Kobayashi
Yoshihiko SARUMARU
fj.os.bsd.freebsd の <9hv79o$ieg$1...@bgsv5906.tk.mesh.ad.jp> の記事において
2001-07-04(水) 22:56頃、e...@tv-asahi.co.jpさんは書きました。
> > /var/log/messagesに何かログが吐かれてませんか？
>
> 関係ないかもしれませんが、
> Jul 3 22:08:29 hoge inetd[149]: /usr/libexec/comsat[13614]: exit status 0x9
> が出ていました。
> 何か、参考になりますでしょうか？
これはつまり、comsat が シグナル 9番 (SIGKILL) を受けて終了し
たということです。
--
猿丸芳彦 (Yoshihiko SARUMARU)
mail: mis...@imasy.or.jp web: http://www.imasy.or.jp/~mistral/
Mori Kouji
"Masahiro EGUCHI" <e...@snow.tv-asahi.co.jp> writes:
> topでは、まだ残っている表示されているし、さらにkillされるものには
> telnetd?(telnetが切断される)が選ばれることがあります。telnetdはそんなに大き
> いものではないように思います。
仮想メモリが足りなくなって kill されるプロセスは、ちょうど足りなくなった
タイミングで実際には確保されていないメモリを使おうとしたプロセスなので
必ずしもメモリをたくさん消費しているプロセスが kill されるとは限りません。
もっとも、本当にメモリが足りないなら、その前に新たなプロセスの作成に
失敗するとかの前兆が現れてくると思います。妙なプログラムを動かして
ない限り。:-)
Narita Takaoki
<80ofqvo...@kurishna.tri.asanuma.co.jp>の記事において
mo...@tri.asanuma.co.jpさんは書きました。
> # たぶん原因は別なんでしょうが参考までに。
別の原因に一票。
> もっとも、本当にメモリが足りないなら、その前に新たなプロセスの作成に
> 失敗するとかの前兆が現れてくると思います。妙なプログラムを動かして
> ない限り。:-)
vmstat や systat を使って観察するのが第一歩かもしれませんね。
--
成田 隆興 ＠ エー・アイ・ソフト株式会社 NB 推進部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ』
Masahiro EGUCHI
皆さんありがとうございます。
> > > /var/log/messagesに何かログが吐かれてませんか？
> >
> > 関係ないかもしれませんが、
> > Jul 3 22:08:29 hoge inetd[149]: /usr/libexec/comsat[13614]: exit status
0x9
> > が出ていました。
> > 何か、参考になりますでしょうか？
>
> これはつまり、comsat が シグナル 9番 (SIGKILL) を受けて終了し
> たということです。
最近、さらにログを見てみたら
Jul 10 19:29:30 hoge getty[20355]: getty exiting due to excessive running
time
Jul 10 20:15:28 hoge getty[20499]: getty exiting due to excessive running
time
Jul 10 21:01:36 hoge getty[20700]: getty exiting due to excessive running
time
Jul 10 21:47:42 hoge getty[20843]: getty exiting due to excessive running
time
というログが出始めています。ほぼ、４５分おきに起きているようです。
どうも、今度はgettyにkillシグナルが送られているようです。
一度、リブートしてみると何か変わるかもしれないと思っていますが、ネットワーク
カード３枚刺さっているゲートウェイなのでなかなかリブートしにくいです。今度、
夜中にリブートしてみようかな。
さらに、vmstat, systatで見てみます。
どうも、gettyの動作が変なのか？いくつかあるgettyのプロセスと違ってリソースを
喰っているようです。
ちょっと、様子を見てみます。
Yoshihiko SARUMARU
fj.os.bsd.freebsd の <9if0lg$4sr$1...@bgsv5905.tk.mesh.ad.jp> の記事において
2001-07-10(火) 22:41頃、e...@snow.tv-asahi.co.jpさんは書きました。
> Jul 10 19:29:30 hoge getty[20355]: getty exiting due to excessive running
> time
> というログが出始めています。ほぼ、４５分おきに起きているようです。
> どうも、今度はgettyにkillシグナルが送られているようです。
このメッセージは timeoverrun()＠libexec/getty/main.c が出して
いますが、timeoverrun() は
#define GETTY_TIMEOUT 60 /* seconds */
(void)signal(SIGXCPU, timeoverrun);
limit.rlim_max = RLIM_INFINITY;
limit.rlim_cur = GETTY_TIMEOUT;
(void)setrlimit(RLIMIT_CPU, &limit);
という条件で呼出されます。つまり CPU 時間が 60秒を越えたら XCPU
シグナルがプロセスに飛び、プロセスはシグナルを補足して
timeovertun() を実行してメッセージを出力し、(exit()を呼出してい
るので)終了します。
KILL シグナルが飛んでるわけではありません。
> どうも、gettyの動作が変なのか？いくつかあるgettyのプロセスと違ってリソースを
> 喰っているようです。
うーん、その getty がどの tty を掴んでいるかによりますが、
/etc/ttys の設定が変なんですかねぇ
Masahiro EGUCHI
こんばんは、
> このメッセージは timeoverrun()＠libexec/getty/main.c が出して
> いますが、timeoverrun() は
>
> #define GETTY_TIMEOUT 60 /* seconds */
> (void)signal(SIGXCPU, timeoverrun);
> limit.rlim_max = RLIM_INFINITY;
> limit.rlim_cur = GETTY_TIMEOUT;
> (void)setrlimit(RLIMIT_CPU, &limit);
>
> という条件で呼出されます。つまり CPU 時間が 60秒を越えたら XCPU
> シグナルがプロセスに飛び、プロセスはシグナルを補足して
> timeovertun() を実行してメッセージを出力し、(exit()を呼出してい
> るので)終了します。
>
> KILL シグナルが飛んでるわけではありません。
>
> > どうも、gettyの動作が変なのか？いくつかあるgettyのプロセスと違ってリソー
スを
> > 喰っているようです。
>
> うーん、その getty がどの tty を掴んでいるかによりますが、
> /etc/ttys の設定が変なんですかねぇ
gettyが以上にCPUパワーを食っている理由ですが、分かりました。
キーボードが壁に当たってリターンキーが押されていました。
それを直したところ、メッセージはなくなりました。
しかし、たまにkillされる現象は直りませんでした。