deploying dataverse.war failed · troubleshooting

Hey everybody. I already obened a conversation here https://groups.google.com/g/dataverse-community/c/wL6Q2bsvw04/m/4KDBFk1IAgAJ?utm_medium=email&utm_source=footer but it is hard to find the reason, why the deployment failed. Maybe it is better in zulip.
Short summary: In the console I entered python3 install.py. Everthing worked fine and when it tryed to deploy the dataverse.war file I got this output
'No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command deploy failed.
Failed to deploy the application!'
But then when I look into the payara admin console I see the deployed dataverse war. But I cannot open localhost:8080. What happend there?
Can anybody help me?
server.log
2024-01-12_14h07_18.png
2024-01-12_14h06_34.png

Philip Durbin 🚀 (Jan 18 2024 at 12:34):

Hi! Thanks for joining.

Philip Durbin 🚀 (Jan 18 2024 at 12:34):

What do you get if you go to http://localhost:8080/api/info/version ?

Su Sa (Jan 18 2024 at 12:39):

{
"status": "OK",
"data": {
"version": "6.0",
"build": "1512-366fd41"
}
}

Su Sa (Jan 18 2024 at 12:41):

ah, hi philip, its you. cool

Philip Durbin 🚀 (Jan 18 2024 at 12:41):

Ok, so the war file has definitely been deployed.

Philip Durbin 🚀 (Jan 18 2024 at 12:42):

How about http://localhost:8080/api/metadatablocks ?

Su Sa (Jan 18 2024 at 12:42):

yes I also think so. but so console say it wasn't deployed

Su Sa (Jan 18 2024 at 12:43):

{
"status": "OK",
"data": []
}

Philip Durbin 🚀 (Jan 18 2024 at 12:43):

Ok, that's bad. It should have a lot of data, like this: https://demo.dataverse.org/api/metadatablocks

Philip Durbin 🚀 (Jan 18 2024 at 12:44):

How attached are you to this installation? Can we throw it away and start again?

Su Sa (Jan 18 2024 at 12:46):

yes, thats no problem. we can install everything from the beginning

Philip Durbin 🚀 (Jan 18 2024 at 12:48):

Great. What flavor of Linux are you using? Rocky? Ubuntu?

Su Sa (Jan 18 2024 at 12:53):

neither nor I use debian

Philip Durbin 🚀 (Jan 18 2024 at 13:00):

Ok. RHEL/Rocky is the preferred distro but Ubuntu/Debian should work.

Oliver Bertuch (Jan 18 2024 at 13:02):

I suspect that the bootstrap wasn't successful

Philip Durbin 🚀 (Jan 18 2024 at 13:02):

These are the recommended steps for a fresh reinstall: https://guides.dataverse.org/en/6.0/installation/installation-main.html#fresh-reinstall

Oliver Bertuch (Jan 18 2024 at 13:03):

I've seen exactly this behaviour with @Jutta Schnabel's deployment

Philip Durbin 🚀 (Jan 18 2024 at 13:03):

Well, this is not in containers.

Oliver Bertuch (Jan 18 2024 at 13:03):

WAR successfully deployed (themed 404 error and /api/info), but nothing else works

Oliver Bertuch (Jan 18 2024 at 13:03):

True, but the symptoms are the same

Oliver Bertuch (Jan 18 2024 at 13:03):

Maybe not the reason

Philip Durbin 🚀 (Jan 18 2024 at 13:04):

yeah

Philip Durbin 🚀 (Jan 18 2024 at 13:04):

I've been trying to get more output. To see what is going wrong.

Su Sa (Jan 18 2024 at 13:05):

https://guides.dataverse.org/en/6.0/installation/installation-main.html#fresh-reinstall i do this for more than 5 times

Oliver Bertuch (Jan 18 2024 at 13:06):

Probably the result is not going to be a different one then :wink:

Oliver Bertuch (Jan 18 2024 at 13:06):

Could you provide a server.log and output from the installer from one of the attempts?

Oliver Bertuch (Jan 18 2024 at 13:06):

That would be really helpful in trying to corner reasons why things blow up

Oliver Bertuch (Jan 18 2024 at 13:07):

(If these filenames and things mean nothing to you, let us know - happy to explain more)

Philip Durbin 🚀 (Jan 18 2024 at 13:08):

One of the five server.log's is above.

Philip Durbin 🚀 (Jan 18 2024 at 13:09):

I've been trying to get output from the terminal and setup logs: https://guides.dataverse.org/en/6.0/installation/intro.html#information-to-send-to-support-when-installation-fails

Oliver Bertuch (Jan 18 2024 at 13:09):

Installer log would be perfect - if some of the scripts fail, that might not be visible from the Payara logs

Philip Durbin 🚀 (Jan 18 2024 at 13:09):

gotta bike through the ice... back soon

Oliver Bertuch (Jan 18 2024 at 13:09):

Break a leg!

Su Sa (Jan 18 2024 at 13:12):

yes that would be no problem. I converted the server.log to fine should i return that?

Su Sa (Jan 18 2024 at 13:13):

what ist 'output from the installer from one of the attempts?'

Su Sa (Jan 18 2024 at 13:16):

'The scripts/api/setup-all.*.log files left behind by the installer.' this files are not genered. if I look into the install.py i can see, that this files will be genereted after deploying of the war. I thing its not generedet because it interrupt the installing process before it will generate this files.

Su Sa (Jan 18 2024 at 13:26):

I got an error when I tried to drop the database
'psql: Error: Connection to server failed on socket '/var/run/postgresql/.s.PGSQL.5432': FATAL: Peer authentication failed for user 'dvnapp''

Philip Durbin 🚀 (Jan 18 2024 at 13:55):

Hmm, I wonder if the database was ever created. If not, there's nothing to drop.

Su Sa (Jan 18 2024 at 14:00):

ok, how can i check it?

Philip Durbin 🚀 (Jan 18 2024 at 14:03):

[postgres@ip-172-31-5-10 ~]$ psql
psql (13.9)
Type "help" for help.

postgres=# \l
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 dvndb     | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =Tc/postgres         +
           |          |          |             |             | postgres=CTc/postgres+
           |          |          |             |             | dvnuser=CTc/postgres
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(4 rows)

postgres=#

Philip Durbin 🚀 (Jan 18 2024 at 14:03):

Something like that. ^^

Philip Durbin 🚀 (Jan 18 2024 at 14:03):

The database is called "dvndb".

Su Sa (Jan 18 2024 at 14:04):

yes i check it. but I saw this before

Su Sa (Jan 18 2024 at 14:04):

but now nothing happen. Only this error appears.

Philip Durbin 🚀 (Jan 18 2024 at 14:05):

Can you drop the "dvndb" database using the "postgres" user instead of the "dvnapp" user?

Philip Durbin 🚀 (Jan 18 2024 at 14:06):

Also, apologies, but I need to run a meeting soon. You're welcome to join if you like: #containers > weekly meeting

Su Sa (Jan 18 2024 at 14:07):

no problem. then we go on later.

Philip Durbin 🚀 (Jan 18 2024 at 14:08):

Also, even if the setup log files can't be found, you see output on your terminal, right? When you run install.py.

Su Sa (Jan 18 2024 at 14:11):

yes i see

Philip Durbin 🚀 (Jan 18 2024 at 14:11):

Can you please share that output?

Su Sa (Jan 18 2024 at 14:13):

yes now it says performing database setup
Admin database connectivity succeeds.
PostgreSQL version: 13
Looks like the user already exists. Continuing.
Couldn't create database or database already exists.

Su Sa (Jan 18 2024 at 14:13):

now something went wrong with the database

Su Sa (Jan 18 2024 at 14:16):

ok, I think we have to go on tomorow. I have to pick up my kids.....

Philip Durbin 🚀 (Jan 18 2024 at 14:20):

Sounds good. I'm taking a day off tomorrow but I'm happy to help on Monday.

Su Sa (Jan 22 2024 at 09:26):

Good morning. A miracle has happened. I deleted the database manually and the install.py could run throught to the end. I tried a lot to delete the dvndb but there was no way. Both the dnvapp and the postgres were not allowed to delete the dvndb. I disable all the access restrictions on localhost connections in the pg_hba.conf.