I appreciate that as yet, Orthanc doesn’t support Ubuntu 18 and wondered if this would be looked at any time soon?
I’ve recently posted a script that takes the compiled binaries and installs them onto U14 and U16 so that one doesn’t have to compile everything. With the 1.5.7 version now released, I’ve tested that again but it fails with a “segmentation fault”
So I compiled my own version, using -DSTATIC_BUILD=ON and I get the exact same result. Considering I’m not a developer, maybe I’m doing something right for once!
However, when I take the compiled binaries (same as those listed {http://lsb.orthanc-server.com/orthanc/1.5.7}} and move them to another server and try installing them without compilation, I start getting missing library files (jsoncpp, libboost_filesystem) etc. I guess that’s to be expected as (my limited understanding being) when you assign a STATIC_BUILD, all those extra libraries are included in the compiled binaries, which makes them portable.
So - is there any movement anywhere to get those statically linked libraries working on Ubuntu 18? I don’t even mind installing additional libraries if that would help (the jsoncpp can be installed with “apt-get install libjsoncpp1” but I didn’t go through all the lists as I wondered if there was a “better” way of doing things?
Sorry, since my machine is a dev machine, it had a few package installed already that made it work…
I’ll try to isolate the minimum packages to install
I really appreciate the feedback here and I believe that I’ve found a bug in 1.5.7 related to setting the server’s environment to UTC… The following was tested on an Ubuntu 18.04.2 VM (which is configured, by default, to UTC) without anything more than LAMP installed (ie, it would appear that lsb-core and locales isn’t required but I’ve tested with these installed as well and the results are the same). Using my original script (updated to use the 1.5.7 binaries)
Orthanc starts without any issues at all (champagne corks are heard popping in Southern California)1. Ctrl + C (Orthanc shuts down)
ln -fs /usr/share/zoneinfo/UTC /etc/localtime
dpkg-reconfigure -f noninteractive tzdata
./Orthanc ./orthanc.json --verbose
Segmentation fault (core dumped)
So it appears if the server is set to UTC, Orthanc has a problem? Would you be able to double-check this please? I can change to (seemingly) any timezone (including London, Brussels etc) and Orthanc starts up just fine, but when it’s set to UTC that’s when the fault appears.
Sebastien,
I installed tzdata and the problem persists. I also check that /etc/localtime exists, which it does.
The segmentation fault exists with any “Etc/” timezone (Greenwich, UCT, UTC, Universal and Zulu). At this point I created a snapshot of the VM (“BinaryInstall”).
I then set my VM back to the snapshot prior to BinaryInstall, and built Orthanc, created the crash.so file as per the backtrace page, and then placed it on my host. I also snapshot at this point called “Build”.
I then set my VM back to the BinaryInstall snapshot and copied crash.so from my host to the VMs /usr/share/orthanc/plugins/ folder. Starting up Orthanc in the same manner ("Orthanc /etc/orthanc --verbose) I see that it registered the plugin ‘crash’ and dumped the core.
Question is: where’s the core file that it creates? I performed a “find / -name core -print” on the VM and it came up with a bunch of results:
/proc/sys/net/core
/dev/core
/snap/core
/snap/core/6350/dev/core
/snap/core/6350/var/lib/initramfs-tools/core
/snap/core/7270/dev/core
/snap/core/7270/var/lib/initramfs-tools/core
/var/snap/core
/lib/modules/4.15.0-54-generic/kernel/net/core
/lib/modules/4.15.0-54-generic/kernel/drivers/mmc/core
/lib/modules/4.15.0-54-generic/kernel/drivers/memstick/core
/lib/modules/4.15.0-54-generic/kernel/drivers/net/ethernet/mellanox/mlx5/core
/lib/modules/4.15.0-54-generic/kernel/drivers/infiniband/core
/lib/modules/4.15.0-54-generic/kernel/drivers/video/fbdev/core
/lib/modules/4.15.0-54-generic/kernel/drivers/gpu/drm/tinydrm/core
/lib/modules/4.15.0-54-generic/kernel/drivers/usb/core
/lib/modules/4.15.0-54-generic/kernel/sound/core
/usr/src/linux-headers-4.15.0-54/net/core
/usr/src/linux-headers-4.15.0-54/drivers/mmc/core
/usr/src/linux-headers-4.15.0-54/drivers/memstick/core
/usr/src/linux-headers-4.15.0-54/drivers/net/ethernet/mellanox/mlx5/core
/usr/src/linux-headers-4.15.0-54/drivers/infiniband/core
/usr/src/linux-headers-4.15.0-54/drivers/video/fbdev/core
/usr/src/linux-headers-4.15.0-54/drivers/gpu/drm/tinydrm/core
/usr/src/linux-headers-4.15.0-54/drivers/gpu/drm/nouveau/nvkm/core
/usr/src/linux-headers-4.15.0-54/drivers/usb/core
/usr/src/linux-headers-4.15.0-54/sound/aoa/core
/usr/src/linux-headers-4.15.0-54/sound/core
/usr/src/linux-headers-4.15.0-54-generic/include/config/mlx5/core
/usr/src/linux-headers-4.15.0-54-generic/include/config/mlxsw/core
/usr/src/linux-headers-4.15.0-54-generic/include/config/mlx4/core
/usr/src/linux-headers-4.15.0-54-generic/include/config/serial/core
/usr/src/linux-headers-4.15.0-54-generic/include/config/core
I was under the impression that the core file is created in the current working directory, (which is /home/dave) but that file didn’t exist, so I then went and installed lsb-core as perhaps that’s why I didn’t get the file I was looking for, in the folder I was expecting, but even after that, the file didn’t exist (and a “find” produced the same results as before I installed lsb-core). I also went back to the build instructions and installed all of the required packages in order to build Orthanc … and afterwards, the additional core files found were those related to boost:
Sebastien,
Yes, thank you so much sir! Using the mainline versions, all /Etc timezones certainly appear to be working, no segmentation fault at startup.
Can I ask at this point - mainline is the “cutting edge” version, whereas 1.5.7 is the current “release” version, is that correct? If so, it would be fair to say that the latest “release” version should be used unless an issue is experienced, which may already be addressed in the “mainline” version, is that correct?
Kindest regards, and thank you for being patient with me!
Can I ask at this point - mainline is the “cutting edge” version, whereas 1.5.7 is the current “release” version, is that correct?
Yes, this is correct. The “mainline” is where Orthanc core developers make their modifications.
If so, it would be fair to say that the latest “release” version should be used unless an issue is experienced, which may already be addressed in the “mainline” version, is that correct?
Yes, official releases should always be used, especially in production environments. The “mainline” version is unstable (it might change on a hourly basis, possibly introducing transient incompatibilities/issues), and no systematic quality control is achieved (contrarily to official releases).
For the record, I do confirm that these are now the minimal steps to install Orthanc LSB on ubuntu18:
FROM ubuntu:18.10
RUN apt-get update
RUN apt-get -y install locales
RUN apt-get -y install wget
RUN export DEBIAN_FRONTEND=noninteractive && apt-get -y install tzdata
RUN locale-gen en_US en_US.UTF-8