public inbox for pmg-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Stoiko Ivanov <s.ivanov@proxmox.com>
To: "Max R. Carrara" <m.carrara@proxmox.com>
Cc: pmg-devel@lists.proxmox.com
Subject: Re: [pmg-devel] [PATCH pmg-api master v1] systemd: fix report services failing if triggered to early by timers
Date: Tue, 23 Sep 2025 17:34:32 +0200	[thread overview]
Message-ID: <20250923173432.4002550e@rosa.proxmox.com> (raw)
In-Reply-To: <20250923151929.415784-1-m.carrara@proxmox.com>

Thanks for the patch - and thanks for the attention to detail you took to
the logs on a fresh system - much appreciated!

As said off-list - quickly reading through `systemd.timer(5)`
I'm not sure the `Persistent=true` makes sense for those two particular
timers:
```
...This is useful to catch up on missed runs of the service when the
system was powered down....
```

Most PMG installations are probably not powered down over prolonged
timespans, and even if they are it's probably not helping anyone to get a
spamreport or adminreport covering the time before the system was stopped.
(e.g. `pmgqm` cleans mails which are beyond the quarantine life-time
setting and this runs after the reports are sent out - so it could
probably happen that you get a report and when you view your quarantine
all mails are gone already)

If you find the time - testing if you observe any ill side-effects from
dropping `Persistent=true` (false is the default according to the man-page)
and sending this as a follow-up would be great!

(if you get to that - maybe also add the actual log-messages you saw in the
journal to the commit-message/notes below) as this can help in getting an
overview what's happening)


On Tue, 23 Sep 2025 17:19:24 +0200
"Max R. Carrara" <m.carrara@proxmox.com> wrote:

> Currently, the `pmgreport.service` and `pmgspamreport.service` units
> might fail if their corresponding timers activate them too early.
> 
> To elaborate, both timers have `Persistent=true` in addition to their
> `OnCalendar` option. `Persistent=true` means that the timer's service
> unit will be triggered immediately when the timer is activated, but
> only if it would have been triggered while the timer was inactive [0].
> 
> Since the timers are activated relatively early, they might trigger
> their service units before postfix.service and postgresql.service have
> come up, causing `pmgreport.service`, or `pmgspamreport.service`, or
> both of them to fail.
> 
> Fix this by letting both service units wait until postfix and postgres
> are up, which are necessary for the units to run successfully. Do this
> by adding the `After` and `Wants` options for `postfix.service` and
> `postgresql.service` to both service units.
> 
> Additional context:
> 
> While this is somewhat hard to encounter / debug under normal
> circumstances, it is possible to make this race condition much more
> apparent by adding an arbitrarily long delay to `postgresql.service`
> and `postfix.service` by adding an override for each:
> 
>  # systemctl edit postgresql.service
> 
> Then add the following:
> 
> [Service]
> ExecStartPre=-sleep 15
> 
> Do the same for `postfix.service`.
> 
> Afterwards, change both timers to activate a few seconds after every
> boot by adding an override for each:
> 
>  # systemctl edit pmgreport.timer
> 
> Then add the following:
> 
> [Timer]
> OnCalendar=
> OnBootSec=5
> 
> Do the same for `pmgspamreport.timer`.
> 
> A reboot should now suffice to make the issue reproducible.
> Conversely, the issue should not appear if this commit is applied.
> (Also, don't forget to remove the overrides again after debugging.)
> 
> [0]: `man 5 systemd.timer`
> 
> Signed-off-by: Max R. Carrara <m.carrara@proxmox.com>
> ---
>  debian/pmgreport.service     | 4 ++++
>  debian/pmgspamreport.service | 4 ++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/debian/pmgreport.service b/debian/pmgreport.service
> index 6b05213..89e25c7 100644
> --- a/debian/pmgreport.service
> +++ b/debian/pmgreport.service
> @@ -1,6 +1,10 @@
>  [Unit]
>  Description=Send Daily System Report Mail
>  ConditionPathExists=/usr/bin/pmgreport
> +After=postfix.service
> +After=postgresql.service
> +Wants=postfix.service
> +Wants=postgresql.service
>  
>  [Service]
>  Type=oneshot
> diff --git a/debian/pmgspamreport.service b/debian/pmgspamreport.service
> index a20214f..2b4f163 100644
> --- a/debian/pmgspamreport.service
> +++ b/debian/pmgspamreport.service
> @@ -1,6 +1,10 @@
>  [Unit]
>  Description=Send Daily Spam Report Mails
>  ConditionPathExists=/usr/bin/pmgqm
> +After=postfix.service
> +After=postgresql.service
> +Wants=postfix.service
> +Wants=postgresql.service
>  
>  [Service]
>  Type=oneshot



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel


  reply	other threads:[~2025-09-23 15:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 15:19 Max R. Carrara
2025-09-23 15:34 ` Stoiko Ivanov [this message]
2025-09-23 16:55   ` Max R. Carrara
2025-09-23 16:49 ` [pmg-devel] superseded: " Max R. Carrara

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=20250923173432.4002550e@rosa.proxmox.com \
    --to=s.ivanov@proxmox.com \
    --cc=m.carrara@proxmox.com \
    --cc=pmg-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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal