FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 02-10-2011, 05:58 PM
 
Default CentOS 5.5 Java Process Death

Martin Hewitt wrote:
> Hi all,
>
> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>
> We have a java application, packaged as a jar, running on our servers
> which, periodically, crawls RSS feeds and writes the articles to a
> database.
>
> Randomly, and seemingly without cause, these processes will die, not
> through the application exiting, or due to my killing it, but due to
> something that seems to kill without leaving a trace.
<snip>
The hard (but correct) way would be to put try {} catch in the code, and
work your way down. Trying to debug it using a debugger might be real
problematical, if you can't repeatably provoke it. I *suppose* you could
attach strace to it, and dump the o/p into a file (on a filesystem with a
*lot* of disk space)....

mark

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-10-2011, 06:20 PM
Martin Hewitt
 
Default CentOS 5.5 Java Process Death

Hi Mark,

Thanks, I didn't know about the strace command, so that's useful.
Fortunately, this is on a dedicated server, so there's a fair amount
of free disk.

I've also remembered that one server was previously running CentOS
5.4, so I'm rebuilding the mirror server with 5.4 to see if that made
a difference.

Thanks for the help.

Martin

On 10 February 2011 18:58, <m.roth@5-cent.us> wrote:
> Martin Hewitt wrote:
>> Hi all,
>>
>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>
>> We have a java application, packaged as a jar, running on our servers
>> which, periodically, crawls RSS feeds and writes the articles to a
>> database.
>>
>> Randomly, and seemingly without cause, these processes will die, not
>> through the application exiting, or due to my killing it, but due to
>> something that seems to kill without leaving a trace.
> <snip>
> The hard (but correct) way would be to put try {} catch in the code, and
> work your way down. Trying to debug it using a debugger might be real
> problematical, if you can't repeatably provoke it. I *suppose* you could
> attach strace to it, and dump the o/p into a file (on a filesystem with a
> *lot* of disk space)....
>
> * * * *mark
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-10-2011, 06:37 PM
 
Default CentOS 5.5 Java Process Death

Hey, Martin,

Martin Hewitt wrote:
>
> Thanks, I didn't know about the strace command, so that's useful.
> Fortunately, this is on a dedicated server, so there's a fair amount
> of free disk.
<snip>
If you can do the code changes (and the try/catch is *supposed* to be in
there, according to java style), work your way down, y'know...

main

...
try {
First actual call to do the job
} catch
writeln error;

And if it fails there, then you know; otherwise, go to the next main call,
sorry, "invocation of a method"....

Then again, this time in each of the main function calls under that, and
step down until you find the function it's dying in. That'll give you a
much better handle on what's happening.

> Thanks for the help.
>
Good luck.


> Martin
>
> On 10 February 2011 18:58, <m.roth@5-cent.us> wrote:
>> Martin Hewitt wrote:
>>> Hi all,
>>>
>>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
>>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>>
>>> We have a java application, packaged as a jar, running on our servers
>>> which, periodically, crawls RSS feeds and writes the articles to a
>>> database.
>>>
>>> Randomly, and seemingly without cause, these processes will die, not
>>> through the application exiting, or due to my killing it, but due to
>>> something that seems to kill without leaving a trace.
>> <snip>
>> The hard (but correct) way would be to put try {} catch in the code, and
>> work your way down. Trying to debug it using a debugger might be real
>> problematical, if you can't repeatably provoke it. I *suppose* you could
>> attach strace to it, and dump the o/p into a file (on a filesystem with
>> a
>> *lot* of disk space)....
>>
>> * * * *mark
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-10-2011, 06:37 PM
 
Default CentOS 5.5 Java Process Death

Hey, Martin,

Martin Hewitt wrote:
>
> Thanks, I didn't know about the strace command, so that's useful.
> Fortunately, this is on a dedicated server, so there's a fair amount
> of free disk.
<snip>
If you can do the code changes (and the try/catch is *supposed* to be in
there, according to java style), work your way down, y'know...

main

...
try {
First actual call to do the job
} catch
writeln error;

And if it fails there, then you know; otherwise, go to the next main call,
sorry, "invocation of a method"....

Then again, this time in each of the main function calls under that, and
step down until you find the function it's dying in. That'll give you a
much better handle on what's happening.

> Thanks for the help.
>
Good luck.

mark
> Martin
>
> On 10 February 2011 18:58, <m.roth@5-cent.us> wrote:
>> Martin Hewitt wrote:
>>> Hi all,
>>>
>>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
>>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>>
>>> We have a java application, packaged as a jar, running on our servers
>>> which, periodically, crawls RSS feeds and writes the articles to a
>>> database.
>>>
>>> Randomly, and seemingly without cause, these processes will die, not
>>> through the application exiting, or due to my killing it, but due to
>>> something that seems to kill without leaving a trace.
>> <snip>
>> The hard (but correct) way would be to put try {} catch in the code, and
>> work your way down. Trying to debug it using a debugger might be real
>> problematical, if you can't repeatably provoke it. I *suppose* you could
>> attach strace to it, and dump the o/p into a file (on a filesystem with
>> a
>> *lot* of disk space)....
>>
>> * * * *mark
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-11-2011, 12:42 AM
Martin Hewitt
 
Default CentOS 5.5 Java Process Death

Hi Mark,

I've exhausted the Java avenues for debugging this issue, but, since
my last email, the process I pointed strace at has been killed, but
I'm afraid the rather raw format of the strace file is lost on me.
The last six lines of the ouput file are:

clone(child_stack=0x4202a250,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND| CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARE NT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x4202a9d0, tls=0x4202a940, child_tidptr=0x4202a9d0) =
23241
futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL) = -1 EINTR (Interrupted system call)
--- SIGHUP (Hangup) @ 0 (0) ---
futex(0x2ab0b620a000, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigreturn(0x2ab0b620a000) = -1 EINTR (Interrupted system call)
futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL <unfinished ... exit status 129>

The SIGHUP is new information, and appears to be what's causing the
java app to exit. Surely Java should be aware of the Interrupted
system call?

There are no other signals in the output file, and the only EINTRs are
in the passage above.

Looks like I need to delve back into Java...

Martin

On 10 February 2011 19:37, <m.roth@5-cent.us> wrote:
> Hey, Martin,
>
> Martin Hewitt wrote:
>>
>> Thanks, I didn't know about the strace command, so that's useful.
>> Fortunately, this is on a dedicated server, so there's a fair amount
>> of free disk.
> <snip>
> If you can do the code changes (and the try/catch is *supposed* to be in
> there, according to java style), work your way down, y'know...
>
> main
>
> ...
> try {
> First actual call to do the job
> } catch
> * writeln error;
>
> And if it fails there, then you know; otherwise, go to the next main call,
> sorry, "invocation of a method"....
>
> Then again, this time in each of the main function calls under that, and
> step down until you find the function it's dying in. That'll give you a
> much better handle on what's happening.
>
>> Thanks for the help.
>>
> Good luck.
>
> * * * *mark
>> Martin
>>
>> On 10 February 2011 18:58, *<m.roth@5-cent.us> wrote:
>>> Martin Hewitt wrote:
>>>> Hi all,
>>>>
>>>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>>>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
>>>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>>>
>>>> We have a java application, packaged as a jar, running on our servers
>>>> which, periodically, crawls RSS feeds and writes the articles to a
>>>> database.
>>>>
>>>> Randomly, and seemingly without cause, these processes will die, not
>>>> through the application exiting, or due to my killing it, but due to
>>>> something that seems to kill without leaving a trace.
>>> <snip>
>>> The hard (but correct) way would be to put try {} catch in the code, and
>>> work your way down. Trying to debug it using a debugger might be real
>>> problematical, if you can't repeatably provoke it. I *suppose* you could
>>> attach strace to it, and dump the o/p into a file (on a filesystem with
>>> a
>>> *lot* of disk space)....
>>>
>>> * * * *mark
>>>
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS@centos.org
>>> http://lists.centos.org/mailman/listinfo/centos
>>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-11-2011, 06:05 AM
Keith Roberts
 
Default CentOS 5.5 Java Process Death

On Fri, 11 Feb 2011, Martin Hewitt wrote:


To: CentOS mailing list <centos@centos.org>
From: Martin Hewitt <martin.hewitt@gmail.com>
Subject: Re: [CentOS] CentOS 5.5 Java Process Death

Hi Mark,

I've exhausted the Java avenues for debugging this issue, but, since
my last email, the process I pointed strace at has been killed, but
I'm afraid the rather raw format of the strace file is lost on me.
The last six lines of the ouput file are:


Do you have different versions of JAVA from different
vendors installed? I don't use Iced Tea as it's not always
100% compatible. Try to use just *one* vendor's version of
JAVA as your active JAVA installation. I only use Sun's SDK
as I have noticed problems using other vendors versions.


HTH

Keith Roberts



clone(child_stack=0x4202a250,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND| CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARE NT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x4202a9d0, tls=0x4202a940, child_tidptr=0x4202a9d0) =
23241
futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL) = -1 EINTR (Interrupted system call)
--- SIGHUP (Hangup) @ 0 (0) ---
futex(0x2ab0b620a000, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigreturn(0x2ab0b620a000) = -1 EINTR (Interrupted system call)
futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL <unfinished ... exit status 129>

The SIGHUP is new information, and appears to be what's causing the
java app to exit. Surely Java should be aware of the Interrupted
system call?

There are no other signals in the output file, and the only EINTRs are
in the passage above.

Looks like I need to delve back into Java...

Martin

On 10 February 2011 19:37, <m.roth@5-cent.us> wrote:

Hey, Martin,

Martin Hewitt wrote:


Thanks, I didn't know about the strace command, so that's useful.
Fortunately, this is on a dedicated server, so there's a fair amount
of free disk.

<snip>
If you can do the code changes (and the try/catch is *supposed* to be in
there, according to java style), work your way down, y'know...

main

...
try {
First actual call to do the job
} catch
* writeln error;

And if it fails there, then you know; otherwise, go to the next main call,
sorry, "invocation of a method"....

Then again, this time in each of the main function calls under that, and
step down until you find the function it's dying in. That'll give you a
much better handle on what's happening.


Thanks for the help.


Good luck.

* * * *mark

Martin

On 10 February 2011 18:58, *<m.roth@5-cent.us> wrote:

Martin Hewitt wrote:

Hi all,

I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
Server VM (build 14.0-b16, mixed mode) installed via Yum.

We have a java application, packaged as a jar, running on our servers
which, periodically, crawls RSS feeds and writes the articles to a
database.

Randomly, and seemingly without cause, these processes will die, not
through the application exiting, or due to my killing it, but due to
something that seems to kill without leaving a trace.

<snip>
The hard (but correct) way would be to put try {} catch in the code, and
work your way down. Trying to debug it using a debugger might be real
problematical, if you can't repeatably provoke it. I *suppose* you could
attach strace to it, and dump the o/p into a file (on a filesystem with
a
*lot* of disk space)....

* * * *mark

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos



--
-----------------------------------------------------------------
Websites:
http://www.karsites.net
http://www.php-debuggers.net
http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with
TMDA [http://tmda.net]
-----------------------------------------------------------------_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-11-2011, 07:53 AM
Martin Hewitt
 
Default CentOS 5.5 Java Process Death

Hi Keith,

Interesting idea, I've built the Sun SDK on one server, and left the yum-installed version on the other, and have started the same java application on both servers with strace, so I'll see if there's any difference.

Thanks for all the help,

Martin

On 11 Feb 2011, at 07:05, Keith Roberts wrote:

> On Fri, 11 Feb 2011, Martin Hewitt wrote:
>
>> To: CentOS mailing list <centos@centos.org>
>> From: Martin Hewitt <martin.hewitt@gmail.com>
>> Subject: Re: [CentOS] CentOS 5.5 Java Process Death
>> Hi Mark,
>>
>> I've exhausted the Java avenues for debugging this issue, but, since
>> my last email, the process I pointed strace at has been killed, but
>> I'm afraid the rather raw format of the strace file is lost on me.
>> The last six lines of the ouput file are:
>
> Do you have different versions of JAVA from different vendors installed? I don't use Iced Tea as it's not always 100% compatible. Try to use just *one* vendor's version of JAVA as your active JAVA installation. I only use Sun's SDK as I have noticed problems using other vendors versions.
>
> HTH
>
> Keith Roberts
>
>
>> clone(child_stack=0x4202a250,
>> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND| CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARE NT_SETTID|CLONE_CHILD_CLEARTID,
>> parent_tidptr=0x4202a9d0, tls=0x4202a940, child_tidptr=0x4202a9d0) =
>> 23241
>> futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL) = -1 EINTR (Interrupted system call)
>> --- SIGHUP (Hangup) @ 0 (0) ---
>> futex(0x2ab0b620a000, FUTEX_WAKE_PRIVATE, 1) = 1
>> rt_sigreturn(0x2ab0b620a000) = -1 EINTR (Interrupted system call)
>> futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL <unfinished ... exit status 129>
>>
>> The SIGHUP is new information, and appears to be what's causing the
>> java app to exit. Surely Java should be aware of the Interrupted
>> system call?
>>
>> There are no other signals in the output file, and the only EINTRs are
>> in the passage above.
>>
>> Looks like I need to delve back into Java...
>>
>> Martin
>>
>> On 10 February 2011 19:37, <m.roth@5-cent.us> wrote:
>>> Hey, Martin,
>>>
>>> Martin Hewitt wrote:
>>>>
>>>> Thanks, I didn't know about the strace command, so that's useful.
>>>> Fortunately, this is on a dedicated server, so there's a fair amount
>>>> of free disk.
>>> <snip>
>>> If you can do the code changes (and the try/catch is *supposed* to be in
>>> there, according to java style), work your way down, y'know...
>>>
>>> main
>>>
>>> ...
>>> try {
>>> First actual call to do the job
>>> } catch
>>> writeln error;
>>>
>>> And if it fails there, then you know; otherwise, go to the next main call,
>>> sorry, "invocation of a method"....
>>>
>>> Then again, this time in each of the main function calls under that, and
>>> step down until you find the function it's dying in. That'll give you a
>>> much better handle on what's happening.
>>>
>>>> Thanks for the help.
>>>>
>>> Good luck.
>>>
>>> mark
>>>> Martin
>>>>
>>>> On 10 February 2011 18:58, <m.roth@5-cent.us> wrote:
>>>>> Martin Hewitt wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>>>>>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK 64-Bit
>>>>>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>>>>>
>>>>>> We have a java application, packaged as a jar, running on our servers
>>>>>> which, periodically, crawls RSS feeds and writes the articles to a
>>>>>> database.
>>>>>>
>>>>>> Randomly, and seemingly without cause, these processes will die, not
>>>>>> through the application exiting, or due to my killing it, but due to
>>>>>> something that seems to kill without leaving a trace.
>>>>> <snip>
>>>>> The hard (but correct) way would be to put try {} catch in the code, and
>>>>> work your way down. Trying to debug it using a debugger might be real
>>>>> problematical, if you can't repeatably provoke it. I *suppose* you could
>>>>> attach strace to it, and dump the o/p into a file (on a filesystem with
>>>>> a
>>>>> *lot* of disk space)....
>>>>>
>>>>> mark
>>>>>
>>>>> _______________________________________________
>>>>> CentOS mailing list
>>>>> CentOS@centos.org
>>>>> http://lists.centos.org/mailman/listinfo/centos
>>>>>
>>>> _______________________________________________
>>>> CentOS mailing list
>>>> CentOS@centos.org
>>>> http://lists.centos.org/mailman/listinfo/centos
>>>>
>>>
>>>
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS@centos.org
>>> http://lists.centos.org/mailman/listinfo/centos
>>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
> --
> -----------------------------------------------------------------
> Websites:
> http://www.karsites.net
> http://www.php-debuggers.net
> http://www.raised-from-the-dead.org.uk
>
> All email addresses are challenge-response protected with
> TMDA [http://tmda.net]
> -----------------------------------------------------------------_______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-11-2011, 01:13 PM
 
Default CentOS 5.5 Java Process Death

Martin Hewitt wrote:
> Hi Mark,
>
> I've exhausted the Java avenues for debugging this issue, but, since
> my last email, the process I pointed strace at has been killed, but
> I'm afraid the rather raw format of the strace file is lost on me.
> The last six lines of the ouput file are:
>
> clone(child_stack=0x4202a250,
>
At a guess, looks like it's creating a child process.
<snip>
> futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL) = -1 EINTR (Interrupted system
> call)
> --- SIGHUP (Hangup) @ 0 (0) ---
> futex(0x2ab0b620a000, FUTEX_WAKE_PRIVATE, 1) = 1
> rt_sigreturn(0x2ab0b620a000) = -1 EINTR (Interrupted system
> call)
> futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL <unfinished ... exit status 129>
>
> The SIGHUP is new information, and appears to be what's causing the
> java app to exit. Surely Java should be aware of the Interrupted
> system call?
>
> There are no other signals in the output file, and the only EINTRs are
> in the passage above.
>
Does the exit status of 129 say anything other than SIGHUP?

> Looks like I need to delve back into Java...
>
Yeah. I think you need to try what I was suggesting: start wrapping
function calls in try/catch, and work your way down (when you find the one
it fails in, then go into that function, er, method, and wrap the calls in
there (and/or even put a writeln in a few choice spots, until you find the
exact function the SIGHUP (or whatever) is happening in.

mark "why, yes, I *was* a developer longer than I've been an admin"

> Martin
>
> On 10 February 2011 19:37, <m.roth@5-cent.us> wrote:
>> Hey, Martin,
>>
>> Martin Hewitt wrote:
>>>
>>> Thanks, I didn't know about the strace command, so that's useful.
>>> Fortunately, this is on a dedicated server, so there's a fair amount
>>> of free disk.
>> <snip>
>> If you can do the code changes (and the try/catch is *supposed* to be in
>> there, according to java style), work your way down, y'know...
>>
>> main
>>
>> ...
>> try {
>> First actual call to do the job
>> } catch
>> * writeln error;
>>
>> And if it fails there, then you know; otherwise, go to the next main
>> call,
>> sorry, "invocation of a method"....
>>
>> Then again, this time in each of the main function calls under that, and
>> step down until you find the function it's dying in. That'll give you a
>> much better handle on what's happening.
>>
>>> Thanks for the help.
>>>
>> Good luck.
>>
>> * * * *mark
>>> Martin
>>>
>>> On 10 February 2011 18:58, *<m.roth@5-cent.us> wrote:
>>>> Martin Hewitt wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>>>>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK
>>>>> 64-Bit
>>>>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>>>>
>>>>> We have a java application, packaged as a jar, running on our servers
>>>>> which, periodically, crawls RSS feeds and writes the articles to a
>>>>> database.
>>>>>
>>>>> Randomly, and seemingly without cause, these processes will die, not
>>>>> through the application exiting, or due to my killing it, but due to
>>>>> something that seems to kill without leaving a trace.
>>>> <snip>
>>>> The hard (but correct) way would be to put try {} catch in the code,
>>>> and
>>>> work your way down. Trying to debug it using a debugger might be real
>>>> problematical, if you can't repeatably provoke it. I *suppose* you
>>>> could
>>>> attach strace to it, and dump the o/p into a file (on a filesystem
>>>> with
>>>> a
>>>> *lot* of disk space)....
>>>>
>>>> * * * *mark
>>>>
>>>> _______________________________________________
>>>> CentOS mailing list
>>>> CentOS@centos.org
>>>> http://lists.centos.org/mailman/listinfo/centos
>>>>
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS@centos.org
>>> http://lists.centos.org/mailman/listinfo/centos
>>>
>>
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-11-2011, 01:28 PM
Keith Roberts
 
Default CentOS 5.5 Java Process Death

On Fri, 11 Feb 2011, Martin Hewitt wrote:

> To: CentOS mailing list <centos@centos.org>
> From: Martin Hewitt <martin.hewitt@gmail.com>
> Subject: Re: [CentOS] CentOS 5.5 Java Process Death
>
> Hi Keith,
>
> Interesting idea, I've built the Sun SDK on one server,
> and left the yum-installed version on the other, and have
> started the same java application on both servers with
> strace, so I'll see if there's any difference.
>
> Thanks for all the help,

Well, it's not an idea Martin, it's what I've learnt by
experience . For example, the newer versions of
Eclipse IDE will not work with GCJ. Please see this excerpt
from the installation directory docs of Helios - Eclipse
3.6:

/eclipse/readme/readme_eclipse.html

3.1.2 General - GCJ

GCJ is an effort by the GCC team to provide an open
source Java compiler and runtime environment to interpret
Java bytecode. Unfortunately, the GCJ runtime environment
is not an environment that is often tested on by Eclipse
developers.

The most common problems surrounding GCJ are:

* Eclipse does not start at all
* Eclipse throws a 'java.lang.ClassNotFoundException:
org.eclipse.core.runtime.Plugin' that can be found in
the logs
(located in workspace/.metadata/.log)

The workspace's log file is a good place to check to
identify whether GCJ
is being used or not. Every Eclipse log session is
prepended with
information about the runtime environment that was used
to run Eclipse.
The log may include something like the following:

java.fullversion=GNU libgcj 4.2.1 (Debian 4.2.1-5)

If Eclipse does start, one can check which runtime
environment is being
used to run Eclipse by going to Help > About Eclipse SDK
> Installation
Details > Configuration. The About dialog itself can also
provide other
information, the build identifier can be of particular
interest as it is
tagged by some distributions. This allows the user to
identify whether
Eclipse was downloaded through the distribution's package
management
system or directly from the eclipse.org web site.

Eg: Build id: M20070212-1330 (Ubuntu version:
3.2.2-0ubuntu3)

The two most common workarounds are:

* download the Eclipse binary from eclipse.org directly
* run Eclipse using an alternate Java runtime
environment

To download Eclipse, try one of the links below:

* [40]http://www.eclipse.org/downloads/
* [41]http://download.eclipse.org/eclipse/downloads/

It is imperative that 64-bit builds are downloaded and
used if a 64-bit
Java runtime environment has been installed. Below are
two sample tarball
names of version 3.6.0 of the Eclipse SDK packaged for
32-bit and 64-bit
processors.

eclipse-SDK-3.6-linux-gtk.tar.gz (32-bit)
eclipse-SDK-3.6-linux-gtk-x86_64.tar.gz (64-bit)

To run Eclipse with an alternate Java runtime
environment, the path to the
Java virtual machine's binary must be identified. With an
Eclipse
installation from the distribution, altering the $PATH
variable to include
the path to the alternate Java runtime environment is
often not enough as
the Eclipse that Linux distributions package often
performs a scan
internally to pick up GCJ by itself whilst ignoring
what's on the $PATH.
An example of the terminal's output is shown below:

searching for compatible vm...
testing /usr/lib/jvm/java-7-icedtea...not found
testing /usr/lib/jvm/java-gcj...found

Once the path to the virtual machine's binary has been
identified, try
running Eclipse with the following command:

./eclipse -vm /path/to/jre/bin/java

For an actual example, it might look something like the
following:

./eclipse -vm /usr/lib/jvm/sun-java-6/bin/java
./eclipse -vm /opt/sun-jdk-1.6.0.02/bin/java

If this seems to solve the problem, it is likely that the
problem really was related to the use of GCJ as the Java
runtime for running Eclipse. The eclipse.ini file located
within Eclipse's folder can be altered to automatically
pass this argument to Eclipse at startup...

I use the following from Sun's download website:

jdk-6u18-linux-i586-rpm.bin

The latest 32bit version is available from here:

http://www.oracle.com/technetwork/java/javase/install-linux-rpm-137089.html

I've noticed other JAVA applications do not work correctly
either, on other vendor's java offerings. Which is the
reason for grabbing the rpm.bin from Sun/Oracle and
installing that.

HTH

Keith Roberts

-----------------------------------------------------------------
Websites:
http://www.karsites.net
http://www.php-debuggers.net
http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with
TMDA [http://tmda.net]
-----------------------------------------------------------------
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-14-2011, 09:54 AM
Martin Hewitt
 
Default CentOS 5.5 Java Process Death

Hi Mark,

Over the weekend I've been testing the environment under various
circumstances, and it seems that the kill issue is not confined to one
app - it's afflicting all jars I've packaged with Eclipse.

I added in as many try...catch blocks as I could and got no useful
output, but it occurred to me that the Eclipse loader is adding in
another level of code between my application and the kernel.

Due to the fact that Eclipse uses a jar-in-jar loader to package in
classpath libraries, I'm going to be experimenting today with a
different jar packager and with executing the application without jar
packaging.

Martin

On 11 February 2011 14:13, <m.roth@5-cent.us> wrote:
> Martin Hewitt wrote:
>> Hi Mark,
>>
>> I've exhausted the Java avenues for debugging this issue, but, since
>> my last email, the process I pointed strace at has been killed, but
>> I'm afraid the rather raw format of the strace file is lost on me.
>> The last six lines of the ouput file are:
>>
>> clone(child_stack=0x4202a250,
>>
> At a guess, looks like it's creating a child process.
> <snip>
>> futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL) = -1 EINTR (Interrupted system
>> call)
>> --- SIGHUP (Hangup) @ 0 (0) ---
>> futex(0x2ab0b620a000, FUTEX_WAKE_PRIVATE, 1) = 1
>> rt_sigreturn(0x2ab0b620a000) * * * * * *= -1 EINTR (Interrupted system
>> call)
>> futex(0x4202a9d0, FUTEX_WAIT, 23241, NULL <unfinished ... exit status 129>
>>
>> The SIGHUP is new information, and appears to be what's causing the
>> java app to exit. Surely Java should be aware of the Interrupted
>> system call?
>>
>> There are no other signals in the output file, and the only EINTRs are
>> in the passage above.
>>
> Does the exit status of 129 say anything other than SIGHUP?
>
>> Looks like I need to delve back into Java...
>>
> Yeah. I think you need to try what I was suggesting: start wrapping
> function calls in try/catch, and work your way down (when you find the one
> it fails in, then go into that function, er, method, and wrap the calls in
> there (and/or even put a writeln in a few choice spots, until you find the
> exact function the SIGHUP (or whatever) is happening in.
>
> * * * * mark "why, yes, I *was* a developer longer than I've been an admin"
>
>> Martin
>>
>> On 10 February 2011 19:37, *<m.roth@5-cent.us> wrote:
>>> Hey, Martin,
>>>
>>> Martin Hewitt wrote:
>>>>
>>>> Thanks, I didn't know about the strace command, so that's useful.
>>>> Fortunately, this is on a dedicated server, so there's a fair amount
>>>> of free disk.
>>> <snip>
>>> If you can do the code changes (and the try/catch is *supposed* to be in
>>> there, according to java style), work your way down, y'know...
>>>
>>> main
>>>
>>> ...
>>> try {
>>> First actual call to do the job
>>> } catch
>>> * writeln error;
>>>
>>> And if it fails there, then you know; otherwise, go to the next main
>>> call,
>>> sorry, "invocation of a method"....
>>>
>>> Then again, this time in each of the main function calls under that, and
>>> step down until you find the function it's dying in. That'll give you a
>>> much better handle on what's happening.
>>>
>>>> Thanks for the help.
>>>>
>>> Good luck.
>>>
>>> * * * *mark
>>>> Martin
>>>>
>>>> On 10 February 2011 18:58, *<m.roth@5-cent.us> wrote:
>>>>> Martin Hewitt wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm running CentOS 5.5 Final, Java version "1.6.0_17" OpenJDK Runtime
>>>>>> Environment (IcedTea6 1.7.5) (rhel-1.16.b17.el5-x86_64) OpenJDK
>>>>>> 64-Bit
>>>>>> Server VM (build 14.0-b16, mixed mode) installed via Yum.
>>>>>>
>>>>>> We have a java application, packaged as a jar, running on our servers
>>>>>> which, periodically, crawls RSS feeds and writes the articles to a
>>>>>> database.
>>>>>>
>>>>>> Randomly, and seemingly without cause, these processes will die, not
>>>>>> through the application exiting, or due to my killing it, but due to
>>>>>> something that seems to kill without leaving a trace.
>>>>> <snip>
>>>>> The hard (but correct) way would be to put try {} catch in the code,
>>>>> and
>>>>> work your way down. Trying to debug it using a debugger might be real
>>>>> problematical, if you can't repeatably provoke it. I *suppose* you
>>>>> could
>>>>> attach strace to it, and dump the o/p into a file (on a filesystem
>>>>> with
>>>>> a
>>>>> *lot* of disk space)....
>>>>>
>>>>> * * * *mark
>>>>>
>>>>> _______________________________________________
>>>>> CentOS mailing list
>>>>> CentOS@centos.org
>>>>> http://lists.centos.org/mailman/listinfo/centos
>>>>>
>>>> _______________________________________________
>>>> CentOS mailing list
>>>> CentOS@centos.org
>>>> http://lists.centos.org/mailman/listinfo/centos
>>>>
>>>
>>>
>>> _______________________________________________
>>> CentOS mailing list
>>> CentOS@centos.org
>>> http://lists.centos.org/mailman/listinfo/centos
>>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 06:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org