On Nov 19 2006 07:13, Oleg Verych wrote:
>On Sun, Nov 19, 2006 at 12:24:14AM +0100, Jan Engelhardt wrote:
>> On Nov 18 2006 21:51, Oleg Verych wrote:
>> >On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
>> >> >Then, who you think prints that "Killed" or "Segmentation fault"
>> >> >m
On Sun, Nov 19, 2006 at 12:24:14AM +0100, Jan Engelhardt wrote:
>
> On Nov 18 2006 21:51, Oleg Verych wrote:
> >On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
> >> >Then, who you think prints that "Killed" or "Segmentation fault"
> >> >messages in *stderr*?
> >> >[Hint: libc's def
On Nov 18 2006 21:51, Oleg Verych wrote:
>On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
>> >Then, who you think prints that "Killed" or "Segmentation fault"
>> >messages in *stderr*?
>> >[Hint: libc's default signal handler (man 2 signal).]
>>
>> Please enlighten us on how you p
On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
>
> On Nov 18 2006 02:38, Oleg Verych wrote:
> >On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
> >> > > > I found that sometimes processes disappear on some heavily used
> >> > > > system
> >> > > > of mine with
>> 4. If this is about detecting the loss of specific processes
>>(network services say), then the problem can be solved in
>>user-space by using a separate monitor process, or by
>>controlling the processes via ptrace.
>
>No not only for specific processes. It helps you detect problem
On Nov 18 2006 02:38, Oleg Verych wrote:
>On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
>> > > > I found that sometimes processes disappear on some heavily used system
>> > > > of mine without any logging. So I've written a patch against 2.6.18.2
>> > > > which emits logging
Nice to meet you, Miquel!
On 2006-11-18, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Oleg Verych <[EMAIL PROTECTED]> wrote:
>>On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
>>> > > > I found that sometimes processes disappear on some heavily used system
> 4. If this is about detecting the loss of specific processes
>(network services say), then the problem can be solved in
>user-space by using a separate monitor process, or by
>controlling the processes via ptrace.
No not only for specific processes. It helps you detect problems with
On Sat, 18 Nov 2006 02:09:46 +0100, Folkert van Heusden wrote:
>I found that sometimes processes disappear on some heavily used system
>of mine without any logging. So I've written a patch against 2.6.18.2
>which emits logging when a process emits a fatal signal.
>
>Signed-off-by: Folkert van Heusd
In article <[EMAIL PROTECTED]>,
Oleg Verych <[EMAIL PROTECTED]> wrote:
>On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
>> > > > I found that sometimes processes disappear on some heavily used system
>> > > > of mine without any logging. So I've written a patch against 2.6.18.
On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
> > > > I found that sometimes processes disappear on some heavily used system
> > > > of mine without any logging. So I've written a patch against 2.6.18.2
> > > > which emits logging when a process emits a fatal signal.
> > > Wh
> > > I found that sometimes processes disappear on some heavily used system
> > > of mine without any logging. So I've written a patch against 2.6.18.2
> > > which emits logging when a process emits a fatal signal.
> > Why not to patch default signal handlers in glibc, to have not only
> > stderr,
Hi,
> > I found that sometimes processes disappear on some heavily used system
> > of mine without any logging. So I've written a patch against 2.6.18.2
> > which emits logging when a process emits a fatal signal.
> Why not to patch default signal handlers in glibc, to have not only
> stderr, but
On 2006-11-18, Folkert van Heusden wrote:
> Hi,
>
> I found that sometimes processes disappear on some heavily used system
> of mine without any logging. So I've written a patch against 2.6.18.2
> which emits logging when a process emits a fatal signal.
Why not to patch default signal handlers in
14 matches
Mail list logo