After 3 days of continual operation ( I barely managed 9hrs before )
it seems I have narrowed this down to the saddeningly basic cause of
the process being sent the SIGHUP signal when its owner process dies.
Using the nohup prefix solves the problem.
Thanks for all the help on this everyone!
Mar
On 18/02/11 20:49, Michael Gliwinski wrote:
>
> Try adding 'nohup' before 'java'. Closing SSH session closes the shell which
> sends HUP to its children.
I religiously use 'screen' when logging in remotely to do any work. Not
only has saved me from interrupted work the connection breaks, but i
Martin Hewitt wrote:
> It's strange how one can wake up and suddenly notice a pattern...
>
> Looking through the straces, and the disconnect timestamps of the SSH
> sessions, it seems that the processes are dying as soon as, or shortly
> after the SSH session is closed.
>
> My command is something
On 18 February 2011 09:49, Michael Gliwinski
wrote:
> On Friday 18 Feb 2011 09:53:39 Martin Hewitt wrote:
>> My command is something along the lines of:
>>
>> java -cp /path/to/shared/libs/*:/path/to/class/directory/
>> path.to.MyApp > out.log 2>&1 &
>>
>> Does anyone have an idea as to why this p
On Friday 18 Feb 2011 09:53:39 Martin Hewitt wrote:
> My command is something along the lines of:
>
> java -cp /path/to/shared/libs/*:/path/to/class/directory/
> path.to.MyApp > out.log 2>&1 &
>
> Does anyone have an idea as to why this process is closing when the
> SSH window that started it clo
It's strange how one can wake up and suddenly notice a pattern...
Looking through the straces, and the disconnect timestamps of the SSH
sessions, it seems that the processes are dying as soon as, or shortly
after the SSH session is closed.
My command is something along the lines of:
java -cp /pa
Hi Cameron,
On 18 February 2011 04:33, Cameron Kerr wrote:
>
> On 17/02/2011, at 9:35 PM, Mathieu Baudier wrote:
>
>>> I've been running our apps as purely as I can (java -cp
>>> /path/to/libs/* path.to.the.App) and they're still being send SIGHUP
>>> signals for reasons I can't understand.
>>
>
On 17/02/2011, at 9:35 PM, Mathieu Baudier wrote:
>> I've been running our apps as purely as I can (java -cp
>> /path/to/libs/* path.to.the.App) and they're still being send SIGHUP
>> signals for reasons I can't understand.
>
I have only started in this thread, but your description of unexplain
> I've been running our apps as purely as I can (java -cp
> /path/to/libs/* path.to.the.App) and they're still being send SIGHUP
> signals for reasons I can't understand.
So, to sum you have tried:
- with various classloading approaches
- various JVMs
- on various systems
I must say that I'm real
On 14 February 2011 12:17, Mathieu Baudier wrote:
>> When I package a "Runnable JAR" using the Eclipse Export wizard, in
>> the manifest file, the main-class is given as
>> org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader, which I presume
>> is a little bit of code to redirect the main method
Hi Mathieu,
On 14 Feb 2011, at 12:17, Mathieu Baudier wrote:
>> When I package a "Runnable JAR" using the Eclipse Export wizard, in
>> the manifest file, the main-class is given as
>> org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader, which I presume
>> is a little bit of code to redirect the
> When I package a "Runnable JAR" using the Eclipse Export wizard, in
> the manifest file, the main-class is given as
> org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader, which I presume
> is a little bit of code to redirect the main method to the main method
> of my actual application. This is
Hi Mathieu,
> Can you please give more details about this "additional" code? How did
> you find out?
When I package a "Runnable JAR" using the Eclipse Export wizard, in
the manifest file, the main-class is given as
org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader, which I presume
is a little
> 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.
Can you please give more details about this "additional" code? How did
you find out?
Do you mean
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
On Fri, 11 Feb 2011, Martin Hewitt wrote:
> To: CentOS mailing list
> From: Martin Hewitt
> 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 o
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(c
at 07:05, Keith Roberts wrote:
> On Fri, 11 Feb 2011, Martin Hewitt wrote:
>
>> To: CentOS mailing list
>> From: Martin Hewitt
>> Subject: Re: [CentOS] CentOS 5.5 Java Process Death
>> Hi Mark,
>>
>> I've exhausted the Java avenues for debugging
On Fri, 11 Feb 2011, Martin Hewitt wrote:
To: CentOS mailing list
From: Martin Hewitt
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, bu
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_
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.
If you can do the code changes (and the try/catch is *supposed* to be in
there, according to java style),
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.
If you can do the code changes (and the try/catch is *supposed* to be in
there, according to java style),
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
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
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,
25 matches
Mail list logo
