Bug 736360 - FIXED_IN_GIT: Systemd does not run 'quotacheck' nor 'quotaon'
Summary: FIXED_IN_GIT: Systemd does not run 'quotacheck' nor 'quotaon'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-07 13:41 UTC by Bert DeKnuydt
Modified: 2013-03-15 00:54 UTC (History)
8 users (show)

Fixed In Version: systemd-26-10.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-30 18:53:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 921806 0 unspecified CLOSED quotaon not called when quotas are set for the root file system in /etc/fstab 2021-02-22 00:41:40 UTC

Internal Links: 921806

Description Bert DeKnuydt 2011-09-07 13:41:39 UTC
Description of problem:

Apparently, there is nothing working in Fedora 15's systemd to run quotacheck 
/quotaon on filesystems that are quota-enabled in /etc/fstab.

There is apparently a quotacheck.service and a quotaon.service
but they are not run by default, and you cannot enable them,
(returns 'Unit files contain no applicable installation 
information. Ignoring.')

Version-Release number of selected component (if applicable):

systemd-26-9.fc15.x86_64
quota-4.00-0.14.pre1.fc15.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Add ',quota' to a local FS's flags in /etc/fstab
2. Run once 'quotacheck -c' to generate the quotafiles.
3. Reboot; and see with 'quotaon -pa' that quota are NOT activated
   (and not checked neither)
  
Actual results:

Quota not activated (nor checked)

Expected results:

Fedora 14 behavior: quota enabled 'automatically'.

(Or, if that is impossible/unwanted, documentation that says it needs 
to be done manually in e.g. /etc/rc.local)

Additional info:

*) Poor man's workaround is e.g. adding in /etc/rc.local:
    
   systemctl start quotacheck.service quotaon.service
 
*) Actually, the entries in for the services quota{check,on}.service in 
   /lib/systemd/system, are not really correct, as they check/enable
   with flag 'a' all _automatically mounted_ FSs; but what about FS that are 
   mounted only on demand through systemd.automount?

Comment 1 Michal Schmidt 2011-09-07 14:31:09 UTC
src/mount.c:mount_add_default_dependencies() pulls quotacheck.service and quotaon.service if the mount options contain "usrquota" or "grpquota".

Comment 2 Lennart Poettering 2011-09-19 23:12:17 UTC
Hmm, systemd only knows about "usrquota" and "grpquota". You appear to be using "quota" instead. We could definitely add support for that switch too, but I can't find any documentation for that. Can you point me to some?

Comment 3 Lennart Poettering 2011-09-19 23:15:11 UTC
(In reply to comment #0)

> *) Actually, the entries in for the services quota{check,on}.service in 
>    /lib/systemd/system, are not really correct, as they check/enable
>    with flag 'a' all _automatically mounted_ FSs; but what about FS that are 
>    mounted only on demand through systemd.automount?

Well quota is generally incompatible with dynamically mounted file systems, since the quota checker runs when the fs is already mounted and we cannot make sure that no other app accesses the fs while doing so -- except if we run this at boot. But when apps modify the fs while the checker is still running the gathered checker information will be necessarily out of date.

btrfs does quota without any quota checkers, things will work fine there without any issues.

Comment 4 Bert DeKnuydt 2011-09-20 12:59:16 UTC
As to comment #2:

I don't know of any authoritative source but 'quota' has been an
alias for 'usrquota' for a long time. It might be deprecated though.
Apart from 'usrquota' and 'grpquota' also the journaled versions 
'usrjquota' and 'grpjquota'.  For these 'quotacheck' does not to be run, but 'quotaon' does.

BTW: If I remember well, I tried with 'usrquota' iso 'quota' and systemd 
reacted in exactly the same way: not running quotaon.

As to comment #3:

There is indeed a window-of-opportunity to do things between the mounting of a fs en the 'quotaon'.  It would be more logical of these operations could be done
atomically; but ext4 will be around for a long time I guess. So why not try
and not break the quota system unnecessarily, i.e. 'quotacheck' (if need be) and
'quotaon' asap after mount?

Comment 5 Lennart Poettering 2011-09-21 18:23:04 UTC
systemd git will now also look for "quota" in addition to "usrquota" and "grpquota".

> BTW: If I remember well, I tried with 'usrquota' iso 'quota' and systemd 
> reacted in exactly the same way: not running quotaon.

Please retry and file a separate bug about that.
> As to comment #3:
> 
> There is indeed a window-of-opportunity to do things between the mounting of a
> fs en the 'quotaon'.  It would be more logical of these operations could be
> done
> atomically; but ext4 will be around for a long time I guess. So why not try
> and not break the quota system unnecessarily, i.e. 'quotacheck' (if need be)
> and
> 'quotaon' asap after mount?

Well, it's not that we are breaking anything here. Traditionally quotacheck was run once at boot up for everything that was mounted at boot. And that's exactly what we do now too. Automatic quota checks for hotplug stuff never existed and we won't add it either. Replacing broken behaviour by behaviour that is just broken in a different way doesn't really help much I'd say.

Comment 6 Fedora Update System 2011-09-23 17:06:04 UTC
systemd-36-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-36-2.fc16

Comment 7 Fedora Update System 2011-09-24 20:48:46 UTC
Package systemd-36-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-36-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/systemd-36-2.fc16
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2011-09-25 23:29:50 UTC
systemd-26-10.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/systemd-26-10.fc15

Comment 9 Fedora Update System 2011-09-26 23:27:08 UTC
Package systemd-26-10.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-26-10.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/systemd-26-10.fc15
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2011-09-30 18:52:22 UTC
systemd-36-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2011-10-05 03:53:04 UTC
systemd-26-10.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.