Handle docker_firsttime also in the Daemon containers

[bschmalhofer]

Just ran into another problematic case. Started under Docker an setup with four services 'web' and one service 'daemon' and one service 'minio'. OTOBO_SYCN_WITH_S3 is set and /opt/otobo is not mounted as a volume. In the GUI I got the notification that the Daemon is not running. The message is correct as in the Daemon contaier only /opt/otobo_install/entrypoint.sh daemon is running. That process is waiting for the existence of /opt/otobo/bin/otobo.Daemon.pl. But this never happens as /opt/otobo is never populated in the container daemon. In a normal setup this is perfectly sensible, as the container web populates the directory /opt/otobo.

TODO:

• call handle_docker_firsttime() also in the container daemon
• But add a locking mechanism so that containers don't get into each others way

The lock is sensible anyways. as it is not guaranteed that only a single container web is started when /opt/otobo is mounted.

Originally posted by @bschmalhofer in #1755 (comment)

[bschmalhofer]

Found out that using flock on mounted Docker volumes is not well supported. See https://forums.docker.com/t/docker-volume-file-permission-and-locking/24335/4. So it's back to the drawing board. Let's keep it simple and support only two cases:

1. The current standard case: /opt/otobo is a Docker volume shared between a single web and daemon container
2. The S3 case where /opt/otobo is part of the Docker image

re. 1.: This is handled fine in the current approach. web does the copying and daemon is waiting until /opt/otobo is available. Actually daemon is checking only the existence of bin/otobo.Daemon.pl. So there is room for a race condition. Maybe add a flag file that indicates that copy_otobo_next() has finished.

re. 2.: There is only one process active in /opt/otobo. No need for locking. We only need an indicator that daemon should call copy_otobo_next().

[bschmalhofer]

Checked whether it works with separate /opt/otobo

TODO:

• check with /opt/otobo in a volume

[bschmalhofer]

No complaints so far. Closing this issue.