The TCP port of the HTTP server is privileged or already in use: (port = 8042)

[Axel Braun]

Hi,

I found this thread https://groups.google.com/g/orthanc-users/c/ZUUECc9AzaU/m/JNg1q4-CAAAJ?pli=1 reporting a problem that the tcp port is reported to be in use when running SSL and a reverse proxy

We actually hit the same problem now, and could not find a solution so far.

Please find the log at

https://paste.opensuse.org/93369438

Config files attached.

Any hit is welcome!

Cheers

Axel

[Sébastien Jodogne]

Dear Axel,

I have started Orthanc with your configuration files, on my Ubuntu 20.04 box, both by compiling from sources and by using the precompiled LSB binaries, and everything works fine:

$ curl https://localhost:8042/system -u alice:bob --cacert /tmp/i/etc/orthanc/orthanc-appl-selfsigned.crt
{
   "ApiVersion" : 16,
   "CheckRevisions" : false,
   "DatabaseBackendPlugin" : null,
   "DatabaseVersion" : 6,
   "DicomAet" : "ORTHANC",
   "DicomPort" : 4242,
   "HttpPort" : 8042,
   "IsHttpServerSecure" : true,
   "Name" : "MyOrthanc",
   "PluginsEnabled" : true,
   "StorageAreaPlugin" : null,
   "Version" : "1.10.1"
}

The error "The TCP port of the HTTP server is privileged or already in use" generally means that two different instances of Orthanc are running at the same time.

Kind Regards,

Sébastien-

[Axel Braun]

Hi Sebastien,

thanks for your quick reaction, which leaves me a bit baffled.

I upgraded to the latest Orthanc version on a plain Leap 15.3 system with all patches apllied

I started Orthanc manually:

/usr/sbin/orthanc --verbose --trace-http --logfile=http_orthanc.log /etc/orthanc/  

-> See log attached. Orthanc uses the internal CivetWeb Server. May this be the issue?

There is no other process listening on that port:

localhost:/home/test # ss -tulpen
Netid         State          Recv-Q         Send-Q                  Local Address:Port                    Peer Address:Port                                                                                                                                            
udp           UNCONN         0              0                             0.0.0.0:38788                        0.0.0.0:*             users:(("avahi-daemon",pid=1052,fd=13)) uid:468 ino:21743 sk:1 <->                                                                
udp           UNCONN         0              0                        0.0.0.0%eth0:68                           0.0.0.0:*             users:(("wickedd-dhcp4",pid=1173,fd=8)) ino:23602 sk:2 <->                                                                        
udp           UNCONN         0              0                             0.0.0.0:5353                         0.0.0.0:*             users:(("avahi-daemon",pid=1052,fd=11)) uid:468 ino:21741 sk:3 <->                                                                
udp           UNCONN         0              0                           127.0.0.1:323                          0.0.0.0:*             users:(("chronyd",pid=1720,fd=5)) ino:24673 sk:4 <->                                                                              
udp           UNCONN         0              0                                [::]:57528                           [::]:*             users:(("avahi-daemon",pid=1052,fd=14)) uid:468 ino:21744 sk:5 v6only:1 <->                                                        
udp           UNCONN         0              0                                [::]:5353                            [::]:*             users:(("avahi-daemon",pid=1052,fd=12)) uid:468 ino:21742 sk:6 v6only:1 <->                                                        
udp           UNCONN         0              0                               [::1]:323                             [::]:*             users:(("chronyd",pid=1720,fd=6)) ino:24674 sk:7 v6only:1 <->                                                                      
tcp           LISTEN         0              5                           127.0.0.1:631                          0.0.0.0:*             users:(("cupsd",pid=1053,fd=7)) ino:22035 sk:8 <->                                                                                
tcp           LISTEN         0              100                         127.0.0.1:25                           0.0.0.0:*             users:(("master",pid=1873,fd=13)) ino:26138 sk:9 <->                                                                              
tcp           LISTEN         0              128                                 *:80                                 *:*             users:(("httpd-prefork",pid=1787,fd=4),("httpd-prefork",pid=1786,fd=4),("httpd-prefork",pid=1785,fd=4),("httpd-prefork",pid=1784,fd=4),("httpd-prefork",pid=1783,fd=4),("httpd-prefork",pid=1753,fd=4)) ino:25432 sk:a v6only:0 <->
tcp           LISTEN         0              5                               [::1]:631                             [::]:*             users:(("cupsd",pid=1053,fd=6)) ino:22034 sk:b v6only:1 <->                                                                        
tcp           LISTEN         0              100                             [::1]:25                              [::]:*             users:(("master",pid=1873,fd=14)) ino:26139 sk:c v6only:1 <->                                                                      
tcp           LISTEN         0              128                                 *:443                                *:*             users:(("httpd-prefork",pid=1787,fd=6),("httpd-prefork",pid=1786,fd=6),("httpd-prefork",pid=1785,fd=6),("httpd-prefork",pid=1784,fd=6),("httpd-prefork",pid=1783,fd=6),("httpd-prefork",pid=1753,fd=6)) ino:25435 sk:d v6only:0 <->

Any hint how to proceed?

Thanks

Axel

[Axel Braun]

PS: Build parameter:

%cmake    ../OrthancServer \
    -DSTANDALONE_BUILD:BOOL=ON \
    -DSTATIC_BUILD:BOOL=OFF \
    -DENABLE_CIVETWEB=ON \
    -DORTHANC_UNIT_TESTS_LINK_FRAMEWORK=OFF \
    -DUSE_SYSTEM_MONGOOSE=OFF \
    -DSYSTEM_MONGOOSE_USE_CALLBACKS=OFF \
    -DUNIT_TESTS_WITH_HTTP_CONNEXIONS=OFF \
    -DBoost_NO_BOOST_CMAKE=ON

Build log:

https://build.opensuse.org/package/live_build_log/home:DocB:Orthanc/orthanc/openSUSE_Leap_15.3/x86_64

[Sébastien Jodogne]

Hello Axel,

As far as I'm concerned, I am unable to provide any help on this distribution-specific issue...

Maybe you could provide full instructions on how to reproduce this issue using Docker so that we could have a look.

Sorry,

Sébastien-

[Axel Braun]

Hi Sebastien,

I see....maybe you can pull a VM from https://www.osboxes.org/ and try with that?

Thanks

Axel

[Benjamin Golinvaux]

I do not want to sound flippant, but I believe that Sébastien suggested that you create a docker image that reproduces your issue, so that he may execute it and investigate if required.

If you cannot reproduce your issue in a new Dockerfile, it problably means that there is something specific with your setup (yes, I'm the real Captain Obvious).

[Axel Braun]

Hi Benjamin,

that was well understood, I just tried to find a workaround that may help in the short run, as I'm not too familiar with Docker.

In between there is some more light in the dark. openSUSE provides libcrypto.so.<major> , but Orthanc calls libcrypto.so

If I install libopenssl-devel, it works in https-mode as well.

Is Debian creating a symlink to libcrypto.so? Should Orthanc not call libcrypto.so.<major>?

Cheers

Axel

[Sébastien Jodogne]

Hello,

Here is how libcrypto is configured on Debian-derivatives:

sjodogne@localhost:/usr/lib/x86_64-linux-gnu$ ls -l libcrypto*
-rw-r--r-- 1 root root 5541876 mar  9 13:12 libcrypto.a
lrwxrwxrwx 1 root root      16 mar  9 13:12 libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2366112 jui 13  2021 libcrypto.so.1.0.0
-rw-r--r-- 1 root root 2954080 mar  9 13:12 libcrypto.so.1.1

CMake should automatically detect the correct library for your distribution. Have a talk with the openSUSE packaging team, I really cannot speak on their behalf.

Sébastien-

[Axel Braun]

Hi Sebastien,

s.jo...@gmail.com schrieb am Montag, 2. Mai 2022 um 10:45:07 UTC+2:

Here is how libcrypto is configured on Debian-derivatives:

sjodogne@localhost:/usr/lib/x86_64-linux-gnu$ ls -l libcrypto*
-rw-r--r-- 1 root root 5541876 mar  9 13:12 libcrypto.a
lrwxrwxrwx 1 root root      16 mar  9 13:12 libcrypto.so -> libcrypto.so.1.1
-rw-r--r-- 1 root root 2366112 jui 13  2021 libcrypto.so.1.0.0
-rw-r--r-- 1 root root 2954080 mar  9 13:12 libcrypto.so.1.1

CMake should automatically detect the correct library for your distribution. Have a talk with the openSUSE packaging team, I really cannot speak on their behalf.

And this is how it comes on openSUSE :

localhost:/etc/orthanc # dir /usr/lib64/libcry*
-rwxr-xr-x 1 root root 3032128 Mar 11 09:39 /usr/lib64/libcrypto.so.1.1
lrwxrwxrwx 1 root root      23 Jan 17 13:47 /usr/lib64/libcryptsetup.so.12 -> libcryptsetup.so.12.6.0
-rwxr-xr-x 1 root root  484992 Jan 17 13:47 /usr/lib64/libcryptsetup.so.12.6.0
lrwxrwxrwx 1 root root      17 Mar 11 10:20 /usr/lib64/libcrypt.so.1 -> libcrypt.so.1.1.0
-rwxr-xr-x 1 root root  202744 Mar 11 10:20 /usr/lib64/libcrypt.so.1.1.0

The point is not CMake . it detects the correct libversion during build, but there is no link created automatically by the libopenssl package. 

BTW, here is the link to the bug report:

https://bugzilla.opensuse.org/show_bug.cgi?id=1199047 - maybe you experts discuss this :-)

Cheers

Axel

[Sébastien Jodogne]

Hi Axel,

On Monday, May 2, 2022 at 4:22:58 PM UTC+2 coogor...@gmail.com wrote:

The point is not CMake . it detects the correct libversion during build, but there is no link created automatically by the libopenssl package. 

BTW, here is the link to the bug report:

https://bugzilla.opensuse.org/show_bug.cgi?id=1199047 - maybe you experts discuss this :-) 

Sorry, I have no expertise about this.

I will happily welcome any patch needed upstream, but I don't know what is to be fixed here. I highly doubt that this is an issue related to the dynamic linking of OpenSSL, otherwise Orthanc would simply not run at all.

Sébastien-

[Axel Braun]

Is the libopenssl-devel package a requirement to run orthanc? or does the libopenssl package itself create the symlink in Debian?

[Axel Braun]

Good news...the solution was found....in the civetweb-package!

[Sébastien Jodogne]

This is great news, thanks for your investigation!

If I correctly understand this bug report, civetweb was compiled without support for SSL in openSUSE:

https://bugzilla.opensuse.org/show_bug.cgi?id=1199047#c5

Sébastien-

[Axel Braun]

Hi Sebastien,

s.jo...@gmail.com schrieb am Donnerstag, 5. Mai 2022 um 17:14:24 UTC+2:

This is great news, thanks for your investigation!

If I correctly understand this bug report, civetweb was compiled without support for SSL in openSUSE:

https://bugzilla.opensuse.org/show_bug.cgi?id=1199047#c5

Not correct - it was expecting a libcrypto.so as a placeholder for the linked library. But if you have various versions of a lib installed, which is the right one, that links to libcrypto.so?

We used the compiler option to link this static. I think this is safe, as any change of an underlying package triggers a rebuild of the target in Open Build Service, so consistency is ensured. IMO better than installing the libopenssl-devel package, which would have been the other solution.

Thanks for your support!

Axel