📜 ⬆️ ⬇️

repquota server loads - how to treat

I want to share a solution to the problem with repquota , which I encountered today. Hopefully help someone not to waste time on the proceedings.

Worth FreeBSD 6.2. Regularly using repquota collects statistics on the use of space by users.

Symptoms of the problem: when you run repquota or quotacheck process starts loading the CPU, and most importantly, it crashes the disks for disk operations. The server almost falls.
')
Symptoms are removed by killing the repquota or quotacheck .

But it turned out that the file /home/quota.user reached unimaginable sizes: 64G. I noticed by accident - according to the backups logs.

The problem was completely cured by the following:

rm /home/quota.user
rm /home/quota.group
quotaoff /usr/home
quotacheck /usr/home
quotaon /usr/home


UPD

Root of evil



The essence was in the format of the file quota.user. Quota information is stored in a file at an offset uid * 32. Accordingly, if the uid is large (or negative), the file is too large, and repquota spends a lot of time viewing the file to get to the last uid.

Read 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, something like that.

Source: https://habr.com/ru/post/62678/


All Articles