"resetup" fetchmail

[robsy]

Hi,

I´m using DMS in a more or less simple setup fetchmail => rspamd => mailboxes (IMAP), including fetchmail parallel (working very fine).
Is there a simple way to trigger the _setup_fetchmail once again after modifying fetchmail.cf while the container is running?
The only way (I found) was to redeploy the container, and I feel this is like shooting with big cannons to very small birds.

Any ideas?

Robert

[polarathene]

Is there a simple way to trigger the _setup_fetchmail once again after modifying fetchmail.cf while the container is running?

Normally you could modify config files directly in the container and when supported by a service tell it to reload the config files (eg dovecot reload / postfix reload), or the more brute force approach with DMS is to restart the service (supervisorctl restart dovecot).

When it comes to support with our DMS config volume to sync configs and apply any other post-hooks after that, we handle that via our Change Detector service (aka check-for-changes.sh), sometimes that's as simple as adding the file(s) to the list that is monitored, and then triggering a copy from the config volume to the internal config path the service actually uses (or whatever other action should be handled for the detected file update).

With Fetchmail that's a bit more complicated, as we have some extra work only applied during container startup:

docker-mailserver/target/scripts/startup/daemons-stack.sh

Lines 57 to 66 in 41dd072

	function _start_daemon_fetchmail() {
	if [[ ${FETCHMAIL_PARALLEL} -eq 1 ]]; then
	local COUNTER=0
	for _ in /etc/fetchmailrc.d/fetchmail-*.rc; do
	COUNTER=$(( COUNTER + 1 ))
	_default_start_daemon "fetchmail-${COUNTER}"
	done
	else
	_default_start_daemon 'fetchmail'
	fi

That has the "parallel" config support by managing multiple fetchmail services, one for each config. In addition to that, here is our the startup methods for fetchmail that may need to be adapted to helper scripts for the change detector to support.

---

So getting that service supported in the way that you want may be a bit of a hassle.

You should be ok though to modify the files within the container directly if you're just wanting to experiment/iterate. Shell into the container and use nano on the internal config file, then you'll need to run supervisorctl restart <service name here> (for the fetchmail services maybe identify them via supervisorctl status).

In the future it may be easier if I ever get around to refactoring the change detection feature to use something like watchexec 🤔

[polarathene]

A step by step guide for contributing change detection support for a service DMS manages is detailed here: #4380 (comment)

[polarathene]

EDIT: Actually... unless the feature below can start a new container instance, I think it'll still have the problem for fetchmail since _setup() will be skipped (due to the presence of /CONTAINER_START).

@casperklein or @georglauterbach could weigh in here, but I think there's not much we can do about this.

You may also want to consider Getmail instead of Fetchmail, as it is a little bit simpler (only a single service so you can use supervisorctl restart getmail), it still has a similar setup process that won't run during container restarts. If you can run these via an external container, you could have more control over all this and deliver to the DMS container (Getmail at least supports LMTP for this purpose).

---

One other possibility is to use Docker Compose watch feature with the sync+restart action (the docs don't indicate if there is just a restart). I've not used this feature or read through the linked docs that well, you'll need to tackle that yourself.

The feature AFAIK will monitor some files outside the container for changes, and when those files are updated it can trigger a restart of the service. With DMS v14 that might not quite work, but with DMS v15 our restart support should be in better shape. v15 will be released later this month AFAIK, but for the time being you can use :edge which currently reflects what v15 will be, so there should be no difference there, just update the tag to :15 once v15 is released (be sure to go over our ChangeLog before you upgrade from earlier release).