Confluence Documentation

Confluence Latest 
Confluence 5.3 Documentation 
Confluence 5.2 Documentation 
Confluence 5.1 Documentation 
More...
 

 

Search the Confluence Knowledge Base

You're visiting the Confluence Knowledge Base. Visit the Confluence Knowledge Base Home for an overview.

Skip to end of metadata
Go to start of metadata

Symptoms

After stopping confluence via catalina.sh stop Confluence says, in the logs, that it is stopping, as below:

but the java process never terminates.

Resolution

Pass the -force parameter to catalina.sh as:

This will kill the java process and stop Confluence.

If the above results in an error, such as:

Please add the following line of code to the top of your <Confluence-Installation-Directory>/bin/setenv.sh file (Standalone instance):

Tomcat will automatically write its process id to id.pid in your specified path and kill its process with the -force parameter.

For Linux or Mac user:
In addition to the above, you can try a custom script that runs shutdown.sh first before forcing Tomcat to shutdown. This script will sleep 60 seconds then look inside ./id.pid to check if Tomcat is still running. If Tomcat is still running, it will issue a catalina.sh stop -force.

The script needs to be saved in <confluence install>/bin and assumes id.pid is located in the same location.

(info) Note that this script is provided as is and not supported.

Finding the Root Cause of Shutdown Problems

Icon

If you're interesting in tracking down the root cause of the problem, your best option is to:

  1. Attempt to shut down your application server
  2. Take 3-5 thread dumps spaced 1 minute apart.
  3. Look through the thread dumps to see what threads are still active after 5 minutes.
  4. If you need help analyzing the thread dump output, send your updated application server logs to Atlassian Support.

Related Content

 Expand to see related content

Related Content with Label 'shutdown'


Help us improve!
Is this article helpful?
Is the content complete?
Is it well written?

14 Comments

  1. Is this something that will ever be fixed as part of Confluence release?

    At present we have to implement the fix after every upgrade which is mildly annoying.

    1. We're pretty sure it's not a Confluence bug (rather it's an environment issue), but we don't yet know a root cause for this problem. We're still investigating it.

      1. If it helps any, our environment is as follows:

        Confluence 3.0.2

        MySQL JDBC driver 5.1.7

        Ubuntu 9.04

        Confluence System Information Page Details:

        =================================

        Confluence Home

        /usr/local/atlassian/data/confluence

        Uptime

        6 days, 13 hours, 27 minutes, 27 seconds

        Confluence Version

        3.0.2

        Build Number

        1636

        Support Entitlement Number

        991945

        Daily XML Backup

        Enabled

         

        System Information

        System Date

        Wednesday, 18 Nov 2009

        System Time

        09:59:35

        System Favourite Colour

        Lemon chiffon

        Java Version

        1.6.0_13

        Java Vendor

        Sun Microsystems Inc.

        JVM Version

        1.0

        JVM Vendor

        Sun Microsystems Inc.

        JVM Implementation Version

        11.3-b02

        Java Runtime

        Java(TM) SE Runtime Environment

        Java VM

        Java HotSpot(TM) Client VM

        Java Input Arguments

        -Xms512m -Xmx1024m -XX:MaxPermSize=256m -Djava.awt.headless=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/usr/local/atlassian/confluence/confluence/conf/logging.properties -Djava.endorsed.dirs=/usr/local/atlassian/confluence/confluence/endorsed -Dcatalina.base=/usr/local/atlassian/confluence/confluence -Dcatalina.home=/usr/local/atlassian/confluence/confluence -Djava.io.tmpdir=/usr/local/atlassian/confluence/confluence/temp

        User Name

        confluence

        System Language

        en

        System Timezone

        Europe/Dublin

        Operating System

        Linux 2.6.28-15-server

        OS Architecture

        i386

        Filesystem Encoding

        UTF-8

        Application Server Working Directory

        /usr/local/atlassian/data/confluence

        Temp Directory

        /usr/local/atlassian/confluence/confluence/temp

        Application Server

        Apache Tomcat/6.0.14

        Servlet Version

        2.5

        Server Base Url

        http://confluence.xxx.xxx.com

         

        Java VM Memory Statistics

        Total Memory

        613 MB

        Free Memory

        84 MB

        Used Memory

        528 MB

        Memory Graph

         

         

         

         

         

          14 % Free

         

         

        Database Information

        Database Dialect

        com.atlassian.hibernate.dialect.MySQLDialect

        Database Connection URL

        jdbc:mysql://localhost/confluence?autoReconnect=true&useUnicode=true&characterEncoding=utf8

        Database Driver Name

        com.mysql.jdbc.Driver

        Database Driver Version

        5.1

        Database Connection Transaction Isolation

        Read committed

        Database name

        MySQL

        Database version

        5.1.31-1ubuntu2

        Database Latency

        0 ms

        Application Server

        Apache Tomcat/6.0.14

        Servlet Version

        2.5

        Server Base Url

        http://confluence.xxx.xxx.com

  2. To my experience with many different installations, all similar symptoms were due to problems with the database connection, not with JIRA or Confluence. eg. trying to start a just stopped system. The Database socket isn't closed yet, and occupied. Then java must be killed. Tipp. Don't hurry, just wait a few (5-10) seconds after stopping, then do the start.

  3. Tomcat without Confluence deployed will shut down.  A thread dump with the shutdown of Tomcat with Confluence shows threads waiting on objects, at org.quartz.simpl.SimpleThreadPool.getNextRunnable(SimpleThreadPool.java:428)
            - locked <0x00002aaac7c1fd50> (a java.lang.Object)

    - waiting on <0x00002aaacb587c70> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnab
    le)

    at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:423)
            - locked <0x00002aaacf6f2ee8> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)

  4. We have this same issue here on our site.  I've been manually killing these processes on our Solaris environment.  It appears to occur after using the Confluence Daily Backup.

  5. It's just a little embarrassing but I don't know how to construct a specific for the template:

    CATALINA_PID="<Change this to your preferred location>/id.pid"export CATALINA_PID

    Is "id.pid" a file. Do you have to create a blank file first?

    Should it be something like:

    /var/run/catalina_id.pid ????

    Thanks for the extra help!

    1. Hi Todd,

      You can just create a blank file with that name, and it should get populated.

  6. According to the readme RUNNING.txt packaged with Tomcat 6 and the Confluence installation steps we should be using, shutdown.sh and startup.sh.

    Just from what I can see, startup.sh does a bunch of things and then calls catalina.sh.

    This does not solve the problem though. I have setup 5 different Ubuntu configurations, 9.10 and 10.10 with PostgreSQL, virtual and not virtual and run into this problem every time.

    It has actually been years since this has been fixed. I can tell you that some admins I have introduced Confluence to chose not to adopt Confluence simply because of this bug.

    From what I can tell, "Benjamin White" took the stock Confluence, removed it and was able to shutdown and startup the packaged tomcat. This points to an issue with Confluence code. The only thing I can think of is to check and ensure that the servlet destroy methods are releasing the database connections.

  7. I tried all suggestions but on Mac-Server it always leaves a bunch of java processes running and does not fully shutdown.

    If I use suggested scripts right after I have started confluence they do work – all of them.

    But after a few minutes of working on confluences it seems to be that a shutdown command is not able to force a full release of all connections to ports and files which you can see as left open if you look at the activity statistics and take a glance at the java processes still running after shutdown.

    I do start a script to shut down confluence and than I shutdown all Java opened connections to files and ports – I never have had any problem restarting confluence after such a manual forced shutdown. 

    It seems to be a confluence bug – someone of the Atlassian tech-writers should take all this data of this page and put it into an corresponding issue.

    1. Klaus and Tim,

      Thank you! I had made this kb article based on what appears to be an incorrect assumption, that it was an environment factor. I've asked our development team to take a look and when we have more specific info (and hopefully a set of specific ways to replicate), we'll indeed open a bug report. Stay tuned...

  8. What happens during shutdown - "CONFLUENCE-INSTALL/bin/shutdown.sh" executes the "catalina.sh" script (in the same directory).
    "catalina.sh" does the heavy lifting required to shutdown the Tomcat process, but it requires CATALINA_PID exist and be correctly set.  

    The last line of "shutdown.sh" execs (calls) "catalina.sh" and passes arguments.  While the shell command "exec" starts a new process, it has the undesirable side effect of stripping previously set environment variables, like CATALINA_PID. CATALINA_PID is required for the Tomcat shutdown process to proceed using the code in the "catalina.sh" script.  If you have a shutdown script that sets CATALINA_PID and calls "shutdown.sh", the shutdown will fail.

    Setting and exporting CATALINA_PID in the "CONFLUENCE-INSTALL/bin/setenv.sh" script fixes the problem.  This file is sourced (included) by the "catalina.sh" script (~ line 120), making any environment variables set in this file available to "catalina.sh".

    CATALINA_PID=/var/conf-home/run/confluence.pid
    export CATALINA_PID

    When Confluence is started, the "confluence.pid" file is created in the directory shown.  It contains the PID (process id) number of the Confluence process.  The startup/shutdown scripts use the existence of this file to prevent multiple instances from running (bad).  The shutdown script uses the process id number contained in this file to stop the process.

    Note that CATALINA_PID is an absolute filename, with full path included.  I have created a "run" directory under my CONFLUENCE-HOME (confluence runtime data) and given the confluence user ownership of this directory.  You should have unique pid filenames and/or locations if you are running multiple standalone installations of Confluence/Jira/Crowd on the same machine.

    One possible fix to version upgrades clobbering "setenv.sh" is to modify the "catalina.sh" script to look in locations outside of the CONFLUENCE-INSTALL directory.  IMHO, the scattered configuration files are the most troublesome part of installing and maintaining this family of products.

  9. Hi Otto,

    Wow, good write-up. I will read through it give it a try.

    To the Confluence team, have you tried this?

    If you are having trouble replicating this problem, you can quickly setup Confluence standalone on Ubuntu using the Rackspace or Slicehost Cloud environments.

    1. Hi Tin,

      To the Confluence team, have you tried this?

      This has been tried and the work around was suggested in this KB.

      In addition, I have filed a report in https://jira.atlassian.com/browse/CONF-22880 as to include the work around in our releases.

      Let me know if there's anything else I can help with.

      Kind Regards,

      Roy Hartono