Loosing DB connection inside container

Hello everyone!

For several years now, we have been facing a peculiar problem with a Dockerized PHP application. After repeatedly searching for a solution without success, I would like to ask the community for any possible ideas.

We are dealing with a PHP4 application that connects to an Oracle DB outside the container. Occasionally, sometimes after a few weeks or sometimes after months, the PHP application suddenly cannot connect to the DB anymore.

Both ping and tnsping to the DB work, both from inside and outside the container. Restarting the container doesn’t change the situation; OCILogon times out even though the DB is reachable. After rebooting the host system, everything works again.

Interestingly, this problem occurs for all our customers on different host systems.

Perhaps someone has an idea what the cause could be.

best regards

When you run PHP4 applications (EOL 2007), I barely dare to ask what OS and Docker version you are using :wink:


Well, these applications were developed by us almost 20 years ago and are still being used by our customers.
The php4 specification in my previous post is actually not quite correct. The applications were originally developed in php4, and then later minimally adapted to run on php5. Sorry for the confusion.
A few years ago, the entire environment was migrated to Docker.
Base image is centos:7 with php and oracle 10gR2 client, pretty simple actually.

FROM centos:7

RUN yum -y upgrade \
    && yum -y install tar glibc.i686 freetype.i686 libpng.i686 libjpeg-turbo.i686 \
    && yum -y install php \
    && yum -y clean all \
    [...] create users and groups

[...] copy assets

RUN  cd / \
    #oracle client
    && curl -o /tmp/oracle_client.tar.gz http://localrepo \
    && tar xzvpf /tmp/oracle_client.tar.gz -C /opt/ \
    # php libs (PEAR / XML)
    && tar xzvpf /tmp/php.tar.gz -C /usr/local/lib/ \
    # www folder (including apache server)
    && tar xzvpf /tmp/www_base.tar.gz -C / \
    [...] clean up

CMD /www/bin/apachectl start

This image runs on different host systems,
e.g. Centos 7 with docker engine 20.10.5 or Ubuntu 18.04.1 LTS with docker engine
but the problem is always the same, from time to time it is no longer possible to establish a db connection from inside the docker container, and the only solution we have is to reboot the hostsystem.

I’m not sure how Docker could be the reason, but could you be a little bit more precise about what you tried? Did you try to restart the PHP container or the database container?

This seems to be wrong. apachectl would start the process in the background, so your container stops immediately.

Check official images how those start PHP

They use this as start script named as “apache2-foreground”:

Based on the installed packages, am I right to assume you are not using amd64 architecture but i686?

Hi, thank you very much for your interest!

Yes, you’re right, I left something out here. I wanted to reduce the code to the essentials and left out the most important thing. There was implemented a little hack when the Dockerfile was created, and now, as you point it out, it’s the first time I really recognize it.
The complete CMD looks like this

CMD /www/bin/apachectl start && tail -F /www/logs/access_log

So the container keeps running.

We have already tried everything possible.
Container restart, image rebuild, restart of docker daemon…
We have never tried DB restart, but that is also out of the question. This is a large DB (non-dockerized) with many hundreds of different clients attached to it, and their connectivity is never impaired.

Reagrding the i686 packages:
The host system and the docker image are x86-64.
The i686 packages are required by the oracle client as far as I can remember. But also by some graphic libs used for the php apps

You better hurry :joy:

CentOS Linux 7 will reach end of life (EOL) on June 30, 2024

I know, but this is not my job :slight_smile:

Better, but still not good. But that would be another topic. Probably not related to your issue.

If it is true, then there is nothing else to do :slight_smile: I doubt it, but I sill don’t know how Docker would cause it. It either works or not. But maybe something with the available resources which you solved by restarting the host.

So it is not running on the same server, right?

:smiley: Yes, thats true.

Yes, the DB is located on another host.

What may also be interesting,
there are other dockerized applications running on the same host (glassfish, wildfly, tomcat…). these also connect to the same database, but have no problems