Installing CVB in Docker

Hello

We want to be able to distribute our app using docker. Has anyone been successful in this?

We experience problems getting the debian package installed without errors (the errors are related to run-level determination) after installation we can compile and link against the cvb library but we cannot run the program as it fails.

Unpacking codemeter (5.22.1504.500) ...
Setting up codemeter (5.22.1504.500) ...
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of start.
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu21.4) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Selecting previously unselected package cvb-foundation-dev.
(Reading database ... 112023 files and directories currently installed.)
Preparing to unpack .../cvb-foundation-dev-13.01.003-ubu1604-x86_64.deb ...
Unpacking cvb-foundation-dev (13.01.003) ...
Selecting previously unselected package cvb-tools-dev.
Preparing to unpack .../cvb-tools-dev-13.01.003-ubu1604-x86_64.deb ...
Unpacking cvb-tools-dev (13.01.003) ...
Selecting previously unselected package cvb-camerasuite.
Preparing to unpack .../cvb-camerasuite-13.01.003-ubu1604-x86_64.deb ...
Unpacking cvb-camerasuite (13.01.003) ...
Selecting previously unselected package cvb-foundation.
Preparing to unpack .../cvb-foundation-13.01.003-ubu1604-x86_64.deb ...
Unpacking cvb-foundation (13.01.003) ...
Selecting previously unselected package cvb-camerasuite-dev.
Preparing to unpack .../cvb-camerasuite-dev-13.01.003-ubu1604-x86_64.deb ...
Unpacking cvb-camerasuite-dev (13.01.003) ...
Selecting previously unselected package cvb-tools.
Preparing to unpack .../cvb-tools-13.01.003-ubu1604-x86_64.deb ...
Unpacking cvb-tools (13.01.003) ...
Setting up cvb-camerasuite (13.01.003) ...
Setting CVB services up...
Failed to retrieve/decode the log configuration for module GEVSVC: Failed to connect to the shared memory with connection info: No such file or directory

*****************************************************************
                  (c) 2015 STEMMER IMAGING GmbH
*****************************************************************

STEMMER IMAGING Logging Service Application 
BuildDate : 	Feb 28 2018


Enter service
Setting up cvb-foundation (13.01.003) ...
Setting up cvb-camerasuite-dev (13.01.003) ...
Setting up cvb-tools (13.01.003) ...
Setting up cvb-foundation-dev (13.01.003) ...
Setting up cvb-tools-dev (13.01.003) ...

@mla, sorry for replying that late, but codemeter and :cvb: setups are not intended for Docker installation. The errors you see come from trying to register the necessary daemons. To be able to install the packages you need to split the installation and get rid of the postinst script (and then do some of the work later).

Install

> dpkg --unpack path/to/codemeter*.deb
> rm /var/lib/dpkg/info/codemeter.postinst
> dpkg --configure codemeter
> dpkg --unpack path/to/cvb-camerasuite-13.01*.deb
> rm /var/lib/dpkg/info/cvb-camerasuite.postinst
> dpkg --configure cvb-camerasuite
> ldconfig

and starting with version 13.01.004

> ln -s `find /opt/ -name cvb-*` /opt/cvb

The other packages can be installed normally via dpkg -I.

Start

For the following start-up script I assume that you want to use a GigE Vision cameras with CameraSuite licensing only.

Before you start your app in the container you need to start at least two services manually and source some environment variables. The most direct way would be a start script in your image which is run in the container:

/opt/cvb/bin/cvmgmtd
/opt/cvb/bin/siGevSvc -s
. /etc/profile.d/cvb_environment.sh

After that you can start your app.

Also, if you want to persist settings you need to map the following directories outside the container:

  • /etc/opt/cvb
  • /var/opt/cvb
2 Likes

Thank you for your reply, i got it working inside docker, but i am unable to get rid of the watermark.

my startup script

/opt/cvb/bin/siLogSvc -s
/opt/cvb/bin/cvmgmtd
/opt/cvb/bin/siGevSvc -s
. /etc/profile.d/cvb_environment.sh

i have added the license key to /opt/cvb/camerasuite.lic but it does not seem to work.

best regards
Morten Larsen

First the file should be located under:

/var/opt/cvb/camerasuite.lic

Did you write the camerasuite.lic inside the image? Do the keys inside this file work outside the container?

I would recommend to put that file outside of the image and mount it there (or mount it somewhere else and adjust the $CVBDATA environment variable pointing to that location. Also other information will be saved there which you might want to persist.

Thank you for your quick reply and assistance.

I am running cvb version 13.01.003

i am mounting

"-v /etc/opt/cvb:/etc/opt/cvb"
"-v /var/opt/cvb:/var/opt/cvb"

the /etc/opt/cvb on the host machine contains the driver

cat /etc/opt/cvb/drivers/GenICam.ini 
;utf8
[SYSTEM]
NumCameras=1
CreateAutoIni=0
AutoSwitchEnable=0
DeviceUpdateTimeout=-1
AutoConfigExecuted=1
[Channel_0]
TLType=GEV
TL=/opt/cvb/drivers/genicam/libGevTL.cti.1.1800.26
Interface=SD::MAC->correct mac for this host
Device=::ID->redacted::192.168.19.2
NumBuffer=30
PacketSize=8192
InterPacketDelay=-1
PixelFormat=5
RotateImage=0
AccessMode=4
Vendor=Allied Vision Technologies
Model=Mako G-507B (9616)
UserName=
SerialNumber=redacted by me
PacketResend=1
HeartbeatTimeout=-1
HeartbeatTimeoutMargin=-1
MCMasterMode=0
MCSession=0
MCNoJoin=0
UseTurboDrive=0
NumConvertThreads=1
AttachChunk=0

ls /var/opt/cvb/

camerasuite.lic  genicam  GenICamBrowser.xml  log  Registry

I copied the driver from a working system and changed the mac address to match the new host. Then i copied the camerasuite.lic file where i found it in the old system (on that it was located in /opt/cvb/camerasuite.lic) i did also copy the complete contents of /var/opt/cvb to the new machine, perhaps this is the problem?

Nevermind

Turns out you have to disable the firewall completely on the host system

systemctl firewalld stop

for the watermark to disappear, can you confirm this? the new host system is centos7 btw.

Hi there!

when working with a CameraSuite license, this behaviour would in fact make sense because the license validity check relies on being able to every now and then talk to the camera. If a firewall prevents this, this would in fact be interpreted as “camera is not there” in which case the CameraSuite license is inactive.

Hello, I am trying to get a Teledyne-DALSA-Linea-GigE camera working inside Docker using CVBpy. I followed the steps described above, and now I can connect to the camera from within Docker.

However, when I start a stream and wait for images (stream.wait_for(…) ), I never receive an image and a time-out occurs. Exactly the same script runs fine in windows. Does someone has any clue what it could be?

Hi @patryk105,

this sound again like either a firewall or routing problem. GEV uses a standardized port for its control protocol. And statefull firewalls can hande a request answer which originated inside of its system. For streaming, though, the camera starts the connection to the dynamically assigned port in your app (it is done automatically).

Thus your system must be able to connect to on any port above 1024 from the outside.

Hi all,

I am also facing the same issue and am not able to fix it even by following the above instructions.

My Dockerfile is based on the instructions given by @parsd:

FROM ubuntu:16.04

RUN apt update && apt install -y unzip multiarch-support libfontconfig1 libfreetype6 libice6 libsm6 libx11-6 libxcb1

COPY cvb.zip /install/cvb.zip

WORKDIR /install
RUN unzip /install/cvb.zip

RUN dpkg --unpack codemeter*.deb && rm /var/lib/dpkg/info/codemeter.postinst && dpkg --configure codemeter
RUN dpkg --unpack cvb-camerasuite-13*.deb && rm /var/lib/dpkg/info/cvb-camerasuite.postinst && dpkg --configure cvb-camerasuite
RUN ldconfig

RUN find /opt/ -name 'cvb-*' -exec ln -s '{}' /opt/cvb ';'

I then start up a container with this image and run the commands

/opt/cvb/bin/cvmgmtd
/opt/cvb/bin/siGevSvc -s
. /etc/profile.d/cvb_environment.sh

However, the siGevSvc command still throws the error

Failed to retrieve/decode the log configuration for module GEVSVC: Failed to connect to the shared memory with connection info: No such file or directory

Running a Python script also throws a bunch of similar errors of failed log configurations for various other modules. The same script works fine on the host.

Any ideas what could be wrong or what I missed? I’m running this on a Ubuntu 18.04 host and I’ve tried both Ubuntu 16.04 and 18.04 images with corresponding CVB versions (13.02.002). Many thanks!

UPDATE

It actually seems that first starting the logging service as @mla did helps to remove the error I encountered, however I still get the following error when running a Python script:

Traceback (most recent call last):
  File "test.py", line 7, in <module>
    with cvb.DeviceFactory.open(os.path.join(cvb.install_path(), "drivers", "GenICam.vin"), port=0) as device:
RuntimeError: {C-API call failed} ({LoadImageFile})

When compiling and executing the provided example at tutorial/ImageManager/GrabConsoleExample I also get the following error:

Error loading /opt/cvb/drivers/GenICam.vin driver!

When looking at what processes are running on idle, it looks like cvmgmtd is taking 100 % of the CPU for a long time. UPDATE: Running /usr/sbin/CodeMeterLin before the startup scripts seemed to fix the CPU issue, however the other errors still persist.

1 Like

Hi @wedjati,

first, thank you for your evaluation work. The “Failed to retrieve/decode the log config” message is just a warning. You can also ignore that. It simply states that no logging will be done.

Second, regarding the acquisition part:

  1. Can you ping you device from within the docker container?
  2. How did you configure your GenICam.ini?
    If you use the GrabConsoleExample, then you need to have a configuration before starting the app. You can create one via the GenICamBrowser. Every system needs its own config. It is not portable.

As an alternative you can use the discovery API, to query devices at runtime. This opens the first device it finds:

auto interfaceInfoList = Cvb::DeviceFactory::Discover();
if (interfaceInfoList.empty())
  return;
auto camera = Cvb::DeviceFactory::Open(interfaceInfoList[0].AccessToken());

or with Python:

FLAGS = cvb.DiscoverFlags.IgnoreGevSD | cvb.DiscoverFlags.IgnoreVins
discover = cvb.DeviceFactory.discover_from_root(FLAGS)
if len(discover) > 0:
    device = cvb.DeviceFactory.open(discover[0].access_token)
    # continue using the device

Hi @parsd

Many thanks for the reply. I am able to ping the device both from the host and from inside the container. Actually I had forgot about configuring the GenICam.ini file, however I am planning on using the discovery API going on, so the example you supplied matches my use case. After changing the base image to python:3.6.9-buster I ran the Python script you provided and was still unable to get it to work. However, setting --net=host when running the Docker container seemed to fix things, I can now discover and open devices. Are there any ports that should be open for the container to be able to receive discovery messages from devices? I would guess that could be the problem.

I am still getting a lot of warning messages though, when discovering devices

Failed to retrieve/decode the log configuration for module DriverDLO: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module BaseDLO: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module CVFactory: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVSD: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module UAL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module UAL: Failed to connect to the shared memory with connection info: No such file or directory

When opening a device:

Failed to retrieve/decode the log configuration for module GCVIN: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module CVFactory: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module USBTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVTL: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GEVSD: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module CVRegistry: Failed to connect to the shared memory with connection info: No such file or directory
Failed to retrieve/decode the log configuration for module GenApiDLO: Failed to connect to the shared memory with connection info: No such file or directory

And when closing a device:

Failed to retrieve/decode the log configuration for module CVCImgDLO: Failed to connect to the shared memory with connection info: No such file or directory

Are these significant? Do these mean that logs aren’t being produced? I don’t get them when running the script from the host.

Thanks for the support!

Hi @wedjati,

These messages are an indication that the :cvb: log service doesn’t seem to be up and running. The service executable is ${CVB}/bin/siLogSvc - if that is running it opens a small block of shared memory to initiate loopback communication with those modules that are capable of generating log output. If that shared memory block cannot be opened by those modules they output these warnings on stderr.

Not having the log service running shouldn’t cause issues during runtime, but as you already deduced it won’t be possible to extract log output from the containerized :cvb: installation.

1 Like

Hi there,

thanks to this thread I have been mostly able to move our application to Docker! However, I am still facing some issues with the CameraSuite License. I am running Ubuntu 18.04 on the host and my Dockerfile looks like this:

FROM ubuntu:18.04

RUN apt-get update -y \
  && apt-get install -y wget bash unzip python3 python3-pip \
  usbutils libsm6 libxext6 libxrender-dev lsb-release multiarch-support libfreetype6 libfontconfig1

RUN mkdir -p /usr/src/app \
  && mkdir -p /tmp/cvb

COPY ./ /usr/src/app

RUN mv /usr/src/app/cvb-13.02.002-ubu1804-x86_64.zip /tmp/cvb/cvb-13.02.002-ubu1804-x86_64.zip

RUN cd /tmp/cvb \
  && unzip cvb-13.02.002-ubu1804-x86_64.zip \
  && dpkg --unpack codemeter_6.81.3477.500_amd64.deb \
  && rm /var/lib/dpkg/info/codemeter.postinst \
  && dpkg --configure codemeter \
  && dpkg --unpack cvb-camerasuite-13.02.002-ubu1804-x86_64.deb \
  && rm /var/lib/dpkg/info/cvb-camerasuite.postinst \
  && dpkg --configure cvb-camerasuite \
  && dpkg --unpack cvb-camerasuite-dev-13.02.002-ubu1804-x86_64.deb \
  && dpkg --configure cvb-camerasuite-dev \
  && ldconfig \
  && ln -s /opt/cvb-13.02.002/ /opt/cvb  \
  && dpkg -I cvb-foundation-13.02.002-ubu1804-x86_64.deb \
  && dpkg -I cvb-foundation-dev-13.02.002-ubu1804-x86_64.deb \
  && dpkg -I cvb-tools-13.02.002-ubu1804-x86_64.deb \
  && dpkg -I cvb-tools-dev-13.02.002-ubu1804-x86_64.deb

WORKDIR /usr/src/app

RUN pip3 install -r requirements.txt

EXPOSE 8080

ENV PYTHONPATH="$PYTHONPATH:/usr/src/app"

CMD /opt/cvb-13.02.002/bin/siLogSvc -s \
  && /opt/cvb-13.02.002/bin/cvmgmtd \
  && /opt/cvb-13.02.002/bin/siGevSvc -s \
  && . /etc/profile.d/cvb_environment.sh \
  && python3 -m camera_manager

I have generated a camerasuite.lic file on the host system and mapped it to /opt/cvb-13.02.002/camerasuite.lic as well as /var/opt/cvb/camerasuite.lic. The license works on the host system, but within the Docker image I still get a watermark on my images.

I’d be very thankful for any help regarding this issue!

Hi and welcom @mpouls,

that file looks pretty good to me. :heart:

This is more of a hunch as we have seen problems with the Codemeter API in the way we use it. Thus if Codemeter is installed and the daemon is not running it sometimes results busy hangs.

So one thing you can try if you are only using CameraSuite licenses is not to install CodeMeter at all. But here the dpkg dependency management could be an obstacle. The other thing is that you start the Codemeter daemon also in your last CMD sequence before the cvmgmtd:

CMD /opt/cvb-13.02.002/bin/siLogSvc -s \
  && start-stop-daemon --start --quiet --exec /usr/sbin/CodeMeterLin
  && /opt/cvb-13.02.002/bin/cvmgmtd \
  && /opt/cvb-13.02.002/bin/siGevSvc -s \
  && . /etc/profile.d/cvb_environment.sh \
  && python3 -m camera_manager

Maybe you need to add --user daemon to the start-stop-daemon line. This is how CodeMeter starts their daemon. It might also be enough to just execute /usr/sbin/CodeMeterLin.

Thanks to @c.hartmann for looking up the Codemeter init scripts :+1:

Thanks a lot for taking the time and having a look at my problem!

I already suspected that there might be an issue with Codemeter within the Docker container and therefore already tried to start /usr/sbin/CodeMeterLin manually within the container. Unfortunately neither that nor running the codemeter daemon via start-stop-daemon fixed the issue :slightly_frowning_face:

Do you have any other ideas what the problem might be? Is there anything else I need to do in order to activate the license besides mapping the camerasuite.lic file (containing the license key) into the docker container? I am currently at a loss where to look next…

For now, we can just continue to run the application on the host. So this is not a super urgent issue for us, it’s just more convenient to have all our applications dockerized :+1:

Thanks again for your great support :slightly_smiling_face:

Before we go deeper into the investigation I just want to make sure we don’t run in a license race condition. The daemons fork and then start in parallel to your app. Can you try the cvb.wait_for_license(time_span_in_ms) function in your __main__?

Thanks for the suggestion :+1:

Unfortunately, we were not using the cvb-Python-API directly, but rather the Genicam-Driver via harvesters (https://github.com/genicam/harvesters). I have now created a minimal working example using the cvb-Python-API and cvb.wait_for_license(time_span_in_ms) returns a cvb.WaitStatus.Timeout. (Sidenote: I am running into some other issued when using the the Python-API under Ubuntu. For instance, cvb expects the package to be installed under site-packages, while Debian-based distributions use dist-packages. Also I have not yet been able to capture images in the Docker-Container.)

I have created a minimal working example, however due to me being a new user I am not allowed to attach it to this post :slightly_frowning_face:

If you’d be willing to have a look at it, I could send you the example via some other way :slightly_smiling_face:

You always can contact support directly for these scenarios:

https://www.stemmer-imaging.com/en-de/request-support/

Hi, did you manage to get CVB working in Docker in conjunction with harvester? If so would you like to share some pointers?