From: Aaron Lauterer <a.lauterer@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [RFC cluster] pmxcfs startup: order before MTAs
Date: Mon, 5 Sep 2022 14:06:02 +0200 [thread overview]
Message-ID: <0746f4b0-bec7-d8bd-54f4-fcaf6f7b01e0@proxmox.com> (raw)
In-Reply-To: <20220905115840.176352-1-s.ivanov@proxmox.com>
If the systemd ordering is okay, what about how we have with Ceph, where we
place the "ceph-after-pve-cluster.conf" for each service instead of changing the
pve-cluster.service?
See my recent patch regarding this [0].
[0] https://lists.proxmox.com/pipermail/pve-devel/2022-July/053546.html
On 9/5/22 13:58, Stoiko Ivanov wrote:
> currently pmxcfs and the running mta (postfix in most cases I assume)
> have no ordering between them - resulting in the mta starting before
> pmxcfs.
>
> This can be problematic in case of a mail for 'root' being in the
> mailq: postfix tries to deliver the mail - pvemailforward tries to
> look up the destination address in /etc/pve/user.cfg and gets a
> connection refused since pmxcfs is not running yet.
>
> reported via our community-forum:
> https://forum.proxmox.com/threads/.108893/
>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
> sending as RFC, since while thinking about this issue and discussing it
> off-list (thx @Fiona!) the following alternative approaches were/are
> considered:
> * letting pvemailforward.pl exit with an error-code - sadly does not work
> as the only difference is that postfix generates a bounce for the mail
> and in (the most-common) case of root being the sender that bounce is
> also undeliverable, and thus dropped
> * the fix through systemd-ordering does work for this case - but seems
> not quite fitting (after all pmxcfs and postfix can happily exist w/o
> the other - only delivering mail to root does not work) - also
> the issue also happens if pmxcfs is not available for other reasons
> * an alternative approach would be to retry fetching the information from
> pmxcfs a few times (afair postfix' command-timeout is 1000s for this),
> e.g. like we do in the installer when looking for the correct ISO.
>
> debian/pve-cluster.service | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/debian/pve-cluster.service b/debian/pve-cluster.service
> index 4327055..fb706be 100644
> --- a/debian/pve-cluster.service
> +++ b/debian/pve-cluster.service
> @@ -5,6 +5,7 @@ Wants=corosync.service
> Wants=rrdcached.service
> Before=corosync.service
> Before=cron.service
> +Before=postfix.service exim4.service sendmail.service qmail.service
> After=network.target
> After=sys-fs-fuse-connections.mount
> After=time-sync.target
next prev parent reply other threads:[~2022-09-05 12:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 11:58 Stoiko Ivanov
2022-09-05 12:06 ` Aaron Lauterer [this message]
2022-09-05 13:22 ` Stoiko Ivanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0746f4b0-bec7-d8bd-54f4-fcaf6f7b01e0@proxmox.com \
--to=a.lauterer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox