UGFja2FnZTogb3BlbnNzaC1jbGllbnQKVmVyc2lvbjogMToxMC4wcDEtMgpTZXZlcml0eTogaW1w b3J0YW50CgpTaW5jZSB0aGUgMToxMC4wcDEtMSDihpIgMToxMC4wcDEtMiB1cGdyYWRlLCB0aGUg dXNlciBzb2NrZXQgZm9yIHNzaC1hZ2VudAppcyBubyBsb25nZXIgY3JlYXRlZCBpbiAke1hER19S VU5USU1FX0RJUn0vb3BlbnNzaF9hZ2VudCwgYnV0IGF0IGFuCnVucHJlZGljdGFibGUgcGF0aCB1 bmRlciAvdG1wLgoKQXMgYW4gZXhhbXBsZSwgaGVyZSBpcyB3aGF0IGl0IGN1cnJlbnRseSB1c2Vz IG9uIG15IHN5c3RlbToKL3RtcC9zc2gtRXd0YktCNXF6QTZrL2FnZW50LjM5MzI0NjUKKHRoZSBw YXRoIGNoYW5nZXMgZWFjaCB0aW1lIHRoZSBzc2gtYWdlbnQgdXNlciBzZXJ2aWNlIGlzIHJlc3Rh cnRlZCkKClRoaXMgYnJlYWtzIHRoZSB1c2Ugb2YgY29tbWFuZHMgbGlrZSBzc2gtYWRkLCBhcyB0 aGV5IGNhbiBubyBsb25nZXIgZmluZAp0aGUgc29ja2V0LgoKVGhpcyBpcyBtb3N0IHByb2JhYmx5 IHJlbGF0ZWQgdG8gdGhlIGZpeCBmb3IgdGhlIGZvbGxvd2luZyBidWcgcmVwb3J0czoKLSBodHRw czovL2J1Z3MuZGViaWFuLm9yZy85NjEzMTEKLSBodHRwczovL2J1Z3MuZGViaWFuLm9yZy8xMDM5 OTE5Ci0gaHR0cHM6Ly9idWdzLmRlYmlhbi5vcmcvMTEwMzAzNwoKRm9yIG5vdyBpdCBjYW4gYmUg d29ya2VkIGFyb3VuZCBieSBkb3duZ3JhZGluZyBvcGVuc3NoLWNsaWVudAp0byB0aGUgVHJpeGll IHZlcnNpb24gKDE6OS45cDItMiksIGFuZCBvcGVuIHRoZSBzb2NrZXQgd2l0aDoKL3Vzci9saWIv b3BlbnNzaC9hZ2VudC1sYXVuY2ggc3RhcnQKCi0tIFN5c3RlbSBJbmZvcm1hdGlvbjoKRGViaWFu IFJlbGVhc2U6IHRyaXhpZS9zaWQKICBBUFQgcHJlZmVycyB1bnN0YWJsZS1kZWJ1ZwogIEFQVCBw b2xpY3k6ICg1MDAsICd1bnN0YWJsZS1kZWJ1ZycpLCAoNTAwLCAndGVzdGluZy1kZWJ1ZycpLCAo NTAwLCAnc3RhYmxlLWRlYnVnJyksICg1MDAsICdvbGRzdGFibGUtZGVidWcnKSwgKDUwMCwgJ3Vu c3RhYmxlJyksICg1MDAsICd0ZXN0aW5nJyksICg1MDAsICdzdGFibGUnKSwgKDUwMCwgJ29sZHN0 YWJsZScpLCAoMSwgJ2V4cGVyaW1lbnRhbC1kZWJ1ZycpLCAoMSwgJ2V4cGVyaW1lbnRhbCcpCkFy Y2hpdGVjdHVyZTogYW1kNjQgKHg4Nl82NCkKRm9yZWlnbiBBcmNoaXRlY3R1cmVzOiBpMzg2CgpL ZXJuZWw6IExpbnV4IDYuMTIuMTctYW1kNjQgKFNNUCB3LzggQ1BVIHRocmVhZHM7IFBSRUVNUFQp Cktlcm5lbCB0YWludCBmbGFnczogVEFJTlRfV0FSTgpMb2NhbGU6IExBTkc9ZnJfRlIuVVRGLTgs IExDX0NUWVBFPWZyX0ZSLlVURi04IChjaGFybWFwPVVURi04KSwgTEFOR1VBR0Ugbm90IHNldApT aGVsbDogL2Jpbi9zaCBsaW5rZWQgdG8gL3Vzci9iaW4vZGFzaApJbml0OiBzeXN0ZW1kICh2aWEg L3J1bi9zeXN0ZW1kL3N5c3RlbSkKTFNNOiBBcHBBcm1vcjogZW5hYmxlZAoKVmVyc2lvbnMgb2Yg cGFja2FnZXMgb3BlbnNzaC1jbGllbnQgZGVwZW5kcyBvbjoKaWkgIGFkZHVzZXIgICAgICAgICAg ICAgIDMuMTUwCmlpICBpbml0LXN5c3RlbS1oZWxwZXJzICAxLjY4CmlpICBsaWJjNiAgICAgICAg ICAgICAgICAyLjQxLTcKaWkgIGxpYmVkaXQyICAgICAgICAgICAgIDMuMS0yMDI1MDEwNC0xCmlp ICBsaWJmaWRvMi0xICAgICAgICAgICAxLjE1LjAtMStiMQppaSAgbGliZ3NzYXBpLWtyYjUtMiAg ICAgMS4yMS4zLTUKaWkgIGxpYnNlbGludXgxICAgICAgICAgIDMuOC4xLTEKaWkgIGxpYnNzbDN0 NjQgICAgICAgICAgIDMuNS4wLTEKaWkgIHBhc3N3ZCAgICAgICAgICAgICAgIDE6NC4xNy40LTEK aWkgIHpsaWIxZyAgICAgICAgICAgICAgIDE6MS4zLmRmc2crcmVhbGx5MS4zLjEtMStiMQoKVmVy c2lvbnMgb2YgcGFja2FnZXMgb3BlbnNzaC1jbGllbnQgcmVjb21tZW5kczoKaWkgIHhhdXRoICAx OjEuMS4yLTEuMQoKVmVyc2lvbnMgb2YgcGFja2FnZXMgb3BlbnNzaC1jbGllbnQgc3VnZ2VzdHM6 CnBuICBrZXljaGFpbiAgICAgIDxub25lPgpwbiAgbGlicGFtLXNzaCAgICA8bm9uZT4KcG4gIG1v bmtleXNwaGVyZSAgPG5vbmU+CnBuICBzc2gtYXNrcGFzcyAgIDxub25lPgoKLS0gbm8gZGViY29u ZiBpbmZvcm1hdGlvbgo=

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

On Fri, Apr 18, 2025 at 04:26:36PM +0200, Antoine Le Gonidec wrote:

Since the 1:10.0p1-1 → 1:10.0p1-2 upgrade, the user socket for ssh-agent
is no longer created in ${XDG_RUNTIME_DIR}/openssh_agent, but at an >unpredictable path under /tmp.

As an example, here is what it currently uses on my system: >/tmp/ssh-EwtbKB5qzA6k/agent.3932465
(the path changes each time the ssh-agent user service is restarted)

This breaks the use of commands like ssh-add, as they can no longer find
the socket.

This is most probably related to the fix for the following bug reports:
- https://bugs.debian.org/961311
- https://bugs.debian.org/1039919
- https://bugs.debian.org/1103037

For now it can be worked around by downgrading openssh-client
to the Trixie version (1:9.9p2-2), and open the socket with: >/usr/lib/openssh/agent-launch start

Surprising, since the systemd unit uses ListenStream=%t/openssh_agent
and sets SSH_AUTH_SOCK in the systemd environment. Daniel, could you
please have a look at this, since it was your change?

Thanks,

--
Colin Watson (he/him) [cjwatson@debian.org]

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

Hi Antoine--

On Fri 2025-04-18 16:26:36 +0200, Antoine Le Gonidec wrote:

Since the 1:10.0p1-1 → 1:10.0p1-2 upgrade, the user socket for ssh-agent
is no longer created in ${XDG_RUNTIME_DIR}/openssh_agent, but at an unpredictable path under /tmp.

Can you share the output of the following command (run as your normal
user):

systemctl --user cat ssh-agent.socket ssh-agent.service


Here's what i'm seeing on my system:

```
0 dkg@bob:~$ systemctl --user cat ssh-agent.socket ssh-agent.service
# /usr/lib/systemd/user/ssh-agent.socket
[Unit]
Description=OpenSSH Agent socket
Documentation=man:ssh-agent(1)
Before=graphical-session-pre.target

[Socket]
SocketMode=0600
ListenStream=%t/openssh_agent
ExecStartPost=/usr/bin/systemctl --user set-environment SSH_AUTH_SOCK=%t/openssh_agent
ExecStopPre=/usr/bin/systemctl --user unset-environment SSH_AUTH_SOCK

[Install]
WantedBy=sockets.target

# /usr/lib/systemd/user/ssh-agent.service
[Unit]
Description=OpenSSH Agent
Documentation=man:ssh-agent(1)

[Service]
Environment=SSH_ASKPASS_REQUIRE=force
# If you need to pass extra arguments to ssh-agent, you can use "systemctl
# --user edit ssh-agent.service" to add a drop-in unit with contents along
# these lines:
# [Service]
# ExecStart=
# ExecStart=/usr/bin/ssh-agent -D -t 1200
ExecStart=/usr/bin/ssh-agent -D
0 dkg@bob:~$
```

If your output looks the same as above, can you share the output of:

systemctl --user status ssh-agent.socket ssh-agent.service

That would let me see what your local process supervisor believes is
going on with this service.

(the path changes each time the ssh-agent user service is restarted)

How are you restarting the ssh-agent user service?

Regards,

--dkg

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCaBvb+AAKCRB4C4VO2cK0 lhBJAP4vhqFDgKbnW8qrgSqbl7GyeP3JBDNHVUJeBlgH4DZRfgD8CPDI7vaTqIn2 8YHKXQ7ASwR3GhYQ3APm7n4l/3Vj2gI=ATR5
-----END PGP SIGNATURE-----

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

Can you share the output of the following command (run as your normal
user):

systemctl --user cat ssh-agent.socket ssh-agent.service

I get the exact same output as yours, no local overrides here.

If your output looks the same as above, can you share the output of:

systemctl --user status ssh-agent.socket ssh-agent.service

That would let me see what your local process supervisor believes is
going on with this service.

○ ssh-agent.socket - OpenSSH Agent socket
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.socket; enabled; preset: enabled) Active: inactive (dead)
Triggers: ● ssh-agent.service
Docs: man:ssh-agent(1)
Listen: /run/user/1000/openssh_agent (Stream)

× ssh-agent.service - OpenSSH Agent
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static)
Active: failed (Result: exit-code) since Fri 2025-04-18 16:26:54 CEST; 2 weeks 5 days ago Duration: 18min 13.762s
Invocation: 9e8c3dc015d64454810ba837d4433547
TriggeredBy: ○ ssh-agent.socket
Docs: man:ssh-agent(1)
Main PID: 3932465 (code=exited, status=2)
Mem peak: 1.9M
CPU: 24ms

How are you restarting the ssh-agent user service?

I used to restart it with:
systemctl --user restart ssh-agent.service

But since I got bitten by the behaviour I reported, I stopped using the systemd unit and now start the agent directly from my user ~/.profile:

# Start SSH agent
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}/openssh_agent"
if [ ! -e "$SSH_AUTH_SOCK" ]; then
ssh-agent -a "$SSH_AUTH_SOCK" >/dev/null
fi

For debugging purposes, I can disable that temporarily and get back to the systemd unit, maybe try to get more debug output from it.

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSUsdxM90hewW6X7Jhja3j5HOuA2AUCaBvjxAAKCRBja3j5HOuA 2BUIAP9MHX6xTAGzO3CGNs84eRKZ6flHdmlj7rMzYdLm/YX/pwEA9bVLBgU710hJ 0ISiuzmMtAQZbyA69zOJ+t3CF2TP3gw=
=54TA
-----END PGP SIGNATURE-----

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

Hi Antoine--

On Thu 2025-05-08 00:50:44 +0200, Antoine Le Gonidec wrote:

Can you share the output of the following command (run as your normal
user):

systemctl --user cat ssh-agent.socket ssh-agent.service

I get the exact same output as yours, no local overrides here.

great, thanks for confirming.

If your output looks the same as above, can you share the output of:

systemctl --user status ssh-agent.socket ssh-agent.service

That would let me see what your local process supervisor believes is
going on with this service.

○ ssh-agent.socket - OpenSSH Agent socket
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.socket; enabled; preset: enabled) Active: inactive (dead)
Triggers: ● ssh-agent.service
Docs: man:ssh-agent(1)
Listen: /run/user/1000/openssh_agent (Stream)

× ssh-agent.service - OpenSSH Agent
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static)
Active: failed (Result: exit-code) since Fri 2025-04-18 16:26:54 CEST; 2 weeks 5 days ago Duration: 18min 13.762s
Invocation: 9e8c3dc015d64454810ba837d4433547
TriggeredBy: ○ ssh-agent.socket
Docs: man:ssh-agent(1)
Main PID: 3932465 (code=exited, status=2)
Mem peak: 1.9M
CPU: 24ms

OK, this is just telling me that you aren't using the systemd unit any
more, right?

How are you restarting the ssh-agent user service?

I used to restart it with:
systemctl --user restart ssh-agent.service

Under what circumstances would you need to do this? I'm not saying it's
wrong (it should be fine!), i'm just trying to replicate the
circumstances you found yourself in.

side note: with stock openssh, asking systemctl to restart ssh-agent
will produce a warning in the logs because ssh-agent will terminate with
a non-zero error code when asked to stop by systemd. This isn't
actually a problem, but it looks scary in the journal. I've asked
upstream to clean this up:

https://github.com/openssh/openssh-portable/pull/565

I don't think it will have any effect on what you're seeing, though.

But since I got bitten by the behaviour I reported, I stopped using the systemd
unit and now start the agent directly from my user ~/.profile:

# Start SSH agent
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}/openssh_agent" if [ ! -e "$SSH_AUTH_SOCK" ]; then
ssh-agent -a "$SSH_AUTH_SOCK" >/dev/null
fi

For debugging purposes, I can disable that temporarily and get back to the systemd unit, maybe try to get more debug output from it.

Yes, please do try to disable that and see what you can replicate. that
would be great! I'm unable to trigger the problem you described
directly myself with the information we have so far.

--dkg


--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCaBy5/wAKCRB4C4VO2cK0 lvjSAP0Y8eyzPVB0mEDnJdszEpuL0tp2SzYDxOYy2b8EV+B3mwD/bPxN1K6Lruf+ Dj2sXIAS2I+EkOkSPuVASWdiGgGh/AQ=gneQ
-----END PGP SIGNATURE-----

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

If your output looks the same as above, can you share the output of:

systemctl --user status ssh-agent.socket ssh-agent.service

That would let me see what your local process supervisor believes is
going on with this service.

○ ssh-agent.socket - OpenSSH Agent socket
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.socket; enabled; preset: enabled) Active: inactive (dead)
Triggers: ● ssh-agent.service
Docs: man:ssh-agent(1)
Listen: /run/user/1000/openssh_agent (Stream)

× ssh-agent.service - OpenSSH Agent
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static)
Active: failed (Result: exit-code) since Fri 2025-04-18 16:26:54 CEST; 2 weeks 5 days ago Duration: 18min 13.762s
Invocation: 9e8c3dc015d64454810ba837d4433547
TriggeredBy: ○ ssh-agent.socket
Docs: man:ssh-agent(1)
Main PID: 3932465 (code=exited, status=2)
Mem peak: 1.9M
CPU: 24ms

OK, this is just telling me that you aren't using the systemd unit any
more, right?

Here is what I did to disable my non-systemd-managed agent and run it again through systemd:
killall ssh-agent
systemctl --enable ssh-agent.service ssh-agent.socket
systemctl --user start ssh-agent.service

Here is the new output of `systemctl --user status ssh-agent.socket ssh-agent.service`:

○ ssh-agent.socket - OpenSSH Agent socket
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.socket; enabled; preset: enabled)
Active: inactive (dead)
Triggers: ● ssh-agent.service
Docs: man:ssh-agent(1)
Listen: /run/user/1000/openssh_agent (Stream)

● ssh-agent.service - OpenSSH Agent
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static)
Active: active (running) since Thu 2025-05-08 17:11:05 CEST; 2min 9s ago
Invocation: 4f8408f214414c46b1b5c1bac906a5cf
TriggeredBy: ○ ssh-agent.socket
Docs: man:ssh-agent(1)
Main PID: 3227523 (ssh-agent)
Tasks: 1 (limit: 21468)
Memory: 1.1M (peak: 2M)
CPU: 23ms
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service
└─3227523 /usr/bin/ssh-agent -D

How are you restarting the ssh-agent user service?

I used to restart it with:
systemctl --user restart ssh-agent.service

Under what circumstances would you need to do this? I'm not saying it's wrong (it should be fine!), i'm just trying to replicate the
circumstances you found yourself in.

I only run that command when the agent is not running for some reason, like what looked like a failure following the upgrade we are discussing. (it was not a real failure, it’s only that the socket was no longer found where I expected
it to be)

But since I got bitten by the behaviour I reported, I stopped using the systemd unit and now start the agent directly from my user ~/.profile:

# Start SSH agent
export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR:-/run/user/$(id -u)}/openssh_agent" if [ ! -e "$SSH_AUTH_SOCK" ]; then
ssh-agent -a "$SSH_AUTH_SOCK" >/dev/null
fi

For debugging purposes, I can disable that temporarily and get back to the systemd unit, maybe try to get more debug output from it.

Yes, please do try to disable that and see what you can replicate. that would be great! I'm unable to trigger the problem you described
directly myself with the information we have so far.

Following the actions I listed above (disabling my workaround, re-enabling and starting the systemd user units), I once again ended up with the socket created in an unexpected path:
/tmp/ssh-Qyd6hMtI8ivT/agent.3227523

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSUsdxM90hewW6X7Jhja3j5HOuA2AUCaBzLLgAKCRBja3j5HOuA 2DPrAP0aCpF/GpWL94RmYRktVet+/J0WOk2Ysx1JsYymYq8xyAD/aPYQQqtKOPxy LeAscFF4XcipYMQpZIwC56GCPWW9dws=
=a17q
-----END PGP SIGNATURE-----

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

On Thu, May 08, 2025 at 04:40:22PM -0400, Daniel Kahn Gillmor wrote:

To fix this use case, we just need to tell systemd that any manual
attempt to start the ssh-agent service needs to ensure that the socket
is listening first.

We can do this with the following patch to the OpenSSH package's >ssh-agent.service file:

diff --git a/debian/systemd/ssh-agent.service b/debian/systemd/ssh-agent.service
index 72e0a3e46..19ea47c91 100644
--- a/debian/systemd/ssh-agent.service
+++ b/debian/systemd/ssh-agent.service
@@ -1,6 +1,8 @@
[Unit]
Description=OpenSSH Agent
Documentation=man:ssh-agent(1)
+Requires=ssh-agent.socket
+After=ssh-agent.socket

[Service]
Environment=SSH_ASKPASS_REQUIRE=force

I think After= is unnecessary. systemd.socket(5) says (bearing in mind
that Before= and After= are inverses, as one might expect from their
names):

Socket units automatically gain a Before= dependency on the service
units they activate.

But adding just Requires= on its own sounds reasonable. I'll wait for confirmation from Antoine that that works, but if so then I'm willing to
try to get this into trixie.

--
Colin Watson (he/him) [cjwatson@debian.org]

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

Control: tags 1103522 + patch

Ah, thanks, i think i understand what is going on now! I was able to
replicate the problem.

Here is what I did to disable my non-systemd-managed agent and run it again through systemd:
killall ssh-agent
systemctl --enable ssh-agent.service ssh-agent.socket
systemctl --user start ssh-agent.service

You're starting the service, when what i think you really want to start
is the socket.

For socket-activated services, the most important thing is to have the
socket listening; when someone connects to it, systemd will the correct service.

By default, the socket is activated automatically (it ships enabled), so
most people wouldn't have run into this problem. But, if the socket was somehow not running (perhaps on package upgrade?) then just manually
starting the service will fail because the .service unit is designed to
work when the socket is active.

And what you did ("systemctl --user start ssh-agent.service") is also a
totally reasonable thing to do (especially for people used to managing non-socket-activated services).

To fix this use case, we just need to tell systemd that any manual
attempt to start the ssh-agent service needs to ensure that the socket
is listening first.

We can do this with the following patch to the OpenSSH package's ssh-agent.service file:

diff --git a/debian/systemd/ssh-agent.service b/debian/systemd/ssh-agent.service
index 72e0a3e46..19ea47c91 100644
--- a/debian/systemd/ssh-agent.service
+++ b/debian/systemd/ssh-agent.service
@@ -1,6 +1,8 @@
[Unit]
Description=OpenSSH Agent
Documentation=man:ssh-agent(1)
+Requires=ssh-agent.socket
+After=ssh-agent.socket

[Service]
Environment=SSH_ASKPASS_REQUIRE=force


You can test this if you like by dropping a file with this contents into ~/.config/systemd/user/ssh-agent.service.d/override.conf :

```
# Added while debugging https://bugs.debian.org/1103522
[Unit]
Requires=ssh-agent.socket
After=ssh-agent.socket
```

Then do:

systemctl --user daemon-reload
systemctl --user restart ssh-agent.service

And you should see that the socket is up and the agent is listening on
the appropriate socket.

If this solves your scenario, please let me know!

(and, don't forget to remove the override.conf once we've resolved the
bug in the debian package)

Thanks for bearing with me on the debugging!

--dkg

--=-=-Content-Type: application/pgp-signature; name="signature.as

We can do this with the following patch to the OpenSSH package's ssh-agent.service file:

diff --git a/debian/systemd/ssh-agent.service b/debian/systemd/ssh-agent.service index 72e0a3e46..19ea47c91 100644
--- a/debian/systemd/ssh-agent.service
+++ b/debian/systemd/ssh-agent.service
@@ -1,6 +1,8 @@
[Unit]
Description=OpenSSH Agent
Documentation=man:ssh-agent(1)
+Requires=ssh-agent.socket
+After=ssh-agent.socket

[Service]
Environment=SSH_ASKPASS_REQUIRE=force

You can test this if you like by dropping a file with this contents into ~/.config/systemd/user/ssh-agent.service.d/override.conf :

```
# Added while debugging https://bugs.debian.org/1103522
[Unit]
Requires=ssh-agent.socket
After=ssh-agent.socket
```

Then do:

systemctl --user daemon-reload
systemctl --user restart ssh-agent.service

And you should see that the socket is up and the agent is listening on
the appropriate socket.

Well spotted, this does indeed fix the behaviour I was experiencing!

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSUsdxM90hewW6X7Jhja3j5HOuA2AUCaB0xsgAKCRBja3j5HOuA 2BQzAQDu486j1mTOanccDbgJGyj/bXsKktFz9MRfjjddLfdfhwEAmIrioEPhTsE9 2MR1/sqMXjqxFyfVMGZLIpT+0+SOBQg=
=n2zr
-----END PGP SIGNATURE-----

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

On Thu 2025-05-08 22:32:11 +0100, Colin Watson wrote:

I think After= is unnecessary. systemd.socket(5) says (bearing in mind
that Before= and After= are inverses, as one might expect from their
names):

Socket units automatically gain a Before= dependency on the service
units they activate.

But adding just Requires= on its own sounds reasonable. I'll wait for confirmation from Antoine that that works, but if so then I'm willing to
try to get this into trixie.

Makes sense to me. And the more parsimonious the change the better.
Thanks for the improvement, Colin!

--dkg

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCaB4QJgAKCRB4C4VO2cK0 lmHAAQC0dkGUOtWxb1gKV/eQGI6maUv9ul9/nxJTgoTLyhCZ0AD/fXLVMncLpEcd V9XwCnFz3UjWfvuv73oXc1psAbJTWQ4nw
-----END PGP SIGNATURE-----

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