Confluence 6.15.4 installation setup error

[Scott Ortel]

Hi All, I have been trying to setup a new install of confluence on CentOS 7.  I have installed confluence many times (earlier versions) but this time I just keep getting a fatal error during setup.  It seems to happen during DB initialization for the PostgrSQL or the internal DB.  Here are the basic steps that I have performed:

./atlassian-confluence-6.15.4-x64.bin
(Answer ‘no’ to startup at end so that I can setup the correct file ownership)

chown -R confluence:confluence /opt/atlassian/confluence /var/atlassian/application-data/confluence

service confluence start

Browse to confluence and begin setup

Enter my license key

Select 'Internal DB' (for simplicity sake to rule out any PostgreSQL issues, which also blows up)

It runs for a while, then blows up.  The log shows the following around the time that it fails:

2019-05-18 10:15:47,700 INFO [ThreadPoolAsyncTaskExecutor::Thread 19] [migration.agent.queue.QueueBroker] info Started queue broker. Registered consumers: [com.atlassian.migration.agent.service.stepexecutor.impl.ExportExecutor@10df0804, com.atlassian.migration.agent.service.stepexecutor.impl.UploadExecutor@2ffb4884, com.atlassian.migration.agent.service.stepexecutor.attachment.AttachmentMigrationExecutor@7a5a7798, com.atlassian.migration.agent.service.stepexecutor.impl.ImportExecutor@19ad987]
-- referer: http://localhost:8090/setup/setupdbchoice-start.action | url: /setup/setupembeddeddb-default.action | traceId: 004000c7668ff4cf | userName: anonymous | action: setupembeddeddb-default
2019-05-18 10:15:47,705 WARN [SiteSummaryCalculator:thread-1] [status.service.systeminfo.UsageInfo] getCountForQuery Unable to execute usage info query: SELECT COUNT(*) FROM users - Table "USERS" not found; SQL statement:
SELECT COUNT(*) FROM users [42102-196]
-- referer: http://localhost:8090/setup/setupdbchoice-start.action | url: /setup/setupembeddeddb-default.action | traceId: 004000c7668ff4cf | userName: anonymous | action: setupembeddeddb-default
org.h2.jdbc.JdbcSQLException: Table "USERS" not found; SQL statement:
SELECT COUNT(*) FROM users [42102-196]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)

Any help is greatly appreciated!  Thanks,

Scott

[Shankar Asam {Appfire} · Accepted solution]

Scott,

The embedded db installations should work without any problem. Could you re-run the confluence installation again after following the below steps;

1. Stop the confluence. 

2. Delete / rename the home directory and recreate the new one.

mv /var/atlassian/application-data/confluence /var/atlassian/application-data/confluence.old

mkdir -p /var/atlassian/application-data/confluence

chown -R confluence:confluence  /var/atlassian/application-data/confluence

3. Start the installation again and check if you still getting the error.

And also, let me know what version of postgreSQL you're using. If the above installation is successful, you can create a new postgresql DB and follow the above procedure and run the installation with new postgresql DB and check

-Shankar

[Scott Ortel]

Shankar,

Thank you for taking the time to respond.  This VPS server had been used in the past to host Confluence 5.5.  However, upon further inspection, it appears that it may be a memory problem.  The server has 2G, but that does not seem to be enough.  I spotted memory warnings in confluence logs.  Also, watching 'top' seemed to indicate that free memory was going to zero.  This seemed to be crashing the setup in strange ways, and even crashing the VM.  I thought 2G was enough.  However, after stopping another process to gain just a bit more memory, the setup completed. However the VM did crash again later when I attempted to install the Gliffy plugin or update the plug-in manager.

Thanks again,

Scott

[Shankar Asam {Appfire}]

Scott,

Glad to know that the installation issue has been fixed.

I think 2GB isn't enough as 50-60% of memory should be allocated to confluence and rest of it can be taken by OS and again if the data grows rapidly you would need to think about the scalability as well. 

Thanks

Shankar

[Scott Ortel]

Shankar,

Indeed.  Increasing the memory to 3G fixed the problem.  Luckily, the server is lightly hit and data increase is not a problem.

Thanks,

Scott