Package: quota Version: 4.04-2+deb10u1 Architecture: amd64 Severity: normal Tags: patch X-Debbugs-CC: d.fil...@web.de
I created a new filesystem and specified to use quota in /etc/fstab,
but didn't run quotacheck -c as I expected this to happen anyway on
reboot. However, systemd's unit quotaon.service failed with:
quotaon[883]: quotaon: cannot find /path/to/filesystem/aquota.group on
/dev/mapper/vg-lv [/path/to/filesystem]
quotaon[883]: quotaon: cannot find /path/to/filesystem/aquota.user on
/dev/mapper/vg-lv [/path/to/filesystem]
systemd[1]: quotaon.service: Main process exited, code=exited,
status=2/INVALIDARGUMENT
I know that during boot /usr/share/quota/quota-initial-check.sh should
have been invoked through quota.service to fix that, but running
"systemctl is-enabled quota.service" prints "disabled" (this is on a
system installed from DVD, so no upgrade logic was ever involved).
Running "systemctl preset quota.service" then created the symlink
/etc/systemd/system/sysinit.target.wants/quota.service to
/lib/systemd/system/quota.service. If the vendor preset for
quota.service is "enabled" then that symlink should have been created
during package installation, no? Otherwise the preset should be
changed to "disabled" and README.Debian should explain why it is not
enabled by default.
I know with absolute certainty that I never deleted that symlink. My
etckeeper logs don't show it either for the commit made when
installing "quota" and "quotatool":
# etckeeper vcs show --name-only 86e432a|grep quota
+quota 4.04-2+deb10u1 amd64
+quotatool 1:1.6.2-5 amd64
cron.daily/quota
default/quota
init.d/quota
init.d/quotarpc
quotagrpadmins
quotatab
warnquota.conf
Running the following command prints nothing either:
find /var/lib/systemd/deb-systemd-helper-enabled -name '*quota*'
Maybe you forgot to call deb-systemd-helper/dh_systemd_enable in a
maintscript?
After enabling quota.service manually and rebooting, the service
started, but the quota files were still not created. There is a file
/var/lib/quota/new whose creation date is equal to that of the
etckeeper commit from installing quota, but
/usr/share/quota/quota-initial-check.sh should have deleted it long
ago. I think quota.service needs an After= in its Unit section on
either var.mount or local-fs.target, otherwise /var/lib/quota/new has
no effect if /var is a mountpoint (which it is in my case) and mounted
after quota.service has run. With that change in place the quota
files were created correctly on the next reboot.
Of course, one could also argue that it is the user's obligation to
ensure correct ordering here as he's the one controlling the mount
units, but that approach doesn't scale well since most mount units are
generated from /etc/fstab. Adding an After=local-fs.target sounds
like the best solution to me personally as it ensures that mountpoints
defined in /etc/fstab have been established. Non-generated mount
units will need to specify an explicit Before=quota.service which they
easily can, thus making this a reasonable demand.
The attached patch also adds some checks to quota-initial-check.sh to
make troubleshooting easier, but you may have to adjust it a bit.
Regards,
Dennis.
N.B.: Looking at quotarpc.service I wonder if the Wants= on
rpcbind.service should actually be a BindsTo= instead, or can
rpc.rquotad function at all without rpcbind? The rpcbind manpage
says: "All RPC servers must be restarted if rpcbind is restarted." If
you decide to switch to a BindsTo= then
ConditionFileIsExecutable=/sbin/rpcbind should be dropped as well as
it would either occlude or duplicate the dependency relation between
both units.
quota.patch.gz
Description: application/gzip
