When this is merged, #2398 can possibly be closed.

Alright, we have one failing check (which is related as well):

not ok 10 checking changedetector: can detect changes & between two containers using same config in 15732ms
# (from function `assert_output' in file test/test_helper/bats-assert/src/assert.bash, line 231,
#  in test file test/mail_changedetector.bats, line 58)
#   `assert_output --partial "postfix: stopped"' failed
# 
# -- output does not contain substring --
# substring (1 lines):
#   postfix: stopped
# output (12 lines):
#   [[ TASKS ]]  2022-02-08 12:06:26 Start check-for-changes script.
#   [[  INF  ]]  2022-02-08 12:06:26 Using postmaster address [email protected]
#   [[  INF  ]]  2022-02-08 12:06:37 check-for-changes is ready
#   [[  INF  ]]  2022-02-08 12:06:37 Change detected
#   [ WARNING ]  Lock file /tmp/docker-mailserver/check-for-changes.sh.lock exists. Another check-for-changes.sh execution is happening. Trying again shortly...
#   [[  INF  ]]  Checking file line endings
#   [[  INF  ]]  Regenerating postfix user list
#   [[  INF  ]]  Creating user 'user1' for domain 'localhost.localdomain'
#   [[  INF  ]]  Creating user 'user2' for domain 'otherdomain.tld'
#   [[  INF  ]]  Creating user 'user3' for domain 'localhost.localdomain' with attributes 'userdb_mail=mbox:~/mail:INBOX=~/inbox'
#   [[  INF  ]]  Adding regexp alias file postfix-regexp.cf
#   [[  INF  ]]  Configuring root alias
# --
#

To me, it seems as if the restart of Postfix is about to happen because we see that the script says: Change detected. Maybe it's too slow at the moment because ealier, the exec would somehow interplay with the file lock (that is now being waited for, I guess ([ WARNING ] Lock file /tmp/docker-mailserver/check-for-changes.sh.lock exists. Another check-for-changes.sh execution is happening. Trying again shortly...)). @NorseGaud @casperklein @wernerfred @polarathene any idea? Maybe the weird exec had a bad tendency to masquerade a problem with locks in the changedetector?

Yes, just tested it - increasing the timeout (by a mere 10s) does the job. I think this is absolutely fine. I will push a fix, and increase the whole script sleep duration from 1s to 2s as well.

Something to consider: sleep values are dependent on a certain state. If heavy load is happening, are these sleep values valid? It's typically much better to check for some sort of state instead of relying on sleep. Especially when you find yourself increasing or decreasing sleep values.

Something to consider: sleep values are dependent on a certain state. If heavy load is happening, are these sleep values valid? It's typically much better to check for some sort of state instead of relying on sleep. Especially when you find yourself increasing or decreasing sleep values.

You're very right. We should consider removing sleeps as much as possible, but I have to admit, my main focus was on removing the exec :)

I will leave this open overnight in case @polarathene has something to add here. If you don't, by all accounts, go ahead and merge this PR @polarathene :)