Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uyuni 2022.05 Tomcat failed to start #5447

Closed
bezkarl opened this issue May 16, 2022 · 6 comments
Closed

Uyuni 2022.05 Tomcat failed to start #5447

bezkarl opened this issue May 16, 2022 · 6 comments
Labels
bug Something isn't working P5

Comments

@bezkarl
Copy link

bezkarl commented May 16, 2022

Problem description

Installation of Uyuni 2022.05 fails with "Tomcat failed to start properly or the installer ran out of tries."

Version of Uyuni Server and Proxy (if used)

Information for package Uyuni-Server-release:

Repository : uyuni-server-stable
Name : Uyuni-Server-release
Version : 2022.05-180.1.uyuni1
Arch : x86_64
Vendor : obs://build.opensuse.org/systemsmanagement:Uyuni
Support Level : Level 3
Installed Size : 1.4 KiB
Installed : Yes (automatically)
Status : up-to-date
Source package : Uyuni-Server-release-2022.05-180.1.uyuni1.src
Summary : Uyuni Server
Description :
Uyuni lets you efficiently manage physical, virtual,
and cloud-based Linux systems. It provides automated and cost-effective
configuration and software management, asset management, and system
provisioning.

Details about the issue

Hi- I am running a fresh install of uyuni 2022.05 on a newly installed Opensuse 15.3 Leap and the installation fails with:

"Tomcat failed to start properly or the installer ran out of tries. Please check /var/log/tomcat/catalina.out or /var/log/tomcat/catalina.$(date +%Y-%m-%d).log for errors.
ERROR: spacewalk-setup failed"

This is the same with yast2 and using /usr/lib/susemanager/bin/mgr-setup -s

I wondering if this similar to issue #5278 with regard to netty:

S | Name | Type | Version | Arch | Repository
---+------------------------+------------+-------------------------+--------+-------------------------------------------------------------
v | netty | package | 4.1.75-150200.4.9.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
v | netty | package | 4.1.75-150200.4.6.2 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | netty | package | 4.1.44.Final-4.5.uyuni1 | noarch | uyuni-server-stable
v | netty | package | 4.1.13-bp153.2.46 | x86_64 | Main Repository

/var/log/tomcat/catalina.$(date +%Y-%m-%d).log output:

16-May-2022 14:42:14.053 WARNING [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [rhn] appears to have started a thread named [PG-JDBC I/O (1)] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.base@11.0.15/sun.nio.ch.EPoll.wait(Native Method)
java.base@11.0.15/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120)
java.base@11.0.15/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124)
java.base@11.0.15/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:141)
io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457)
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
java.base@11.0.15/java.lang.Thread.run(Thread.java:829)
16-May-2022 14:42:14.055 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@78d9e523]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@67afbc5e]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
16-May-2022 14:42:14.055 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@783d3671]) and a value of type [com.redhat.rhn.common.hibernate.SessionInfo] (value [com.redhat.rhn.common.hibernate.SessionInfo@8699caf]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
16-May-2022 14:42:14.056 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@783d3671]) and a value of type [com.redhat.rhn.common.hibernate.SessionInfo] (value [com.redhat.rhn.common.hibernate.SessionInfo@3f2e907c]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
16-May-2022 14:42:14.056 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [rhn] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@78d9e523]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@25f9868b]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
16-May-2022 14:42:14.061 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [84,095] ms
16-May-2022 14:42:14.076 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"]
16-May-2022 14:42:14.124 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"]
16-May-2022 14:42:14.148 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"]
16-May-2022 14:42:14.164 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [84,463] milliseconds

Please let me know is there any other logging information I can provide.

Kind regards,
Karl

@bezkarl bezkarl added bug Something isn't working P5 labels May 16, 2022
@abotelho-cbn
Copy link

May 16 17:44:22 testuyuni.ls.cbn server[10597]: 2022-05-16 17:44:22,585 ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3 ERROR Attempted to append to non-started appender xmlRpcFailOverAppender May 16 17:44:22 testuyuni.ls.cbn server[10597]: 2022-05-16 17:44:22,589 ajp-nio-0:0:0:0:0:0:0:1-8009-exec-3 ERROR FailoverAppender xmlRpcFailOverAppender did not start successfully

Same here.

@mcalmer
Copy link
Contributor

mcalmer commented May 18, 2022

Would you provide the following files please?

  • /var/log/rhn/rhn_installation.log
  • /var/log/rhn/install_db.log

and please check if there is something in the journal (aka "messages") about tomcat which is not in the catalina logfile already.

$> journalctl -u tomcat

@bezkarl
Copy link
Author

bezkarl commented May 18, 2022

Hi,

Thanks for the response.

Here are the files- there is nothing in /var/log/rhn/install_db.log:

rhn_installation.log
journalctl.txt

I have noticed an error in journalctl log regarding an authentication issue with the db which I am not sure is relevant:

Caused by: org.postgresql.util.PSQLException: FATAL: password authentication failed for user "uyuni"

Kind regards,
Karl

@mcalmer
Copy link
Contributor

mcalmer commented May 19, 2022

@bezkarl Do you have a whitespace in your password?

@bezkarl
Copy link
Author

bezkarl commented May 19, 2022

@mcalmer

Yes I do, and I have just re-run the setup with a different password without whitepsaces and it has worked!

Many thanks for your help in resolving this.

Kind regards,
Karl

@mcalmer
Copy link
Contributor

mcalmer commented May 19, 2022

Perfect. JFYI - The whitespace problem will be fixed when we switch to openSUSE Leap 15.4 as base os.
We also started an update for 15.3, but it seems it will not make it in time.

To support whitespaces with the new auth mechanism scram-sha-256 you need a new version or the postgresql-jdbc driver and new extra module. This was easier to change for the next version then in 15.3.

Closing this issue.

@mcalmer mcalmer closed this as completed May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P5
Projects
None yet
Development

No branches or pull requests

3 participants