--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/a236cf9d-dcb1-467d-b411-9de12533eec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/424b3b66-3ea2-4b3f-9f35-dcab3cbc7059%40googlegroups.com.
Jianliang,
If you see a “tomcat7 working page”, that sounds like a default tomcat7 webapp just to let you verify things are working. If you put the XNAT war in place as ROOT.war, but the default tomcat application is already sitting unpacked in a ROOT directory (all within the webapps folder), tomcat is just going to ignore the war file and continue chugging away with the ROOT directory. So, try clearing out the contents of the webapp directory, and drop the XNAT war in as ROOT.war.
Thanks,
Charlie
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/ac1ecb2a-7a2e-436b-a96f-1013fd5b57dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
Is there anything in the XNAT logs, or in /var/log/tomcat7 ?
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/2a84aebf-1667-4584-8418-7c00f641819b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
A couple things…
Regarding Ralph’s earlier comment about extracting the war file and the naming of that file, Tomcat installs applications at a context corresponding to the name of the war file minus its extension, so if you put the file in there as foo.war, then your XNAT application will be accessible at http://server:8080/foo and xnat.war would be http://server:8080/xnat, etc. This holds with one exception, which is naming the war file ROOT.war, in which case XNAT is available at the root context, i.e. http://server:8080 with no other path. On start-up, if you have only the war file in the webapps folder, Tomcat extracts the contents of that war file into a folder with the same name, so ROOT.war is extracted into ROOT, xnat.war is extracted into xnat, and so on (there’s a setting unpackWARs that dictates how Tomcat unpacks the war file, but Tomcat still extracts the contents of the war file even if this set to false: it just extracts the contents into a work folder instead of directly into the webapps folder).
Regarding Charlie’s comment about Tomcat using the contents of the ROOT folder over the contents of the war file, this is mostly true. Once you’ve deployed a war file and Tomcat has extracted the contents, you can then go into that folder and modify files in there, e.g. change a VM or JS or JSP file, or even replace class or jar files, and those changes will be reflected in the application (resources like VMs and the like will change as soon as you reload a page, but changes to class and jar files that have already been loaded require a restart of Tomcat). However, if you deploy a new war file, Tomcat will extract the contents of that war file and overwrite the corresponding files in the application folder.*
Here's what I think is going on:
When you were initially able to reach http://server:8080, you had XNAT up and running fine. However, http://server goes to port 80 (https://server goes to 443) and wouldn’t reach Tomcat unless you had something like nginx or Apache httpd to handle directing traffic from port 80 or 443 to port 8080. When you then renamed ROOT.war to xnat.war, http://server:8080 no longer worked because XNAT was then running at http://server:8080/xnat.
I’d suggest the following steps:
server {
listen 80;
listen [::]:80 default_server;
server_name server;
location / {
proxy_pass http://localhost:8080;
proxy_redirect http://localhost:8080 $scheme://server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 1200;
proxy_send_timeout 1200;
proxy_read_timeout 1200;
send_timeout 1200;
proxy_buffers 4 32k;
client_max_body_size 0;
client_body_buffer_size 128k;
}
}
Once nginx has started, you should now be able to reach XNAT through the URL http://server.
* Tomcat *may* do a timestamp comparison in this case, so if you’ve updated a VM template in the ROOT folder and not updated it in the new war file, Tomcat *may* not overwrite the version in the folder with the version from the war file. I haven’t tested this, but you do get some weird behavior in this kind of scenario. I know that it will definitely *not* delete files in the ROOT folder that are no longer in the war file, which can also lead to weird behavior. That’s why, whenever I’m deploying a new war file, I always delete the corresponding folder, something along the lines of:
$ systemctl stop tomcat7.service
$ rm -rf /var/lib/tomcat7/webapps/ROOT*
$ cp xnat-web-1.7.5-SNAPSHOT.war /var/lib/tomcat7/webapps/ROOT.war
$ systemctl start tomcat7.service
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
Phone: +1 (314) 273-1645
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/d310745d-813b-4bd2-88ab-9583976e5e8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Presuming you have PostgreSQL running on the same server as XNAT, with a database user named xnat and a database named xnat, then yes that should be fine.
And no, you shouldn’t need to reinstall the pipeline.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/779cfdb4-79ab-4fcf-a40f-15baff97559d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The amount of RAM the VM has doesn’t matter if you don’t have Tomcat’s JVM configured to use it. Have a look here:
https://wiki.xnat.org/display/XNAT17/Configuring+Tomcat+To+Avoid+Errors
The XNAT Vagrant VM setup can be a good place to look for examples of how these things are configured. For example, the file templates/tomcat7.tmpl is the template used to replace the default Tomcat configuration. That includes this:
CATALINA_OPTS="-Xms512m -Xmx1g -XX:+UseConcMarkSweepGC -XX:-OmitStackTraceInFastThrow"
CATALINA_OPTS="${CATALINA_OPTS} -XX:+CMSIncrementalMode -XX:+CMSClassUnloadingEnabled"
CATALINA_OPTS="${CATALINA_OPTS} -Dxnat.home=@XNAT_HOME@"
CATALINA_OPTS="${CATALINA_OPTS} -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000"
I’d suggest allocating at least 4GB of RAM to your VM and 2GB to the Tomcat JVM if you have the 4GB to spare on the host machine.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/8c740fa3-5264-4321-a720-c7a247dd7391%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
XNAT has encountered an error with your request:
If this error continues to occur, please contact your system administrator with information about how to recreate the problem.
Is that still the RAM issue because it has been set?
Best wishes,
Jianliang
I have no idea. 512MB is pretty low, but should probably work. You need to check the Tomcat and XNAT logs to see if there are any error messages there.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/283e417b-102b-4a8a-a5eb-80d93277de63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
proxy_set_header Host &
Try shutting down Tomcat, clearing out your XNAT logs (e.g. rm -f /data/xnat/home/logs/*), then restarting Tomcat. That way any log entries that were created during earlier issues with getting XNAT up won’t be in there to confuse matters.
Once you’ve done that and can’t get any farther accessing your XNAT, grab any logs that have contents (other than access.log and axis.log, which aren’t helpful at all). If you can post those to a gist on github or something similar, that’d be helpful.
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
Phone: +1 (314) 273-1645
From: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com> on behalf of Jianliang Gao <pilla...@gmail.com>
Reply-To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Date: Thursday, November 1, 2018 at 5:15 PM
To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] site not reachable: XNAT installation on Ubuntu VM
Hi Rick,
Tomcat7 didn't have errors.
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/aba282a9-26e1-457c-8c06-b6ad2df8e50a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Something very weird is going on there. That’s trying to initialize the guest user, but the guest user isn’t in the database, which has to mean the database isn’t getting initialized properly since the guest user is inserted in the default initialization script. Try dropping your database and recreating it. The values you use depend on what you have configured in your xnat-conf.properties. If you have the default values like this:
datasource.url=jdbc:postgresql://localhost/xnat
datasource.username=xnat
datasource.password=xnat
Then the commands would
$ dropdb xnat
$ createdb -U xnat xnat
Make sure there are no tables in that database to ensure that XNAT will actually initialize and populate the database. During start-up, you should see this in the Tomcat Catalina.out log:
===========================
New Database -- BEGINNING Initialization
===========================
===========================
Database initialization complete.
===========================
Verify that the guest and admin users were added:
$ psql -c "select login from xdat_user"
login
-------
admin
guest
(2 rows)
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/dbf4008f-9f25-45cc-92c7-b8af0d0bdb74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.