From: "Max R. Carrara" <m.carrara@proxmox.com>
To: "Stoiko Ivanov" <s.ivanov@proxmox.com>, <pmg-devel@lists.proxmox.com>
Subject: Re: [pmg-devel] [PATCH package-rebuilds v2 1/1] fetchmail: improve shipped service file
Date: Thu, 25 Sep 2025 19:07:26 +0200 [thread overview]
Message-ID: <DD21O6RPG4MX.3NUWVQ5BR9KMY@proxmox.com> (raw)
In-Reply-To: <20250924180538.9281-4-s.ivanov@proxmox.com>
On Wed Sep 24, 2025 at 8:05 PM CEST, Stoiko Ivanov wrote:
> fetchmail exits with exit-code 3 if:
> 'The user authentication step failed...' (see fetchmail(1)).
> This also includes the case if there are no accounts configured for
> fetching, e.g. if all accounts are configured with 'skip' instead of
> 'poll'. In PMG you get this when temporary disaling all configured
> accounts in the GUI.
s/disaling/disabling ;)
>
> So we simply should not consider an exit of 3 as failure.
> Additionally adapt the Restart value to 'on-failure' (else systemd
> tries restarting 5 times and gives up)
> see systemd.service(5).
But wouldn't this mean that if I e.g. temporarily disable all configured
accounts, `fetchmail.service` would exit with `3` and then never restart
again? Or am I mistaken here?
That being said, `fetchmail.service` refuses to start for me on my most
recent test VMs, even though I have added a dummy entry in the UI.
I might be holding it wrong, but `/etc/default/fetchmail` is never being
written to; it's empty for me.
# systemctl status fetchmail.service
○ fetchmail.service - fetchmail mail retriever agent
Loaded: loaded (/usr/lib/systemd/system/fetchmail.service; enabled; preset: enabled)
Active: inactive (dead) (Result: exec-condition) since Thu 2025-09-25 18:47:38 CEST; 6min ago
Invocation: e87235808c58412883ec5c2ad55ab248
Condition: start condition unmet at Thu 2025-09-25 18:47:38 CEST; 6min ago
Docs: man:fetchmail(1)
Process: 2239 ExecCondition=/bin/sh -c [ "$START_DAEMON" = "yes" ] (code=exited, status=1/FAILURE)
Mem peak: 1.7M
CPU: 5ms
Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: Starting fetchmail.service - fetchmail mail retriever agent...
Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: fetchmail.service: Skipped due to 'exec-condition'.
Sep 25 18:47:38 pmg-9-beta-01 systemd[1]: Condition check resulted in fetchmail.service - fetchmail mail retriever agent being skipped.
All of that aside, I think it would make more sense to keep
`Restart=always` but add `SuccessExitStatus=3`, as well as
`RestartSec=` to control how quickly the service is restarted [0].
Since the daemonized fetchmail sleeps for 300 seconds before running
again, we could maybe set `RestartSec=300`, so that systemd waits for
five minutes before trying to start `fetchmail.service` again. That way
the daemon isn't restarted immediately when it fails; or in other words,
mails are fetched every 5 minutes, even on failure.
Additionally, it might be favorable to explicitly set
`StartLimitIntervalSec=` and `StartLimitBurst=` [1] here, because the
default retry count is 5 (as you already noticed), in case setting
`RestartSec` alone is insufficient for some reason.
FWIW, you can find the defaults for the above two values using
`cat /etc/systemd/system.conf | grep StartLimit`
[0]: `man 5 systemd.service`
[1]: `man 5 systemd.unit`
>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
> pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> index a6e3168..b7260ac 100644
> --- a/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> +++ b/pkgs/fetchmail/fetchmail-6.4.39/debian/fetchmail.service
> @@ -21,7 +21,8 @@ User=fetchmail
> Type=exec
> # sort $OPTIONS after "-daemon 300" to allow overwriting the interval using $OPTIONS
> ExecStart=/usr/bin/fetchmail --daemon 300 $OPTIONS --nodetach -f /etc/fetchmailrc --pidfile /run/fetchmail/fetchmail.pid
> -Restart=always
> +SuccessExitStatus=3
> +Restart=on-failure
>
> [Install]
> WantedBy=multi-user.target
_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel
prev parent reply other threads:[~2025-09-25 17:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 18:05 [pmg-devel] [PATCH pmg-api v2 0/2] improve fetchmail handling in PMG Stoiko Ivanov
2025-09-24 18:05 ` [pmg-devel] [PATCH pmg-api v2 1/2] fix #6798: fetchmail: adapt to changed sslproto semantics Stoiko Ivanov
2025-09-24 18:05 ` [pmg-devel] [PATCH pmg-api v2 2/2] templates: fetchmail: add comment where users can add manual accounts Stoiko Ivanov
2025-09-24 18:05 ` [pmg-devel] [PATCH package-rebuilds v2 1/1] fetchmail: improve shipped service file Stoiko Ivanov
2025-09-25 17:07 ` Max R. Carrara [this message]
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=DD21O6RPG4MX.3NUWVQ5BR9KMY@proxmox.com \
--to=m.carrara@proxmox.com \
--cc=pmg-devel@lists.proxmox.com \
--cc=s.ivanov@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