#134 setquota -r does not fail if a server has not RPC quota service registered

[Petr Písař]

If a server is not running rpc.rquotad and a client tries to set a quoa using "setquota -r ...", setquota does print any error message and returns 0 exit code.

I believe this is a wrong behavior and setquota should report an error. Compare to running setquota for a local file system that has no quotas enabled. In that case it repors "...has no quota enabled" and exits with 1.

It seems this silent behaviour was introduced with:

commit 3912b14a2db657893abce87cf9b9a0b2e1df0c5c
Author: jkar8572 <jkar8572>
Date:   Sat Oct 18 17:32:49 2003 +0000

    Fixed fake error messages from rpc.rquotad
    Fixed reporting of quotas on NFS filesystem without quotas

That commit started faking ENOENT error in case of an unregistered RPC service.

As a result rpc_rquota_get() returns ENOENT, then getprivs(..., 0) returns NULL and setlimits() assigns that NULL to curprivs variable. Then setlimits() skips populating limits with old values (it iterates zero times over an empty curprivs (==NULL)), and calls putprivs(NULL, ...) that having nothing to do returns optimistic 0. I.e. a success.

I think the setlimits() should insist on retrieving old limits, otherwise raise an error. A similar faulty code can also be seen in batch_setlimits().

[Petr Písař]

s/setquota does print any error message/setquota does NOT print any error message /

[Jan Kara]

OK, I agree this is somewhat inconsistent. I've pushed out changes that make the behavior more consistent. The error messages are still different for NFS than for local filesystems e.g.:

leet:~/source/quota-tools # ./setquota -r -u root 100 200 300 400 /labs
setquota: error while getting quota from pobox.suse.cz:/home/exports for root (id 0): No such file or directory
setquota: Error getting quota information to update.

vs

leet:~/source/quota-tools # ./setquota -r -u root 100 200 300 400 /
setquota: Mountpoint (or device) / not found or has no quota enabled.
setquota: Not all specified mountpoints are using quota.

But it would be more difficult to make them same without regressing other things (most notably because there's no way to easily detect whether particular NFS mount supports quotas or not).

Overall the rule now applied is: "scan all" operations silently ignore failures, if particular filesystems are specified on command line, error on any of them is fatal and nothing is changed / reported (besides the error).

Please test if the current code works for you.

[Anonymous]

Your patches work for me.

Although the ENOENT message is highly confusing. What are the other cases that would regress? I tried removing "else if (rquotaprog_not_registered)" branches from both rpc_rquota_get(), and rpc_rquota_set() and setquota, quota, "quota -A", "quota -f" works as expected. Now when we distinguish operations on an explicit file system from operations over all file systems we don't need disguise ECONNREFUSED as ENOENT.

[Petr Písař]

That was me.

[Jan Kara]

Well, there's a question what error we should report. The real error reported by RPC is "Program not registered" and it's different from standard "Connection refused" error. But thinking about it for a while I guess there's no big difference for the user so let's merge these two error cases.

[Jan Kara]

So what I have now is:

leet# ./quota -f /labs
quota: error while getting quota from pobox.suse.cz:/home/exports for root (id 0): Cannot connect to RPC quota service

OK?

[Petr Písař]

I think it's Ok. This is an explicit request for a specific file system and thus you get an error. A similar one as on a local file system without enabled quotas.

When reading your last commit (4cd287f3) a small nit caught my eye. Could you please make the "Cannot connect to RPC quota service" string translatable (_())?

[Jan Kara]

Sure, thanks for catching this.