How to unwind a failed Confluence Server 7.x install on Linux: what's my path forward?

[James Bullock]

Fresh Confluence 7.<current> install on fresh / clean OpenSuSE Leap 15.1 (with KDE desktop, all patches to date) via installer ("zzz.bin", run to install), ran, launched web install, connect to database (so app running in app server on Java.) stalled on creating initial site as "restore" of backup (from small 6.11.2 site.)

I'd rather not poke around randomly: Don't restore w/ conversion until you're the whole way up?; How to get "install" to launch into web app again anyway?; Java weirdness?; Blow away n recreate empty target DB?; other...

• Choked creating initial site, as "restore"
  
  • Stalled for >20 min, page showing "initializing", w no resoruce consumption.
  • Won't relauch app in browser, reporting system error.
  • Reinstall won't work w/ prior in place.
  • Blowing away Confluence user, /opt and /var directories doesn't help reinstall: same result from launch of app in browser.

What's the best path forward is from here? Perhaps there's some factoid that'll tell me one thing to unwind? How the restore failed or stalled install at that point? How to try the built-in demo site, to confirm function?

• Yes, I'm aware of the Linux installer issue in the issues system.
  • The needed packages are present in 15.1 & the installer runs.
• All configs as what they installer does; that's why rather run installer.
• Memory is tight on that machine: memory only partially used during "recover" failure.

This is a sandbox so system, dependency, side-effect and cruft are contained. I'd still rather not wipe the install to clean this up.

[James Bullock]

Additional info: Any suggestions? Anybody? Bueller?

Install after wiping install directories, user, n drop / create of target database (confluenceuser, owned by confluenceuser), declares success. Access via browser:

Confluence had problems starting up. Could not load from environment. NullPointerException. (See attached pic.) Logs not available via app link.

• Locate n dig through logs to figure out what's going on.
• Investigate "confluence" user environment for Java weirdness.
• Wipe n reinstall distro, then Confluence:
  • Install 7.0.2, n choose demo site, bypassing import from archive.
  • Install 6.11.2 -- sourced site -- n see if it comes up n loads that.

[James Bullock]

So, working hypothesis is that despire the "<version>.bin" running without reported errors, the captive account running the application ("confluence") reads in some wrong Java weirdness.

Just what I was hoping to avoid dealing with by running the installer. (What good is dropping in your own JRE if the wrapping setup program doesn't make the captive user it creates point to that?)

[James Bullock]

Semi-partial answer, still investigating via experiments, guidance, & chasing back error messages and logs...

• The installer won't Just Work(tm) on vanilla OpenSuSE 15.1 (several permutations of Confluence 6.x, 7.0.2, 7.0.3, and OpenSuSE 15.0, and 15.1)
• To get the install to go, first unwind default OpenSuSE install of legacy OpenJDK (that you didn't ask for.) and point JAVA_HOME to a comptible Java.
• Now get reproducably stuck at the "null pointer exception" on launching setup access via browser.
• Some sequence I did not notice as different, *did* get past the "null pointer", through setup wizard  and import of backup from prior site, with version upgrade.
  • Current hypothesis is browser plus Tomcat interact differently when run off the network ("localhost" only), leading to refs to objects that don't exist.

Not an anser yet. This is incomplete, hacky, doubtless part wrong, and makes no sense.

FWIW, legacy install of Confluence 6.x on OpenSuSE 15 years ago *did* install and configure, but *would not run*, traced to residual runtime environment reference to system OpenJDK, overcome by hand-asserting JAVA_HOME in Confluence run-time startup scripts.