@LukeAllen this is a nice step forward. Supervisor does a good job managing processes, let me know if I can help in any way.

@gegere thanks! If you could figure out what went wrong in the automated test, that would be really helpful. It looks like the TravisCI automated test is failing at a different point than on my machine, so I'm kind of confused.

Restarted build.

I reproduced the issue locally. Will try to have a look.

Note that there's no more mail.log output in foreground (accessible using docker logs), which was a good thing to debug. (this is important otherwise DMS_DEBUG has no interest)

Problem seems related to Dovecot. I tried multiple times and its not always the same container which stops. But I can always see the same thing in the logs:

Fatal: Dovecot is not running (read from /var/run/dovecot/master.pid)

The output of start-mailserver.sh goes to stdout now, so it will be visible. (I had been redirecting the output to /var/log/container-startup.log which is why it wasn't showing. Now it goes both places.) I'm still not sure what's happening with the tests.

I guess services have to be launched in background mode, and supervisor in foreground.
start-mailserver.sh probably can't get exit 0 from foreground startups and hangs.
Just my 2 cents.

Yeah people usually run supervisor in the foreground for docker containers, but it can run in the background too. I ran it in the background to stay compatible with your existing startup script.

I replaced the old init.d calls with supervisorctl start appname which does immediately return exit 0. It does return before the app has finished starting though. I'm not sure if that breaks some assumption of the tests or the startup script. I can't figure out where the test is actually failing; is there a way to make the TravisCI tests run with DMS_DEBUG=1?

You can add DMS_DEBUG=1 in the Makefile

Hi @LukeAllen, any update on this?

I fixed the dovecot problem. The issue was that in some configurations, start-mailserver.sh starts dovecot, writes some config files, then immediately calls dovecot reload. The dovecot reload broke because supervisor hadn't finished starting dovecot. I modified it to just write all config files before starting dovecot. So now all the tests run, but there are new failures.

HI @LukeAllen, it seems that a lot of tests are not passing
https://travis-ci.org/tomav/docker-mailserver/builds/250677415?utm_source=github_status&utm_medium=notification

@LukeAllen do you need help getting this done?

I think we should check whether the tasks could run in foreground mode or not. If so (notifications and errors are mapped to stdout and stderr) we should set the following to each supervisord definition:

stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0 

Benefit would be that we would have 1 interface for all logging informations. @tomav what do you think about that?

@alinmear good idea; I incorporated your logging suggestion. Thanks for the help offer; yeah I could use some help. I'm having trouble understanding these tests. I've verified that the processes are actually all running, and the container can send mail, so my guess is that some of the tests might make assumptions that aren't true any more. Not sure though.

@LukeAllen will try to check this on the weekend!

Another possibility would be to use baseimage-docker by phusion which was designed specifically for this purpose (and other enhancements). Maybe they've already solved the problem and we don't need to reinvent the wheel?

I would be willing to invest some time into this. The docker image is perfect for running a mailserver, but I am unsure about dependability and resiliance against service failures...

Hi all,

I have rebased the changes from @LukeAllen on the new master branch and did some switching of the flow.
Currently I have almost all tests working nicely and have only 8 errors (ldap/log related). I will spend some more time on it to make these go away.

Could someone take a review of my changes on top of the @LukeAllen branch issue-631-run-services-with-supervisor and give out some ideas if some changes are needed before I wrap it up?

When done I need to make a new pull request or what is the procedure of it?

Solved all tests, see PR #676 because I could not make a PR on this PR.

Awesome thanks @johansmitsnl; I was having trouble understanding those tests. Closing this PR now since PR #676 incorporates it.