#1059270 e2fsprogs: e2scrub_reap.service triggers mount of nfs home before network is ready causing loop

Package:
e2fsprogs
Source:
e2fsprogs
Description:
ext2/ext3/ext4 file system utilities
Submitter:
Rike-Benjamin Schuppner
Date:
2023-12-22 10:51:03 UTC
Severity:
normal
#1059270#5
Date:
2023-12-22 10:39:26 UTC
From:
To:
Dear Maintainer,

we run a system with the /home folder living in a remote nfs server.
After upgrading to Debian 12, we noticed boot failures that were
apparently caused by the e2scrub_reap.service as this service triggers
an automount

    home.automount: Got automount request for /home, triggered by 924 ((crub_all))

which then, after a few minutes of waiting for timeouts, causes a few
other services to fail:

   mount.nfs4: Network is unreachable
   home.mount: Mount process exited, code=exited, status=32/n/a
   home.mount: Failed with result 'exit-code'.
   Failed to mount home.mount - /home.
   systemd-logind.service: Failed to set up mount namespacing: /run/systemd/unit-root/home: No such device
   systemd-logind.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-logind: No such device
   NetworkManager.service: Failed to set up mount namespacing: /run/systemd/unit-root/home: No such device
   NetworkManager.service: Failed at step NAMESPACE spawning /usr/sbin/NetworkManager: No such device
   Reached target remote-fs.target - Remote File Systems.
   chrony.service: Failed to set up mount namespacing: /run/systemd/unit-root/home: No such device
   chrony.service: Failed at step NAMESPACE spawning /usr/sbin/chronyd: No such device

While the system appears to be usable, systemd shows the services as
having failed, and of course the few minutes of boot delay is also
something that we would like to avoid.


The fix that worked for us was to change the service setting in e2scrub_reap.service from
ProtectHome=read-only to

     [Service]
     ProtectHome=yes

which does not trigger the automount system.