repquota loads the server - how to treat
I want to share a solution to the problem I
Worth FreeBSD 6.2. Regularly using
Symptoms of the problem: at startup,
Symptoms are relieved by killing the process
But it turned out that the /home/quota.user file reached unimaginable sizes: 64G. I noticed by chance - according to the backup logs.
The problem was completely cured by the following banal: UPD
The bottom line was in the quota.user file format. Information about the quota is stored in the file at the offset uid * 32. Accordingly, with a large uid (or negative), the file is too large, and repquota spends a lot of time viewing the file to get to the last uid.
More on opennet and the freebsd mailing list .
There was no user with a huge uid, but there was a file with uid 2147483647. It was created by Exim due to the fact that there was a user in the system with a login consisting of 11 digits. When assigning rights to the user's mail, Exim began to think that it was a uid, not a name.
In general, somehow.
repquota
encountered today. I hope it helps someone not to waste time on the proceedings. Worth FreeBSD 6.2. Regularly using
repquota
statistics is collected on the use of space by users. Symptoms of the problem: at startup,
repquota
or the quotacheck
process starts to load the CPU, and most importantly - fails to drive on disk operations. The server practically lays down. Symptoms are relieved by killing the process
repquota
or quotacheck
. But it turned out that the /home/quota.user file reached unimaginable sizes: 64G. I noticed by chance - according to the backup logs.
The problem was completely cured by the following banal: UPD
rm /home/quota.user
rm /home/quota.group
quotaoff /usr/home
quotacheck /usr/home
quotaon /usr/home
Root of evil
The bottom line was in the quota.user file format. Information about the quota is stored in the file at the offset uid * 32. Accordingly, with a large uid (or negative), the file is too large, and repquota spends a lot of time viewing the file to get to the last uid.
More on opennet and the freebsd mailing list .
There was no user with a huge uid, but there was a file with uid 2147483647. It was created by Exim due to the fact that there was a user in the system with a login consisting of 11 digits. When assigning rights to the user's mail, Exim began to think that it was a uid, not a name.
In general, somehow.