Tests are failing!
That's strange as it has passed on my host all the checks.

I've repeated now my tests and :

docker exec mail_fail2ban fail2ban-client status sasl
ERROR Unable to contact server. Is it running?
And a few seconds later:
docker exec mail_fail2ban fail2ban-client status sasl
Status for the jail: sasl
|- filter
| |- File list: /var/log/mail/mail.log
| |- Currently failed: 0
| - Total failed: 0 - action
|- Currently banned: 0
| - IP list: - Total banned: 0

I'll look at it later.

@tomav I've repeated the tests in my own environment (via Makefile) and it seems that it may happen that during some test not all services are already online. I've expanded the sleep time used in the makefile and now everything is working (on my own server):

52 tests, 0 failures

I don't know if that could be the kind of problem we have on the Travis CI build. Maybe having another container to start up (mail_fail2ban) requires more time for the services to be online.

@tomav the jail is there and is configured for sasl.
From my own experience - on my server - the problem is that when the tests are run the new mail_fail2ban container _hasn't fully started _all the services, fail2ban included. What do you think about it?
On my server I've increased the sleep time in the makefile between each rules and it complete the tests, now, as I've reported on April 2nd.

Increasing time is not a good solution, we already have timeouts because of freshclam.
We should use a matrix of env and play dedicated tests.
https://docs.travis-ci.com/user/customizing-the-build/#Build-Matrix

That's probably what @gegere suggested.

That's a possibility.
Do you have any suggestion? Because we could test fail2ban togheter with pop3 for example? What do you think?

Never played with Travis matrix build and I'm currently out of time. Let's see if a contributor can help.

@tomav I've seen that today's Reldeis patch has passed the CI tests. Would you like to try to restart this one? Probably now the Travis-CI resources are less busy!

Restarted.

@tomav I've another idea

@tomav sorry, I've another idea: I've tested on my server and make the job reach the end (on my server at least!).
In the makefile I've splitted the single sleep 60 at the end of the run rule in 4 distinct sleep 15 at the end of each docker run command.
This way each container has some time to startup and reach an almost stable state (where almost all if not all the processes are up).

In fact the problem with the current version is that starting up all the processes togheter causes a lot of contention on the resources (iowait and so on). As an example, 60s after the startup of all the containers on the container mail only 20 processes out of 30 are ready!

By splitting 60s in 4x15s we don't add more time to the job :)
Is it ok for you?

Ok, let's try!

@tomav Ok - I'm going to submit another PR.

@tomav ... sort of ... eureka!
Finally all the tests are ok :)

@tomav I've done some changes and added a PR.
You will also find a check for the integration tests. Please consider that some of the tests have been modified to look at the new /var/log/mail/mail.log path so - even if indirectly - we are already checking that logs are now in the new location. Anyway, I've added a specific test to check that.
Moreover the commit message is - I hope - more clear.