On Sat, Dec 28, 2024 at 17:21:08 +0100, Roger Price wrote:

● fetchmail.service - LSB: init-Script for system wide fetchmail daemon

The correct way to stop a systemd service whose name you know is:

systemctl stop fetchmail.service

If you're entirely new to systemd, you can get by with:

systemctl status NAME # looks like you found that
systemctl stop NAME # terminate a running service
systemctl start NAME # start a stopped service
systemctl restart NAME # stop, and then start, a running service
systemctl reload NAME # ask a running service to reread configs

Not all services have a "reload" option, but many do.

Quite often, discovering the service's systemd unit name is the hardest
part in managing it.

It's dead, but still fetching mail!

If the service is showing as terminated, but it continues running intermittently, then it's *possible* that something else is invoking
it. In that case, you will have some detective work to do. But let's
not go down that rabbit hole if it's just a matter of you not knowing
how to stop a service.

I tried

root@titan ~ /etc/init.d/fetchmail --quit
Not starting fetchmail daemon, disabled via /etc/default/fetchmail.

The correct way to use a legacy sysv-rc init.d script to stop a service
is:

/etc/init.d/fetchmail stop

But if you already know there's a systemd unit, you should use the
systemctl way instead. The init.d scripts are remnants of a past
init system. If you're not actually *using* that init system, you
shouldn't get in the habit of relying on its legacy shims to be there.

In this specific case, the --quit option you tried to use was ignored,
and it appears to have assumed you meant "start". But it DID NOT
start the fetchmail service, because it's disabled in the /etc/default/fetchmail file. (The /etc/default/ directory is the
common place for configuration files used by sysv-rc scripts.)

All of this is just background noise, though. You shouldn't be using
this init.d script when there's a systemd unit file.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

I would like to stop fetchmail on Debian 11. I tried command systemctl stop fetchmail and system status fetchmail reported

● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: inactive (dead) since Sat 2024-12-28 10:37:58 CET; 6h ago
Docs: man:systemd-sysv-generator(8)
Process: 1250 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
Process: 1199929 ExecStop=/etc/init.d/fetchmail stop (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 57750)
Memory: 1.9M
CPU: 6min 33.392s
CGroup: /system.slice/fetchmail.service
└─1264 /usr/bin/fetchmail -f /etc/fetchmarc
--pidfile /var/run/fetchmail/fetchmail.pid --syslog
...
Dec 28 17:06:54 titan fetchmail[1264]: reading message
mailbox@rogerprice.org@mail.gandi.net:1 of 1 (9321 octets) flushed

It's dead, but still fetching mail! I tried

root@titan ~ /etc/init.d/fetchmail --quit
Not starting fetchmail daemon, disabled via /etc/default/fetchmail.

but fetchmail goes on fetching mail. What is the correct way of stopping fetchmail?

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi, have you try

/etc/init.d/fetchmail stop

?

Cheers,
Jerome

On 28/12/2024 17:21, Roger Price wrote:

I would like to stop fetchmail on Debian 11.  I tried command systemctl stop fetchmail and system status fetchmail reported

 ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
     Loaded: loaded (/etc/init.d/fetchmail; generated)
     Active: inactive (dead) since Sat 2024-12-28 10:37:58 CET; 6h ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1250 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
    Process: 1199929 ExecStop=/etc/init.d/fetchmail stop (code=exited, status=0/SUCCESS)
      Tasks: 1 (limit: 57750)
     Memory: 1.9M
        CPU: 6min 33.392s
     CGroup: /system.slice/fetchmail.service
             └─1264 /usr/bin/fetchmail -f /etc/fetchmarc
                    --pidfile /var/run/fetchmail/fetchmail.pid --syslog
 ...
 Dec 28 17:06:54 titan fetchmail[1264]: reading message
                                        mailbox@rogerprice.org@mail.gandi.net:1 of 1 (9321 octets) flushed

It's dead, but still fetching mail! I tried

 root@titan ~ /etc/init.d/fetchmail --quit
 Not starting fetchmail daemon, disabled via /etc/default/fetchmail.

but fetchmail goes on fetching mail.  What is the correct way of stopping fetchmail?

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for your replies. I tried

systemctl stop fetchmail.service

I tried 4 times. then I tried

/etc/init.d/fetchmail stop

but although dead for 6 hours, fetchmail continued to fetch mails.
So I tried

root@titan ~ ps -ef | grep fetch
fetchma+ 1264 1 0 Sep25 ? 00:06:33 /usr/bin/fetchmail -f
/etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid --syslog
root@titan ~ kill 1264

And the fetchma+ process disappeared - I hope it no longer rises from the
dead.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 28 Dec 2024 17:21:08 +0100 (CET)
Roger Price <debian@rogerprice.org> wrote:

but fetchmail goes on fetching mail. What is the correct way of
stopping fetchmail?

Perhaps there is a fetchmail.timer unit that is starting up
fetchmail.service from time to time?

systemctl status fetchmail.timer

You might also look at /usr/share/doc/fetchmail/README.systemd

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 28, 2024 at 11:36:44 -0700, Charles Curley wrote:

On Sat, 28 Dec 2024 17:21:08 +0100 (CET)
Roger Price <debian@rogerprice.org> wrote:

but fetchmail goes on fetching mail. What is the correct way of
stopping fetchmail?

Perhaps there is a fetchmail.timer unit that is starting up
fetchmail.service from time to time?

systemctl status fetchmail.timer

You might also look at /usr/share/doc/fetchmail/README.systemd

Going back to the original post, it looks like the systemd "unit"
for fetchmail is actually just a shim for the init.d scripts.
That may change in some future version of Debian (or perhaps the OP
is on an old version??), but for now, I'd look to more traditional
sources.

Perhaps there's a cron job that starts it.

Assuming "fetchmail" is the package name, it might be worth looking at
the file list (dpkg -L fetchmail) to see what's being installed. If
there's a *.timer file, or a file inside a cron.* directory, those
would be worth investigating.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 28, 2024 at 18:56:09 +0100, Roger Price wrote:

I tried 4 times. then I tried

/etc/init.d/fetchmail stop

but although dead for 6 hours, fetchmail continued to fetch mails.
So I tried

root@titan ~ ps -ef | grep fetch
fetchma+ 1264 1 0 Sep25 ? 00:06:33 /usr/bin/fetchmail -f
/etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid --syslog
root@titan ~ kill 1264

That process had been running for three months.(*) It wasn't "dead for 6 hours" at the moment you ran those commands.

(*) Unless of course your system clock is massively wrong.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 28 Dec 2024, Greg Wooledge wrote:

On Sat, Dec 28, 2024 at 11:36:44 -0700, Charles Curley wrote:

On Sat, 28 Dec 2024 17:21:08 +0100 (CET)
Roger Price <debian@rogerprice.org> wrote:

but fetchmail goes on fetching mail. What is the correct way of
stopping fetchmail?

Perhaps there is a fetchmail.timer unit that is starting up
fetchmail.service from time to time?

Perhaps there's a cron job that starts it.

Debian 11 dpkg -L fetchmail does not show any timer unit or other cron device that might keep a "dead" service alive.

systemctl status fetchmail.timer

No such unit in Debian 11.

You might also look at /usr/share/doc/fetchmail/README.systemd

I found nothing that keeps officially "dead" services alive.

root@titan ~ ps -ef | grep fetch
fetchma+ 1264 1 0 Sep25 ? 00:06:33 /usr/bin/fetchmail -f
/etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid --syslog
root@titan ~ kill 1264

That process had been running for three months.(*) It wasn't "dead for 6 hours" at the moment you ran those commands.

The process was alive for three months until I typed systemctl stop fetchmail. 6
hours later I typed systemctl status fetchmail and systemd told me that the still running process had been "dead" for 6 hours.

# (*) Unless of course your system clock is massively wrong.

:-) I rely on the Network Time Protocol (NTP). An excellent service.

But the problem is solved. Command kill came to the rescue.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Price (12024-12-28):

● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: inactive (dead) since Sat 2024-12-28 10:37:58 CET; 6h ago
Docs: man:systemd-sysv-generator(8)
Process: 1250 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
Process: 1199929 ExecStop=/etc/init.d/fetchmail stop (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 57750)
Memory: 1.9M
CPU: 6min 33.392s
CGroup: /system.slice/fetchmail.service
└─1264 /usr/bin/fetchmail -f /etc/fetchmarc
--pidfile /var/run/fetchmail/fetchmail.pid --syslog
...
Dec 28 17:06:54 titan fetchmail[1264]: reading message
mailbox@rogerprice.org@mail.gandi.net:1 of 1 (9321 octets) flushed

It's dead

It is “dead” but not dead, since it still has a process. Your problem is there, you do not need to look elsewhere: systemctl stop did not do its
job properly. You need to find out why.

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Dec 28, 2024 at 22:59:19 +0100, Nicolas George wrote:

Roger Price (12024-12-28):

● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: inactive (dead) since Sat 2024-12-28 10:37:58 CET; 6h ago
Docs: man:systemd-sysv-generator(8)
Process: 1250 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
Process: 1199929 ExecStop=/etc/init.d/fetchmail stop (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 57750)
Memory: 1.9M
CPU: 6min 33.392s
CGroup: /system.slice/fetchmail.service
└─1264 /usr/bin/fetchmail -f /etc/fetchmarc
--pidfile /var/run/fetchmail/fetchmail.pid --syslog
...
Dec 28 17:06:54 titan fetchmail[1264]: reading message
mailbox@rogerprice.org@mail.gandi.net:1 of 1 (9321 octets) flushed

It's dead

It is “dead” but not dead, since it still has a process. Your problem is there, you do not need to look elsewhere: systemctl stop did not do its
job properly. You need to find out why.

If you look at the ExecStart= there, you can see that this isn't a
proper systemd unit. It's just an auto-generated wrapper around the
init.d scripts.

If an init.d script is broken and doesn't stop the service that it's
supposed to stop, well, that's kinda why people stopped using sysv init.
It's really terrible.

I believe Roger said he's on Debian 11(?). The file list for the Deb12
package shows both an init.d script and a systemd unit file. <https://packages.debian.org/bookworm/amd64/fetchmail/filelist>

I don't know whether one of them is just a stub that acts as a wrapper
for the other, or whether they're both proper, full-fledged management
files for their respective init systems.

So, this might be a "bug already fixed in stable" kind of situation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 09:40:44 +0700, Max Nikulin wrote:

On 28/12/2024 23:47, Greg Wooledge wrote:

On Sat, Dec 28, 2024 at 17:21:08 +0100, Roger Price wrote:

root@titan ~ /etc/init.d/fetchmail --quit
Not starting fetchmail daemon, disabled via /etc/default/fetchmail.

The correct way to use a legacy sysv-rc init.d script to stop a service
is:

/etc/init.d/fetchmail stop

I do not have fetchmail installed, [...]

Yeah, that's the common problem here. Only the OP is using this package,
and apparently he's not on the current stable release.

My guess is that the main service process exited, but some its child (it belongs to service's cgroup) were continuing running for some reason. Unless improperly configured, systemd is able to kill all processes after some timeout. Perhaps something is wrong with service type, KillMode, or
timeouts.

Right. I had a similar guess (parent dies, children live on).

I looked at the file list for the oldstable package (the one I believe
Roger is using) at <https://packages.debian.org/bullseye/amd64/fetchmail/filelist> and
this one does NOT have a systemd unit file. As I've pointed out a
couple times now, that version of the package only has an init.d file.

So, there is no service type, there is no KillMode, and I'm not *aware*
of any kind of timeouts enforced by the init.d script. But I haven't
actually read it.

Anyway, I'm still going with the "init.d script failure, made irrelevant
in the stable release because now it has a systemd unit file" theory.
There's not much point trying to debug an init.d script in an oldstable release, when the stable release won't be using it (normally).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Unstable:

toncho/~ 20 systemctl cat fetchmail.service
# /run/systemd/generator.late/fetchmail.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fetchmail
Description=LSB: init-Script for system wide fetchmail daemon Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=network-online.target
After=remote-fs.target
After=mail-transport-agent.target
After=postfix.service
After=exim4.service
After=nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fetchmail start
ExecStop=/etc/init.d/fetchmail stop

--
John Hasler
john@sugarbit.com
Elmwood, WI USA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

On Sun, 29 Dec 2024, Max Nikulin wrote:

Commands that might help to discover what actually happened
journalctl -u fetchmail.service

Dec 28 10:37:58 titan systemd[1]: Stopping LSB: init-Script for system wide
fetchmail daemon...
Dec 28 10:37:58 titan fetchmail[1199929]: Not starting fetchmail daemon,
disabled via /etc/default/fetchmail.
Dec 28 10:37:58 titan systemd[1]: fetchmail.service: Succeeded.
Dec 28 10:37:58 titan systemd[1]: fetchmail.service: Unit process 1264
(fetchmail) remains running after unit stopped.
Dec 28 10:37:58 titan systemd[1]: Stopped LSB: init-Script for system wide
fetchmail daemon.
Dec 28 10:37:58 titan systemd[1]: fetchmail.service: Consumed 6min 32.376s CPU
time.
Dec 28 18:46:01 titan fetchmail[1264]: terminated with signal 15

Notice the surprising entry "(fetchmail) remains running after unit stopped." The final line is my command "kill 1264" which stopped fetchmail.

On Sat, 28 Dec 2024, Greg Wooledge wrote:

I looked at the file list for the oldstable package (the one I believe
Roger is using) at <https://packages.debian.org/bullseye/amd64/fetchmail/filelist> and
this one does NOT have a systemd unit file. As I've pointed out a
couple times now, that version of the package only has an init.d file.

So, there is no service type, there is no KillMode, and I'm not *aware*
of any kind of timeouts enforced by the init.d script.

I ran command diff on the Debian 11 and Debian 12 ouputs of dpkg -L fetchmail

22a23,26

/usr/lib
/usr/lib/systemd
/usr/lib/systemd/user
/usr/lib/systemd/user/fetchmail.service

31a36

/usr/share/doc/fetchmail/README.systemd

On Debian 12 the command systemctl status fetchmail now has a "CGroup" entry:

● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: active (running) since Sat 2024-12-28 10:46:38 CET; 22h ago
Docs: man:systemd-sysv-generator(8)
Process: 252241 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 38046)
Memory: 3.0M
CPU: 52.194s
CGroup: /system.slice/fetchmail.service
└─252255 /usr/bin/fetchmail -f /etc/fetchmail
--pidfile /var/run/fetchmail/fetchmail.pid --syslog

So I'm assuming that something in Debian 11 fetchmail was mismanaging the PIDs, and that that problem has been solved, although Debian 12 file /var/run/fetchmail/fetchmail.pid shows

252255
150

which contains a PID which does not agree with the Process: declaration in the systemctl output.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, December 28, 2024 6:56:09 PM CET, Roger Price wrote:

And the fetchma+ process disappeared - I hope it no longer
rises from the dead.

then make sure you run

systemctl disable fetchmail.service

otherwise it will start again at next boot.

greetings...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 29 Dec 2024, Michael wrote:

On Saturday, December 28, 2024 6:56:09 PM CET, Roger Price wrote:

And the fetchma+ process disappeared - I hope it no longer rises from the
dead.

then make sure you run
systemctl disable fetchmail.service
otherwise it will start again at next boot.

In /etc/default/fetchmail, I have
START_DAEMON=no

I assume this also prevents fetchmail from restarting. Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 29 Dec 2024, Michael wrote:

then make sure you run
systemctl disable fetchmail.service
otherwise it will start again at next boot.

Here is what happened when i tried "disable" on this Debian 11 machine.

root@titan ~ systemctl disable fetchmail
fetchmail.service is not a native service, redirecting to systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable fetchmail

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

pocket@homemail.com (12024-12-29):

ExecStart=/usr/bin/fetchmail --pidfile /run/fetchmail/fetchmailrc.pid -f /etc/fetchmailrc

Debian uses --nodetach, which is a much better use of modern service monitoring.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On Sun, Dec 29, 2024 at 02:16:42PM +0100, pocket@homemail.com wrote:

https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail

What is your point? There is a native systemd service unit for fetchmail
in the next release of Debian. Your constant off-topic proselytizing of
Arch here is unwelcome.

Regards,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Saturday, December 28, 2024 at 10:18 PM
From: "John Hasler" <john@sugarbit.com>
To: debian-user@lists.debian.org
Subject: Re: Correct way to stop fetchmail

On Unstable:

toncho/~ 20 systemctl cat fetchmail.service
# /run/systemd/generator.late/fetchmail.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fetchmail
Description=LSB: init-Script for system wide fetchmail daemon Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=network-online.target
After=remote-fs.target
After=mail-transport-agent.target
After=postfix.service
After=exim4.service
After=nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fetchmail start
ExecStop=/etc/init.d/fetchmail stop

https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail

Description=Fetchmail
After=network.target

[Service]
User=fetchmail
ExecStart=/usr/bin/fetchmail --pidfile /run/fetchmail/fetchmailrc.pid -f /etc/fetchmailrc
RestartSec=1

[Install]
WantedBy=multi-user.target

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 09:50:31 +0100, Roger Price wrote:

On Debian 12 the command systemctl status fetchmail now has a "CGroup" entry:

● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: active (running) since Sat 2024-12-28 10:46:38 CET; 22h ago
Docs: man:systemd-sysv-generator(8)
Process: 252241 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 38046)
Memory: 3.0M
CPU: 52.194s
CGroup: /system.slice/fetchmail.service
└─252255 /usr/bin/fetchmail -f /etc/fetchmail
--pidfile /var/run/fetchmail/fetchmail.pid --syslog

So I'm assuming that something in Debian 11 fetchmail was mismanaging the PIDs, and that that problem has been solved, although Debian 12 file /var/run/fetchmail/fetchmail.pid shows

252255
150

which contains a PID which does not agree with the Process: declaration in the systemctl output.

I'm assuming 252241 was the PID of the /etc/init.d/fetchmail shell
script, whereas 252255 is the PID of the /usr/bin/fetchmail daemon
launched by the init.d script. Note that the "Process:" line also
has "code=exited, status=0/SUCCESS". That's all perfectly normal for
an init.d script that launches either a background shell process, or
a daemon which forks its own child and then terminates its original
process to detach itself from the shell.

All of that forking and detaching nonsense and untracked child processes
are why people developed modern service managers (daemontools, runit,
systemd and so on).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 13:50:56 +0000, Andy Smith wrote:

Hello,

On Sun, Dec 29, 2024 at 02:16:42PM +0100, pocket@homemail.com wrote:

https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail

What is your point? There is a native systemd service unit for fetchmail
in the next release of Debian. Your constant off-topic proselytizing of
Arch here is unwelcome.

That's not how I perceived it. If Arch has a systemd unit file that
seems a lot more usable than the one we saw in Debian's packaging,
then Roger *might* want to try using the Arch unit file instead.
Obviously this is one of those "at your own risk" type of answers, but
it wasn't off-topic, and wasn't too much "proselytizing".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Dec 29, 2024 at 09:29:58AM -0500, Greg Wooledge wrote:

On Sun, Dec 29, 2024 at 13:50:56 +0000, Andy Smith wrote:

On Sun, Dec 29, 2024 at 02:16:42PM +0100, pocket@homemail.com wrote:

https://gitlab.archlinux.org/archlinux/packaging/packages/fetchmail

What is your point? There is a native systemd service unit for fetchmail
in the next release of Debian. Your constant off-topic proselytizing of Arch here is unwelcome.

That's not how I perceived it. If Arch has a systemd unit file that
seems a lot more usable than the one we saw in Debian's packaging,

Why would you not just look at the one in Debian testing right now?

Baffling to me.

Regards,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 29, 2024 at 22:44:56 +0700, Max Nikulin wrote:

John posted content of the service file *generated* for SysV init script.

Ahhhh. I missed that context.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)