I think I just ran into this problem. systemd-fsck seemed to be choking on a ~1.8T LVM volume with an ext3 filesytem - the volume's group is on an encrypted primary partion on a HDD. I'm running stretch.
Before attempting to remedy the problem: * systemd-fsck tried to run on the volume ever boot, * "systemd-analyze blame" told me systemd-fsck runs for ~4 min on the volume, which is not long enough to complete a check (I know from past checks), * "journalctl -u" systemd-fsckd.service told me nothing interesting, * tune2fs said the volume has not been checked since 15 Mar 2016, which supports the theory systemd-fsck is not completing. * systemd-fsck completes for all other volumes and disks (which are considerably smaller), so I'd guess it's a timeout issue. Before the 15 Mar 2016 everything worked fine, so this must have been caused by an update since then. Unfortunately I can't pin down a more precise start date, but I do have dpkg logs going back to the 15th so might be able to glean something from that. Setting TimeoutStartSec in /etc/systemd/system/systemd-fsckd.service to 0 and 480min did nothing. fsck ran fine while booting after running "systemctl mask > systemd-fsckd.service systemd-fsckd.socket"; tune2fs reported the volume had been checked and "systemd-analyze blame" gave a sane run time for systemd-fsck. - Aubrey Stark-Toller
