Stream: troubleshooting

Topic: DOI config change, server down

Andrés Díaz Hurtado (Jan 31 2025 at 19:49):

Hello, we installed dataverse to version v. 6.3 build 1607-8c99a74, we configured the default.config file with the datacite fields for DOI consumption, but the fields were set to fake, we have modified most of the fields with ‘fake’, but at this moment the dataverse field. pid.datacite.type=FAKE, where we have tried to change the variable =FAKE by DATACITE or datacite, but when the setting is done, the dataverse URL remains in the "your server is now runnig" screen, how to solve this error.

Translated with DeepL.com (free version)

Philip Durbin 🚀 (Jan 31 2025 at 19:51):

In server.log do you see messages about ConfigCheckService?

Andrés Díaz Hurtado (Jan 31 2025 at 19:56):

No, And verifying this file has not been modified since installation. /usr/local/payara6/glassfish/domains/domain1/logs

Philip Durbin 🚀 (Jan 31 2025 at 19:59):

Interesting. I expected that you might see errors like this above the config check error:

"No PID providers configured"

"No default PID provider configured"

Philip Durbin 🚀 (Jan 31 2025 at 19:59):

Can you please attach your server.log file?

Andrés Díaz Hurtado (Jan 31 2025 at 20:03):

Yes

Andrés Díaz Hurtado (Jan 31 2025 at 20:05):

server.log

Andrés Díaz Hurtado (Jan 31 2025 at 20:06):

Also, when a project is created, it is not being registered to Datacite, this error can be caused by FAKE?

Philip Durbin 🚀 (Jan 31 2025 at 20:07):

Well, this is the error I see in your log: "java.net.BindException: Address already in use"

Philip Durbin 🚀 (Jan 31 2025 at 20:07):

Are there multiple versions of Payara running?

Philip Durbin 🚀 (Jan 31 2025 at 20:08):

I would stop payara and then do a ps -efww | grep -i paraya

Andrés Díaz Hurtado (Jan 31 2025 at 20:10):

No, at this moment we only have payara in version 6.2024.6, previously we had version 5 in another server, but a new installation was made. In this installation the migration of a whole project was done.

Philip Durbin 🚀 (Jan 31 2025 at 20:11):

Ok but that "address already in use" error suggests that something might already be running on a port that Payara wants to use, such as port 8080.

Philip Durbin 🚀 (Jan 31 2025 at 20:11):

You could try rebooting the server, I guess. That will definitely stop anything that might be using port 8080.

Andrés Díaz Hurtado (Jan 31 2025 at 20:12):

Captura de pantalla 2025-01-31 151038.png

Philip Durbin 🚀 (Jan 31 2025 at 20:12):

Ok, good. Nothing payara-related running.

Philip Durbin 🚀 (Jan 31 2025 at 20:12):

But when you start you get the "Address already in use" error? Is anything else running on port 8080?

Philip Durbin 🚀 (Jan 31 2025 at 20:13):

I think the syntax is lsof -i :8080 but please don't quote me.

Philip Durbin 🚀 (Jan 31 2025 at 20:13):

And Payara does use a couple other ports as well.

Andrés Díaz Hurtado (Jan 31 2025 at 20:18):

This is what runs on port 8080

Andrés Díaz Hurtado (Jan 31 2025 at 20:19):

Captura de pantalla 2025-01-31 151647.png

Philip Durbin 🚀 (Jan 31 2025 at 20:20):

Huh. Some java process? What is it? Can you kill it?

Andrés Díaz Hurtado (Jan 31 2025 at 20:21):

Is payara

Andrés Díaz Hurtado (Jan 31 2025 at 20:22):

Captura de pantalla 2025-01-31 152148.png

Philip Durbin 🚀 (Jan 31 2025 at 20:25):

Ah ha! Multiple Payaras trying to run. So! Please try killing them all. Then try starting it up.

Andrés Díaz Hurtado (Jan 31 2025 at 20:27):

When I kill the process, solr automatically creates a new one

Philip Durbin 🚀 (Jan 31 2025 at 20:28):

Hmm, is there a parent process you can kill?

Andrés Díaz Hurtado (Jan 31 2025 at 20:31):

No, only the process of solr.

Andrés Díaz Hurtado (Jan 31 2025 at 20:31):

Captura de pantalla 2025-01-31 153129.png

Philip Durbin 🚀 (Jan 31 2025 at 20:37):

There should be a way to kill Solr and have it stay dead. :skull_and_crossbones:

Philip Durbin 🚀 (Jan 31 2025 at 20:38):

Do you have init scripts set up? Do your services when you reboot the server?

Andrés Díaz Hurtado (Jan 31 2025 at 20:48):

Done, I stopped solr with systemctl stop solr and uploaded payara with systemctl start payara

Philip Durbin 🚀 (Jan 31 2025 at 20:48):

great!

Andrés Díaz Hurtado (Jan 31 2025 at 20:49):

Captura de pantalla 2025-01-31 154923.png

Philip Durbin 🚀 (Jan 31 2025 at 20:51):

Progress! But now you need to start Solr.

Andrés Díaz Hurtado (Jan 31 2025 at 20:52):

When I upload solr it creates the same java processes

Philip Durbin 🚀 (Jan 31 2025 at 20:53):

Hmm, usually Solr and Payara play nicely together. :thinking:

Philip Durbin 🚀 (Jan 31 2025 at 20:53):

Usually they can run side-by-side.

Andrés Díaz Hurtado (Jan 31 2025 at 20:53):

ok

Andrés Díaz Hurtado (Jan 31 2025 at 20:55):

But this solves the problem?

Philip Durbin 🚀 (Jan 31 2025 at 21:00):

Well, I'm still confused about how Solr can conflict with Payara. They run on different ports.

Philip Durbin 🚀 (Jan 31 2025 at 21:01):

From the one screenshot you posted it looked like an old version of Payara was running (but I'm not sure why it didn't show up with ps :shrug: ).

Andrés Díaz Hurtado (Jan 31 2025 at 21:03):

But there is an alternative to correct the error?

Andrés Díaz Hurtado (Jan 31 2025 at 21:03):

As I indicated it is a new installation on a different server than the previous one in use.

Philip Durbin 🚀 (Jan 31 2025 at 21:04):

My theory is that you tried to stop Payara but it didn't fully stop. Then, when you went to try to start Payara, it couldn't start because of the port conflict. So the solution is to full stop the old Payara. This happens sometimes.

Andrés Díaz Hurtado (Jan 31 2025 at 21:09):

So restarting the server would be a better option, please remember that you only have one version of payara.

Philip Durbin 🚀 (Jan 31 2025 at 21:10):

Restarting is one way to fix it, yes.

Andrés Díaz Hurtado (Jan 31 2025 at 21:11):

Ok I will do the process and I will be reporting back

Andrés Díaz Hurtado (Jan 31 2025 at 21:11):

Thaks for you help

Philip Durbin 🚀 (Jan 31 2025 at 21:11):

Sure. Have a good weekend!

Andrés Díaz Hurtado (Jan 31 2025 at 21:20):

Sorry is it necessary to add this variable to the domain.xml file ./asadmin create-jvm-options “-Ddataverse.spi.pidproviders.directory=/path/”

Andrés Díaz Hurtado (Feb 03 2025 at 14:22):

Good Day. Is it necessary to add this variable to the domain.xml file ./asadmin create-jvm-options “-Ddataverse.spi.pidproviders.directory=/path/”?

Philip Durbin 🚀 (Feb 03 2025 at 14:24):

Hmm. I'm pretty sure that setting is optional. Let me check the docs.

Philip Durbin 🚀 (Feb 03 2025 at 14:25):

Above https://guides.dataverse.org/en/6.3/installation/config.html#dataverse-spi-pidproviders-directory it says "The following three global settings are required to configure PID Providers in the Dataverse software" but I don't think that's right. I think only the first two are required. :thinking:

Andrés Díaz Hurtado (Feb 03 2025 at 14:39):

Ok, I understand, I am still working on solving the error, the server has been restarted but we continue with the same error.

Philip Durbin 🚀 (Feb 03 2025 at 14:47):

Bummer. Meanwhile, I made this PR to clarify the docs: clarify which PID settings are required #11205. Thanks for catching that!

Philip Durbin 🚀 (Feb 03 2025 at 14:48):

Same error? Can you please remind me what the error is?

Andrés Díaz Hurtado (Feb 03 2025 at 15:07):

There is a field 'Ddataverse.pid.*.type=FAKE' which we have tried to change to 'FAKE', but when the change is made it does not upload dataverse and remains in “your server is now runnig”, also when entering a dataset it is not registered in datacite. When the dataverse installation was done, the “default.config” file was configured with the data of our datacite in the “[doi]” fields, but when reviewing the “domain.xml” file in the path ‘/usr/local/payara6/glassfish/domains/domain1/config/’ everything was in “FAKE”.

Philip Durbin 🚀 (Feb 03 2025 at 15:09):

I see. Lots of problems at once. :disappointed:

Philip Durbin 🚀 (Feb 03 2025 at 15:10):

You would like to use DataCite instead of FAKE. Is that right?

Andrés Díaz Hurtado (Feb 03 2025 at 15:12):

Yes, is right

Philip Durbin 🚀 (Feb 03 2025 at 15:16):

I struggled with this config myself. Here's what worked for me:

dataverse.pid.providers=dc1
dataverse.pid.default-provider=dc1
dataverse.pid.dc1.type=datacite
dataverse.pid.dc1.label=DataCite
dataverse.pid.dc1.authority=10.70122
dataverse.pid.dc1.shoulder=FK2/
dataverse.pid.dc1.datacite.mds-api-url=https://mds.test.datacite.org
dataverse.pid.dc1.datacite.rest-api-url=https://mds.test.datacite.org
dataverse.pid.dc1.datacite.username=REDACTED
dataverse.pid.dc1.datacite.password=REDACTED

Andrés Díaz Hurtado (Feb 03 2025 at 15:27):

In the field ‘dataverse.pid.dc1.shoulder=FK2/’, Datacite must be informed about the field ‘FK2/’, for example one of the doi we have published is ‘https://doi.org/10.60790/EK61SN’ which is correctly registered in Datacite (This was migrated from our old version), but not https://doi.org/10.60790/FK2/EK61SN. Do I make myself understood?

Philip Durbin 🚀 (Feb 03 2025 at 15:28):

The shoulder is optional.

Philip Durbin 🚀 (Feb 03 2025 at 15:29):

We always use that FK2/ shoulder in testing. I'm not sure why, to be honest. :shrug:

Andrés Díaz Hurtado (Feb 03 2025 at 15:31):

Ok, got it, I'll leave it ‘/’ for the moment, so as not to have a problem with Datacite. Anyway, I will check the fields in the domain.xml file.

Philip Durbin 🚀 (Feb 03 2025 at 15:37):

Instead of / you should probably leave shoulder undefined.

Andrés Díaz Hurtado (Feb 03 2025 at 15:57):

How is this process done, to leave it undefined?

Philip Durbin 🚀 (Feb 03 2025 at 15:59):

You're using domain.xml, right? To leave it undefined you would not include the line about shoulder in domain.xml.

Andrés Díaz Hurtado (Feb 03 2025 at 16:00):

That is, I remove the line ‘Ddataverse.pid.*.shoulder’, from the ‘domain.xml’ file?

Philip Durbin 🚀 (Feb 03 2025 at 16:17):

Yes, please try that. And then restart Payara.

Andrés Díaz Hurtado (Feb 03 2025 at 17:11):

I had a session with a Datacite provider and the only configuration that worked in 'domain.xml' was:

<jvm-options>-Ddataverse.pid.datacite.mds-api-url=https://mds.datacite.org</jvm-options>
<jvm-options>-Ddataverse.pid.datacite. rest-api-url=https://api.datacite.org</jvm-options>
<jvm-options>-Ddatataverse.pid.datacite.username=Test1234</jvm-options>
<jvm-options>-Ddataverse.pid.datacite.password=Test1234</jvm-options>
<jvm-options>-Ddataverse.pid.datacite.shoulder=</jvm-options>

If the shoulder is deleted, it takes a long time to generate the Dataset, for this reason the shoulder was left empty in domain.xml and the creation of the Dataset was instantaneous.

Philip Durbin 🚀 (Feb 03 2025 at 17:13):

Oh! Interesting. Sorry to tell you wrong. This is news to me!

Andrés Díaz Hurtado (Feb 03 2025 at 17:15):

No problem, thank you for your help, and may this solution help other installations.

Philip Durbin 🚀 (Feb 03 2025 at 17:16):

Yes!

Last updated: Oct 30 2025 at 06:21 UTC