Hi
I've installed OpenREM 1.0 via docker on a Fedora 34 system. The installation appeared to run smoothly without errors and the database and translation commands executed correctly. However, when I point my browser to
http://localhost I get: "The connection was reset". Curl gives a similar error.
Looking at the output of docker-compose ps I have:
>docker-compose ps
Name Command State Ports
--------------------------------------------------------------------------------------------------------------------------------------
openrem /home/app/openrem/entrypoi ... Up 8000/tcp
openrem-broker docker-entrypoint.sh rabbi ... Up 15671/tcp, 15672/tcp, 15691/tcp, 15692/tcp,
25672/tcp, 4369/tcp, 5671/tcp, 5672/tcp
openrem-db docker-entrypoint.sh postgres Up 5432/tcp
openrem-docker-a1126295f53d_worker_1 /home/app/openrem/entrypoi ... Up
openrem-flower /home/app/openrem/entrypoi ... Up 5555/tcp
openrem-nginx nginx -g daemon off; Up 0.0.0.0:80->80/tcp,:::80->80/tcp
openrem-orthanc-1 /docker-entrypoint.sh /tmp ... Restarting
Running docker-compose in daemonless mode I see orthanc reports the following error:
openrem-orthanc-1 | Startup command: Orthanc /tmp/orthanc.json
openrem-orthanc-1 | W1208 12:51:29.556511 main.cpp:1776] Orthanc version: 1.8.2
openrem-orthanc-1 | W1208 12:51:29.556715 OrthancConfiguration.cpp:62] Reading the configuration from: "/tmp/orthanc.json"
openrem-orthanc-1 | W1208 12:51:29.571175 FromDcmtkBridge.cpp:298] Loading external DICOM dictionary: "/usr/share/libdcmtk14/dicom.dic"
openrem-orthanc-1 | W1208 12:51:29.579152 FromDcmtkBridge.cpp:298] Loading external DICOM dictionary: "/usr/share/libdcmtk14/private.dic"
openrem-orthanc-1 | W1208 12:51:29.590960 main.cpp:852] Loading plugin(s) from: /usr/share/orthanc/plugins/
openrem-orthanc-1 | W1208 12:51:29.598452 PluginsManager.cpp:269] Registering plugin 'gdcm' (version 1.2)
openrem-orthanc-1 | W1208 12:51:29.598604 PluginsManager.cpp:168] Orthanc will use GDCM to decode transfer syntax: 1.2.840.10008.1.2.4.90
openrem-orthanc-1 | W1208 12:51:29.598616 PluginsManager.cpp:168] Orthanc will use GDCM to decode transfer syntax: 1.2.840.10008.1.2.4.91
openrem-orthanc-1 | W1208 12:51:29.598622 PluginsManager.cpp:168] Orthanc will use GDCM to decode transfer syntax: 1.2.840.10008.1.2.4.92
openrem-orthanc-1 | W1208 12:51:29.598636 PluginsManager.cpp:168] Orthanc will use GDCM to decode transfer syntax: 1.2.840.10008.1.2.4.93
openrem-orthanc-1 | W1208 12:51:29.598645 PluginsManager.cpp:168] Throttling GDCM to 4 concurrent thread(s)
openrem-orthanc-1 | W1208 12:51:29.598658 PluginsManager.cpp:168] Version of GDCM: 3.0.8
openrem-orthanc-1 | W1208 12:51:29.598692 OrthancInitialization.cpp:329] SQLite index directory: "/var/lib/orthanc/db"
openrem-orthanc-1 | W1208 12:51:29.598811 OrthancInitialization.cpp:406] Storage directory: "/var/lib/orthanc/db"
openrem-orthanc-1 | W1208 12:51:29.599297 HttpClient.cpp:1125] HTTPS will use the CA certificates from this file: /etc/ssl/certs/ca-certificates.crt
openrem-orthanc-1 | W1208 12:51:29.599750 LuaContext.cpp:93] Lua says: Lua toolbox installed
openrem-orthanc-1 | E1208 12:51:29.599961 OrthancException.cpp:57] The specified path does not point to a regular file: The path does not point to a regular file: /etc/share/orthanc/scripts/openrem_orthanc_config_docker.lua
openrem-orthanc-1 | E1208 12:51:29.600051 ServerIndex.cpp:706] INTERNAL ERROR: ServerIndex::Stop() should be invoked manually to avoid mess in the destruction order!
openrem-orthanc-1 | W1208 12:51:30.100009 PluginsManager.cpp:219] Unregistering plugin 'gdcm' (version 1.2)
openrem-orthanc-1 | E1208 12:51:30.103839 main.cpp:1833] Uncaught exception, stopping now: [The specified path does not point to a regular file] (code 2006)
openrem-orthanc-1 | W1208 12:51:30.103886 main.cpp:1864] Orthanc has stopped
I've searched the docker containers and the openrem_orthanc_config_docker.lua was definitely not copied over.
I've also tried the docker Wordpress example and that is running correctly and can be accessed from a browser.
I've also tried this OpenREM installation on a Fedora CoreOS 35 virtual machine with the same results.
I'm not sure if this is a bug or something unique to Fedora but I can list it on bitbucket if you wish.
Regards
Alan