Bug#1004687: systemd: When NFS filesystems are mounted, systemctl actions (ex: daemon-reload) are exceedingly slow

Michael Biebl

unread,

Jan 31, 2022, 5:10:04 PM1/31/22

to

Control: tags -1 moreinfo unreproducible

Am 31.01.22 um 20:15 schrieb Brandon Applegate:
> Package: systemd
> Version: 247.3-6
> Severity: normal
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
>
> Installed fresh Bullseye (amd64). At some point experienced extreme delay with systemctl operations.
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> Increased systemd log level to debug. Through trial and error determined unmounting all NFS alleviates this condition.
>
> * What was the outcome of this action?
>
> "systemctl daemon-reload" can now be ran normally with no delay.
>

This sounds like an issue with your NFS setup.
Calling systemctl will cause NFS mounts to be stated, but that shouldn't
take too long.
In a test bed here I couldn't reproduce the problem.
Thus marking accordingly.

Please provide more information how this issue can be reproduced.

Michael

OpenPGP_signature

Brandon Applegate

unread,

Jan 31, 2022, 5:40:04 PM1/31/22

to

Hello,

It could be. I will tell you though that for what it’s worth, up until about a week ago this machine ran Debian 9, and the NFS server setup was exactly the same. Never had this issue at all.

I don’t have any errors in logs on the NFS server side (TueNAS (nee: FreeNAS) by the way). The only thing close to an NFS related error I have on the Debian client side are a few nfsidmap nss_getpwnam errors when initially mounting.

One other thing I think I will try is to mount these rw. I’ve had them mounted ro forever (by design). Just wondering if something is unhappy about them being ro.

signature.asc

Brandon Applegate

unread,

Jan 31, 2022, 7:10:03 PM1/31/22

to

Mounting as rw didn’t seem to help. Shortly after that - a random try of “systemctl reload-daemon” resulted in the same hang/delay. I noticed again that the systed fstab generator was running. I managed to strace it (missed the beginning of course) - and it was hanging. Eventually I got this:

strace: Process 56818 attached
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=56808, si_uid=0} ---
+++ killed by SIGTERM +++

I’m guessing it wasn’t responding so systemd killed it ?

Is there anything else I can do to try to troubleshoot this ?

signature.asc

Michael Biebl

unread,

Jul 5, 2022, 1:30:03 PM7/5/22

to

On Mon, 31 Jan 2022 19:03:49 -0500 Brandon Applegate <bra...@burn.net>
wrote:

Brandon,

this doesn't appear to be a Debian specific issue.
Could you please install systemd v250 from bullseye-backports and test
if the problem is still reproducible.

If so, I would kindly ask you to file the issue upstream at
https://github.com/systemd/systemd/issues/new

Michael

OpenPGP_signature

Brandon Applegate

unread,

Jul 5, 2022, 3:40:03 PM7/5/22

to

Well now I can’t even reproduce it on the original system. Grrr.

You can close this if you need to. If I hit this again, I will try pulling in newer systemd from backports as you suggest and file an upstream bug if need be.

Thanks.

--

Brandon Applegate - CCIE 10273

PGP Key fingerprint:

0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A

"For thousands of years men dreamed of pacts with demons.

Only now are such things possible."

signature.asc