(In reply to comment #0)
> Steps to Reproduce:
> 1. setup your device, mount it with quota enabled like
> /tmp/tmp.CGIWazevOe/bz77871.img on /tmp/tmp.CGIWazevOe/bz77871 type ext2
> (rw,loop=/dev/loop0,usrquota,quota)
                               ^^^^^
Here you have quotas already enabled. You cannot run quotaon on file system with already enabled quotas.

However this is line from /etc/mtab which quota tools do not use if proc FS is available. They parse /proc/mounts instead because /etc/mtab is damaged by mount(8) usually.

> 2. quotacheck -c /tmp/tmp.CGIWazevOe/bz77871
> ls -l /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> 
> 3. set some quota parameters - I  have:
> setquota bz77871 128 256 0 0 /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> setquota -t 3600 0 /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> 
These commands cannot pass because you instruct setquota to operate on file  that is not a mount point. I will assume the trailing `aquota.user' is a typo.

> 4. quotaon -v /tmp/tmp.CGIWazevOe/bz77871
> 
> Actual results:
> :: [   PASS   ] :: Initialising quota files
> -rw-------. 1 root root 7168 Jun 30 10:04
> /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> 
> ^^^ you see the file exists
> 
> :: [   PASS   ] :: Setting the testing user quotas
> :: [   PASS   ] :: Setting the grace time
> 
> ^^^ no complaints from setquota
> 
> quotaon: using /tmp/tmp.CGIWazevOe/bz77871/aquota.user on /dev/loop0
> [/tmp/tmp.CGIWazevOe/bz77871]: Invalid argument
> quotaon: Maybe create new quota files with quotacheck(8)?
>
Cannot reproduce (with SELinux in permissive mode as the policy has not been updated in RHEL-6 yet).
 
> Additional info:
> the error message "Invalid argument" is not very helpful when the only
> argument is just the device where the quota should be turned on, which is
> perfectly valid (I also tried to use "/dev/loop0" instead)

This is transliteration of error EINVAL (strerror(errno)) returned from kernel when asking kernel to enable quotas on given file system.

Because I cannot reproduce it, I would like to ask you to provide exact sequence of commands you used, content of /proc/mounts before running quotaon, possibly strace of quotaon to see arguments passed to quotactl(2) syscall and state of you SELinux and relevant part (while running quotaon) of /var/log/audit/audit.log.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

(In reply to comment #2)
> (In reply to comment #0)
> > Steps to Reproduce:
> > 1. setup your device, mount it with quota enabled like
> > /tmp/tmp.CGIWazevOe/bz77871.img on /tmp/tmp.CGIWazevOe/bz77871 type ext2
> > (rw,loop=/dev/loop0,usrquota,quota)
>                                ^^^^^
> Here you have quotas already enabled. You cannot run quotaon on file system
> with already enabled quotas.

then it seems I got the docs wrong ... I thought having the quota parameter passed to mount is just a prerequisite to use quota, not that it is enough to activate quota

now the test specifies the mountpoint in fstab like this:

$TmpDir/bz77871.img $HomeDir ext2 loop,usrquota 0 0

- is that correct (after variable substitution)?

> However this is line from /etc/mtab which quota tools do not use if proc FS is
> available. They parse /proc/mounts instead because /etc/mtab is damaged by
> mount(8) usually.

mount now reports:

/tmp/tmp.2TnHBdHBfF/bz77871.img on /tmp/tmp.2TnHBdHBfF/bz77871 type ext2 (rw,loop=/dev/loop0,usrquota)

and /proc/mounts has this:

/dev/loop0 /tmp/tmp.2TnHBdHBfF/bz77871 ext2 rw,seclabel,relatime,errors=continue,usrquota 0 0

> > 2. quotacheck -c /tmp/tmp.CGIWazevOe/bz77871
> > ls -l /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> > 
> > 3. set some quota parameters - I  have:
> > setquota bz77871 128 256 0 0 /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> > setquota -t 3600 0 /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> > 
> These commands cannot pass because you instruct setquota to operate on file 
> that is not a mount point. I will assume the trailing `aquota.user' is a typo.

um, yes, copy&paste from the test:

rlRun "quotacheck -c $HomeDir" 0 "Initialising quota files"                                                                                                    
rlRun "setquota bz77871 128 256 0 0 $HomeDir" 0 "Setting the testing user quotas"                                                                              
rlRun "setquota -t 3600 0 $HomeDir" 0 "Setting the grace time"                                                                                                 

where $HomeDir doesn't end in /aquota.user of course

> > 4. quotaon -v /tmp/tmp.CGIWazevOe/bz77871
> > 
> > Actual results:
> > :: [   PASS   ] :: Initialising quota files
> > -rw-------. 1 root root 7168 Jun 30 10:04
> > /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> > 
> > ^^^ you see the file exists
> > 
> > :: [   PASS   ] :: Setting the testing user quotas
> > :: [   PASS   ] :: Setting the grace time
> > 
> > ^^^ no complaints from setquota
> > 
> > quotaon: using /tmp/tmp.CGIWazevOe/bz77871/aquota.user on /dev/loop0
> > [/tmp/tmp.CGIWazevOe/bz77871]: Invalid argument
> > quotaon: Maybe create new quota files with quotacheck(8)?
> >
> Cannot reproduce

now that is strange, because I'm getting the error consistently:

quotaon: using /tmp/tmp.2TnHBdHBfF/bz77871/aquota.user on /dev/loop0 [/tmp/tmp.2TnHBdHBfF/bz77871]: Nepřípustný argument
quotaon: Maybe create new quota files with quotacheck(8)?
:: [   FAIL   ] :: Turning quota on (Expected 0, got 1)

> (with SELinux in permissive mode as the policy has not been
> updated in RHEL-6 yet).

... and it seems still wrong => bug #767579

> > Additional info:
> > the error message "Invalid argument" is not very helpful when the only
> > argument is just the device where the quota should be turned on, which is
> > perfectly valid (I also tried to use "/dev/loop0" instead)
> 
> This is transliteration of error EINVAL (strerror(errno)) returned from kernel
> when asking kernel to enable quotas on given file system.
> 
> Because I cannot reproduce it, I would like to ask you to provide exact
> sequence of commands you used, content of /proc/mounts before running quotaon,
> possibly strace of quotaon to see arguments passed to quotactl(2) syscall and
> state of you SELinux and relevant part (while running quotaon) of
> /var/log/audit/audit.log.

I guess it'd be better if you had a few minutes to sit together at the same machine ... please schedule some meeting or just ping me on irc

(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #0)
> > > Steps to Reproduce:
> > > 1. setup your device, mount it with quota enabled like
> > > /tmp/tmp.CGIWazevOe/bz77871.img on /tmp/tmp.CGIWazevOe/bz77871 type ext2
> > > (rw,loop=/dev/loop0,usrquota,quota)
> >                                ^^^^^
> > Here you have quotas already enabled. You cannot run quotaon on file system
> > with already enabled quotas.
> 
> then it seems I got the docs wrong ... I thought having the quota parameter
> passed to mount is just a prerequisite to use quota, not that it is enough to
> activate quota
> 

Sorry, I thought on XFS mistakenly. In ext file system, any of quota, usrquota, grpquota are prerequisite for quota tools, but they do not enable quota accounting nor enforcing at mount time. One need to quotaon the file system explicitly later then.

> now the test specifies the mountpoint in fstab like this:
> 
> $TmpDir/bz77871.img $HomeDir ext2 loop,usrquota 0 0
>
> - is that correct (after variable substitution)?
> 
Yes, this one is correct. `quota' option equals to `usrquota,grpquota' string. Any of the three should be sufficient to make quota tools thinking quotas should be handled on the file system.

> > However this is line from /etc/mtab which quota tools do not use if proc FS is
> > available. They parse /proc/mounts instead because /etc/mtab is damaged by
> > mount(8) usually.
> 
> mount now reports:
> 
> /tmp/tmp.2TnHBdHBfF/bz77871.img on /tmp/tmp.2TnHBdHBfF/bz77871 type ext2
> (rw,loop=/dev/loop0,usrquota)
> 
> and /proc/mounts has this:
> 
> /dev/loop0 /tmp/tmp.2TnHBdHBfF/bz77871 ext2
> rw,seclabel,relatime,errors=continue,usrquota 0 0
>
Great.

> rlRun "quotacheck -c $HomeDir" 0 "Initialising quota files"                     
> rlRun "setquota bz77871 128 256 0 0 $HomeDir" 0 "Setting the testing user quotas"                                                                         

There could be argument `-u' between `setquota' and `bz77871' to control user quotas (and not for example group quotas). Though `-u' option is default behavior.

> rlRun "setquota -t 3600 0 $HomeDir" 0 "Setting the grace time"                  
> 

The same applies here.

> > > 4. quotaon -v /tmp/tmp.CGIWazevOe/bz77871
> > > 
> > > Actual results:
> > > :: [   PASS   ] :: Initialising quota files
> > > -rw-------. 1 root root 7168 Jun 30 10:04
> > > /tmp/tmp.CGIWazevOe/bz77871/aquota.user
> > > 
> > > ^^^ you see the file exists

quotaon initializes and starts accounting and enforcing quotas in kernel. quota files (aquota.user) are initialized by quotackeck -c command. This message by test script is misleading.

> > > quotaon: using /tmp/tmp.CGIWazevOe/bz77871/aquota.user on /dev/loop0
> > > [/tmp/tmp.CGIWazevOe/bz77871]: Invalid argument
> > > quotaon: Maybe create new quota files with quotacheck(8)?
> > >
> > Cannot reproduce
> 
> now that is strange, because I'm getting the error consistently:
> 
> quotaon: using /tmp/tmp.2TnHBdHBfF/bz77871/aquota.user on /dev/loop0
> [/tmp/tmp.2TnHBdHBfF/bz77871]: Nepřípustný argument
> quotaon: Maybe create new quota files with quotacheck(8)?
> :: [   FAIL   ] :: Turning quota on (Expected 0, got 1)
> 
[...]
> I guess it'd be better if you had a few minutes to sit together at the same
> machine ... please schedule some meeting or just ping me on irc

I do.

Finally, I can reproduce it on:

kernel-2.6.32-220.el6.x86_64
glibc-2.12-1.47.el6.x86_64
quota-3.17-16.el6.x86_64

with this script:


#!/bin/bash
set -x
IMG=/tmp/1.ext2
DIR=/mnt/quota

umount "$DIR"
rm "$IMG"

dd if=/dev/zero "of=${IMG}" bs=1M count=1
mkfs.ext2 -F "$IMG"
mount -o loop,usrquota "$IMG" "$DIR"
quotacheck -c "$DIR"
quotaon "$DIR"


If quotaon is executed very quickly after quotacheck, kernel returns EINVAL:

quotactl(Q_QUOTAON|USRQUOTA, "/dev/loop0", QFMT_VFS_V0, 0x7f21121201c0) = -1 EINVAL (Invalid argument)
quotaon: using /mnt/quota/aquota.user on /dev/loop0 [/mnt/quota]: Invalid argument

The last quotactl argument should point to quota file and is printed by quotaon tool in the subsequent message (using ... on). So the pointer is correct.

It looks like a race in kernel.

If sync(2) is called just before quotaon or some quotaon is delayed (about 10 seconds), quotactl(2) call succeeds.

I will reassign this issue to kernel.

To reporter: Use sync(1) until this issue will be solved.

(In reply to comment #6)
> To reporter: Use sync(1) until this issue will be solved.

I've added sync workaround so that this doesn't block testing of the original bug

however, I've done it just as fallback, so the test will be failing in the setup phase until this one is fixed, so that the test covers both bugs now

plus there is one outstanding selinux issue (RFE?) - bug #767579

anyways, thanks for looking into this

one more observation: this problem seems to happen only in Permissive selinux mode

I've been using Permissive because of the abovementioned bug #767579

I cannot reproduce this bug if I leave selinux in Enforcing mode and set the context of the directory to 'unconfined_u:object_r:home_root_t:s0'

remove RHTSdone from QA whiteboard & the TCMS reference, as the test doesn't work reliably, as per comment #8

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This is an old bug. Can you take a look and see if it is still an issue?

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days