docker-maven-plugin: docker stop does not work

Hello,

I have a maven project and the docker plug in configuration for it is listed below. Starting works fine. But after the integration tests are done and the plug in shuts down the container it just hangs with this output forever

[INFO] — docker-maven-plugin:0.14.1:stop (stop) @ wh-cdc-web — 08:52:37.421 DB> 2016-09-06 06:52:37 UTC [1-2] LOG: received smart shutdown request 08:52:37.421 DB> 2016-09-06 06:52:37 UTC [10-2] LOG: autovacuum launcher shutting down

The container is not running anymore so it was shutdown, it’s just the plugin waiting for something.

PlugIn Version: 0.15.16 Docker version 1.12.1, build 23cf638

Dockerfile.txt

<plugin>
                <groupId>io.fabric8</groupId>
                <artifactId>docker-maven-plugin</artifactId>
                <version>${docker.maven.plugin.fabric8.version}</version>
                <configuration>
                    <logDate>default</logDate>
                    <autoPull>true</autoPull>
                    <images>
                        <image>
                            <alias>db</alias>
                            <name>postgres:9</name>
                            <build>
                                <ports>
                                    <port>5432</port>
                                </ports>
                                <dockerFileDir>${project.basedir}/docker</dockerFileDir>
                            </build>
                            <run>
                                <ports>
                                    <port>${dbPort}:5432</port>
                                </ports>
                                <wait>
                                    <log>database system is ready to accept connections</log>
                                    <time>20000</time>
                                </wait>
                                <log>
                                    <prefix>DB</prefix>
                                    <color>yellow</color>
                                </log>
                            </run>
                        </image>
                    </images>
                </configuration>

                <!-- Hooking into the lifecycle -->
                <executions>
                    <execution>

                        <id>start</id>
                        <phase>pre-integration-test</phase>
                        <goals>
                            <goal>build</goal>
                            <goal>start</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>stop</id>
                        <phase>post-integration-test</phase>
                        <goals>
                            <goal>stop</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

About this issue

Original URL
State: open
Created 8 years ago
Comments: 70 (1 by maintainers)

Commits related to this issue

use tcp instead of unix sockets for docker - https://github.com/fabric8io/docker-maven-plugin/issues/552 — committed to AlfrescoArchive/activiti-cloud-audit-service by deleted user 6 years ago
use tcp instead of unix sockets for docker - https://github.com/fabric8io/docker-maven-plugin/issues/552 — committed to AlfrescoArchive/activiti-cloud-modeling-service by deleted user 6 years ago
use tcp instead of unix sockets for docker - https://github.com/fabric8io/docker-maven-plugin/issues/552 — committed to AlfrescoArchive/activiti-cloud-process-model-service by deleted user 6 years ago
use tcp instead of unix sockets for docker - https://github.com/fabric8io/docker-maven-plugin/issues/552 — committed to AlfrescoArchive/activiti-cloud-modeling by deleted user 6 years ago

Most upvoted comments

Thanks ! I will try to reproduce this on a virtual box image and can hopefully trigger the same bug.

rhuss on Jun 1, 2017

@andreasaronsson I tried jnr-unixsocket-0.19 already but I got tons of issues with closed streams. Not sure that’s d-m-p doing something wrong or the lib. Going to investigate this further, as it seems that it contains some fix which could be related to this issue.

rhuss on May 24, 2018

Yes, i did some deep debugging some time ago and it seems that jnr-unixsocket mixes up streams if you access the unix socket concurrently (responses from the socket are written back to the wrong stream). This could also explain that Maven still waits on answer which already has been sent on another stream.

Parallel access happens e.g. when you us a wait condition on log files.

rhuss on Jan 10, 2018

I am having this same issue with a MySQL container, but only when I specify a volume for it to use. I was trying to fix some slowness that was happening on Travis by running MySQL on a ramdisk, and then starting running into this issue.

  <plugin>
    <groupId>io.fabric8</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>0.20.1</version>
    <executions>
      <execution>
        <id>prepare-it-containers</id>
        <phase>pre-integration-test</phase>
        <goals>
          <goal>start</goal>
        </goals>
        <configuration>
          <images>
            <image>
              <name>mysql:5.7</name>
              <alias>db_it</alias>
              <run>
                <namingStrategy>alias</namingStrategy>
                <env>
                  ...
                </env>
                <ports>
                  <port>${mysql.port}:3306</port>
                </ports>
                <wait>
                  <log>ready for connections</log>
                  <time>20000</time>
                  <shutdown>5000</shutdown>
                  <kill>5000</kill>
                </wait>
                <volumes>
                  <bind>
                    <volume>/mnt/ramdisk:/var/lib/mysql</volume>
                  </bind>
                </volumes>
              </run>
            </image>
          </images>
        </configuration>
      </execution>
      <execution>
        <id>remove-it-containers</id>
        <phase>post-integration-test</phase>
        <goals>
          <goal>stop</goal>
        </goals>
        <configuration>
          <removeVolumes>true</removeVolumes>
        </configuration>
      </execution>
    </executions>
  </plugin>

I tried attaching the volume to my standard volume rather than ramdisk, and it still happens. I also check and the containers are gone almost immediately after it starts hanging, it just never returns.

toran414 on May 4, 2017