md2 write failed: user block quota too long on PHP compile??

[Richard G]

Last night I was swapping php versions on the servers. So php1_release and php3_release.
This ment changing them in custombuild and then running the da build update and da build php commands afterwards.

Now on 1 server, during the compiling of php or imagick or just after the compiling in between, I've seen this message appearing.
What could be the cause of this as I have way enough free space:

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs            32G     0   32G   0% /dev/shm
tmpfs            13G   17M   13G   1% /run
/dev/md2        847G  298G  506G  38% /
/dev/md1        1.5G  585M  815M  42% /boot
/dev/loop0      9.3G  320K  8.8G   1% /tmp
/dev/sdb        1.8T   76G  1.7T   5% /backupdrive
tmpfs           6.3G  4.0K  6.3G   1% /run/user/0

and I checked, both user root and user diradmin do not have any quota's.
The /tmp is 8 GB but I can't imagine that getting totally full.
Also I have set the /tmp for directadmin in the directadmin.conf file to /datemp directory, so that could not be full during rebuild either.

Raid-check was mondaymorning early and no errors, SSD's are both fine in disk monitoring.

Do I need to worry or what could have caused this error? Only on 1 server, not on others.
I also do not know what is not written now. All seems fine, but still.... I don't like that kind of errors.

 

[sysdev]

Well, your raid kan be ok on monday and broken today.

But this means that the user block-quota is limiting the action AND the grace period has passed. That will give hard quota blocks.

 

[Richard G]

user block-quota is limiting the action AND the grace period has passed.

Yes but why, because this was during recompiling php, so this is done by root and/or Directadmin and they don't have any user quota.
Or am I missing something?

Ofcourse raid could be broken a day later, but then the monitoring system would have given me a warning and also on check all is fine.

 

[sysdev]

Maybe this one is over the limit?

# repquota -a|grep admin

 

[Richard G]

I don't think so.

repquota -a|grep admin
diradmin  --  106260       0       0          12723     0     0       
admin     -- 3151844       0       0           8971     0     0

and

quota -u admin
Disk quotas for user admin (uid 1000): none

 

[sysdev]

Quota's are kernel things. Maybe a crash of something messed up the administration.
Check with journalctl and dmesg if it has any quota messages. Maybe that points to the right direction.
Try a quotaoff/check/on and try to build again.
Of a xfs_quota -x -c 'report -h' / and see if anything had a grace period.

Sorry, can't help any further coz I never had that error.

 

[Richard G]

Of a xfs_quota -x -c 'report -h' / and see if anything had a grace period.

I don't have XFS. But it might have been some grace period as like 10 minutes before I already done a complete php rebuild and if I remember correctly I didn't see any errors at that moment.

I'll keep an eye on the system and disk monitors just to be sure.

Sorry, can't help any further coz I never had that error.

No problem, I'm already thankfull for you trying to help and the info given.