CES Daemon in Docker container

The licensing system automatically starts the daemon on demand when in a container environment, so I am unsure why you are trying to start the licensing system.

I could be wrong but my understanding Rocky Linux/Containers/Docker is not a supported scenario with v6.   

I think v9.0 was the first version where we supported containers with rocky linux and it was with podman & autopass.

@James Rowson / @Stephen kennington thoughts?

According to Project Management, we supported Rocky Linux 9.0 in VC/ED 9.0. As it's Rocky 9.0 it'll be podman.

------------------------------
James Rowson
Rocket Forum Shared Account
------------------------------

Hi Eric,

Please note that Rocket Software provides support for running in containers via the Visual COBOL "for Docker" products (these are different than the regular Visual COBOL products). Also as noted in a prior reply, running in containers on Rocky Linux was not supported in Visual COBOL 6.0.

Since you would need to upgrade, please consider moving to the latest version; Visual COBOL Development Hub for Docker/COBOL Server for Docker 10.0; here is a link to a docs page with information about Container support, which lists supported Operating Systems and container tools.

I will just continue using Rocky 8 as my host since that works in my Jenkins build environment with multiple docker OS versions.  I was just trying to see if I could figure out why the mfcesd starts after sitting for over 10 minutes as I debugged it but haven't figured out yet what it is waiting for.  I know that MF 6 works fine in my Rocky 9 host even if not officially supported.

I am stuck building/linking my product for the customers that are actually using older MF versions and don't move forward very quickly.

Thanks.

I am now stuck trying to build our products on Rocky Linux 9 host with a Rocky Linux 9 docker image.  I have installed Microfocus 10 in my image and start autopass & mfcesd and still see the same hang I was having with previous versions.  I still see the hang of mfcesd with the frames below.  This hangs for at least 5 minutes on that until it finally starts.  I am just looking for anything you can point me into what could be causing this to hang at that location for this long.

[d673c90b94dc] (root) /> ps -ef | grep microfocus
root         551       1 17 15:32 pts/0    00:00:06 /opt/microfocus/licensing/autopass/java-runtime/bin/java -XX:-UsePerfData -cp /opt/microfocus/licensing/autopass/lib/autopassj-daemon-24.1-jar-with-dependencies.jar -Dappname=autoPassdaemon -Djava.util.prefs.systemRoot=/opt/microfocus/licensing/autopass com.autopass.daemon.LinuxServer $@ start
root         673       1 97 15:32 ?        00:00:36 /opt/microfocus/licensing/bin/mfcesd

[d673c90b94dc] (root) /> pstack 673
#0  0x00007f2c94a38747 in close () from /lib64/libc.so.6
#1  0x00000000004069b6 in daemonize ()
#2  0x00000000004098ed in main ()

… After at least 5 minutes

[d673c90b94dc] (root) /> pstack 673
Thread 4 (Thread 0x7f2c93935640 (LWP 1088) "mfcesd"):
#0  0x00007f2c949c122a in __futex_abstimed_wait_common () from /lib64/libc.so.6
#1  0x00007f2c949c396f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libc.so.6
#2  0x00007f2c94c29b9f in waitTreeLimit () from /opt/microfocus/licensing/bin/libmfcollector.so.3
#3  0x00007f2c94c28bfd in houseKeepingThread () from /opt/microfocus/licensing/bin/libmfcollector.so.3
#4  0x00007f2c94c29121 in houseKeepingInstanceThread () from /opt/microfocus/licensing/bin/libmfcollector.so.3
#5  0x00007f2c949c419a in start_thread () from /lib64/libc.so.6
#6  0x00007f2c94a48534 in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f2c94136640 (LWP 1087) "mfcesd"):
#0  0x00007f2c94a3c00f in poll () from /lib64/libc.so.6
#1  0x00007f2c94c294a3 in collectorThreadMainLoop () from /opt/microfocus/licensing/bin/libmfcollector.so.3
#2  0x00007f2c94c28d35 in collectorThread () from /opt/microfocus/licensing/bin/libmfcollector.so.3
#3  0x00007f2c94c2914b in collectorInstanceThread () from /opt/microfocus/licensing/bin/libmfcollector.so.3
#4  0x00007f2c949c419a in start_thread () from /lib64/libc.so.6
#5  0x00007f2c94a48534 in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f2c94937640 (LWP 1086) "mfcesd"):
#0  0x00007f2c949c122a in __futex_abstimed_wait_common () from /lib64/libc.so.6
#1  0x00007f2c949c396f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libc.so.6
#2  0x0000000000406322 in ProcWatcherThread ()
#3  0x00007f2c949c419a in start_thread () from /lib64/libc.so.6
#4  0x00007f2c94a48534 in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f2c94939140 (LWP 673) "mfcesd"):
#0  0x00007f2c94a3e82d in select () from /lib64/libc.so.6
#1  0x000000000040a225 in main ()
 

Eric

I have found a solution that works for me right after entering the previous entry. 

If I limit the number of soft and hard open file limits to something reasonable like 64k and 200000 then the process starts quickly as expected.  Not sure why this works but now MF works correctly within my docker image.

Eric