Comment 3 for bug 1860676

Hmm... I can't duplicate this on Debian testing, which is using a newer version of e2fsprogs (1.45.5-2). The e2scrub_reap.service file is identical with Ubuntu's 1.45.3-4ubuntu2.1, though. And looking at the service file, I have no idea why systemctl would be trying to paskk for a password, given that it is running as root.

<tytso@lambda> {/home/tytso}
1046% sudo systemctl restart e2scrub_reap.service
[sudo] password for tytso:
<tytso@lambda> {/home/tytso}
1047% sudo systemctl status e2scrub_reap.service
● e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots
     Loaded: loaded (/lib/systemd/system/e2scrub_reap.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Fri 2020-01-24 22:20:55 EST; 3s ago
       Docs: man:e2scrub_all(8)
    Process: 1106527 ExecStart=/sbin/e2scrub_all -A -r (code=exited, status=0/SUCCESS)
   Main PID: 1106527 (code=exited, status=0/SUCCESS)

Jan 24 22:20:55 lambda systemd[1]: Starting Remove Stale Online ext4 Metadata Check Snapshots...
Jan 24 22:20:55 lambda systemd[1]: e2scrub_reap.service: Succeeded.
Jan 24 22:20:55 lambda systemd[1]: Started Remove Stale Online ext4 Metadata Check Snapshots.

It is true that /sbin/e2scrub_all has changed significantly between 1.45.3 and 1.45.5; but it looked like you never got as far as actually executing e2scrub_reap.service, and if it did, it shouldn't be calling systemctl in reap mode.

Does "sudo /sbin/e2scrub_all -A -r" hang for you?

The only other thing which you might try i, commenting out this line from /lib/systemd/system/e2scrpb_reap.service, and see if it fixes the hang:

AmbientCapabilities=CAP_SYS_ADMIN CAP_SYS_RAWIO

If it does, I have no idea why it might be working for me using Debian testing (which is using systemd 244-3) and why it ight be failing for you with Ubuntu. Remember, systemd is your *friend*. It is the best init replacement compared to all the others. All Hail Systemd! :-/