From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 76A8D1FF191 for ; Tue, 23 Sep 2025 18:55:30 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 70B16139ED; Tue, 23 Sep 2025 18:56:00 +0200 (CEST) Mime-Version: 1.0 Date: Tue, 23 Sep 2025 18:55:27 +0200 Message-Id: To: "Stoiko Ivanov" From: "Max R. Carrara" X-Mailer: aerc 0.18.2-0-ge037c095a049 References: <20250923151929.415784-1-m.carrara@proxmox.com> <20250923173432.4002550e@rosa.proxmox.com> In-Reply-To: <20250923173432.4002550e@rosa.proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1758646515139 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.086 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pmg-devel] [PATCH pmg-api master v1] systemd: fix report services failing if triggered to early by timers X-BeenThere: pmg-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Mail Gateway development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pmg-devel@lists.proxmox.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pmg-devel-bounces@lists.proxmox.com Sender: "pmg-devel" On Tue Sep 23, 2025 at 5:34 PM CEST, Stoiko Ivanov wrote: > 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) Just sent in a v2 addressing all of this! (: The tl;dr is: `Persistent=true` ensures that reports are being sent even in the case of a particularly poorly timed downtime / reboot at midnight. While yes, this isn't ideal if there's a prolonged downtime, most PMG installations are probably not powered down over prolonged timespans, as you mentioned. So IMO it's more important to ensure that no reports are missing instead of sending out potentially useless reports. Also added some of the logs I've shown you off-list already. > > > On Tue, 23 Sep 2025 17:19:24 +0200 > "Max R. Carrara" 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. > > > > [...] _______________________________________________ pmg-devel mailing list pmg-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel