CentOS 7 And Glassfish 2.1.1

Home » General » CentOS 7 And Glassfish 2.1.1
General 6 Comments


I have a server with CentOS 7 installed, on this server I installed Java
1.7 (java version “1.7.0_80”) and Glassfish 2.1.1. The last few days I’ve ran into a problem: Glassfish process got killed twice and I don’t have a clue why is getting terminated, I know that sometimes processes get killed if RAM is not enough; however on this server I have 62GB of RAM and 10GB of SWAP and Glassfish is configured to use only 15GB of RAM.

I’ve looked on all the logs on /var/log and there is nothing there, I
don’t see any message that can’t tell me why is the process being terminated.

Is there other place or is there something I can do to know why is this happening?

uname -a

Linux server.edh.mx 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Thank you very much.

Best regards,


6 thoughts on - CentOS 7 And Glassfish 2.1.1

  • I’ve not run it in YEARS, but I believe Glassfish maintains its own logs under wherever its installed.

    is that Java 1.7 the Sun/Oracle Java, or is it OpenJDK ? and where was Glassfish installed from? I didn’t think that was built into CentOS 7
    or any of the common repositories.

    john r pierce, recycling bits in santa cruz

  • El 11/07/2016 a las 05:35 p. m., John R Pierce escribió:

    Yes. But it is possible to use Glassfish 2.1.1 with Java 1.7 (I have other systems using that combo and they work fine). I cannot use Glassfish 4.1.1 because the application only runs in 2.1.1.


  • well, glassfish is open source, and its not part of CentOS so you’d best take this up with the Glassfish community, and/or debug it yourself.

    While we use Java SE at $job, we’ve avoided Java EE like the plague.
    *WAY* too many moving parts for our tastes.

    john r pierce, recycling bits in santa cruz

  • Hello.

    Thank you for your comments. Investigating further I’ve discovered where glassfish maintain the logs for core dumps:


    And they have the following name: hs_err_pidXXXX.log

    Hopefully this will help someone who runs into the same problem.

    Thank you.

    El 11/07/2016 a las 05:54 p. m., John R Pierce escribió: