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.

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