Onderwerp: Plesk & user quota probleem

Een aantal dagen geleden kwam ik erachter dat bij een gewone user (buiten plesk om) de quota niet correct was. Vanwege het feit dat daar een IRC server draait had ik weinig zin om de server te rebooten, dus heb ik getracht om de quota handmatig te herstellen (quotaoff, quotacheck, quotaon)... alles precies volgens de regels. Helaas mocht het niet zo zijn:

Na uitvoeren van quotaoff bleef mijn shell sessie hangen. Na opnieuw inloggen bleek dat proces in status D door te blijven lopen (met geen mogelijkheid te killen) en de load werd wat hoger.

Quotacheck werkte wel. Na de quotacheck quotaon uitgevoerd, waarna de sessie wederom bleef hangen. Na opnieuw inloggen bleken er nu 2 processen in status D te blijven hangen en de load was nu onacceptabel hoog geworden (hoger dan 8).

Bij bekijken van de quota onder "su user" kwam opeens de volgende melding naar voren:

quota: Can't open quotafile //aquota.user: Permission denied
quota: Quota file not found or has wrong format.
Disk quotas for user xxxxx (uid xxxx): none

Lijkt er dus op dat er iets gruwelijk mis was gegaan. De quota was wel te zien als root, en de waardes ervan waren okay, dus de quotacheck heeft in dat opzicht wel gewerkt. Maar vanwege de enorme load (waarschijnlijk hdd load, want CPU en mem usage waren okay) toch maar gereboot.

Vervolgens leek alles goed te zijn (quota was weer op te roepen vanaf een user account), tot ik later iets moest FTP-en op een plesk account. Kreeg daar na inloggen te zien "quotas off"... erg vreemd maar ik schonk er verder weinig aandacht aan.

Vervolgens moest ik voor een user in plesk het password aanpassen. Dit duurde een eeuwigheid en na een aantal keer proberen was dat pwd eindelijk toch aangepast, maar de load was weer enorm hoog. Bleek dat er in de process lijst 3 instances waren van het volgende proces... in status D (en niet te killen):

root 28712 0.0 0.2 3952 1052 ? D 02:26 0:00 /usr/local/psa/admin/bin/usermng --isquotable

Vervolgens kregen users weer de melding "Can't open quotafile...." zoals hierboven gequote. De server moest vanwege de load wederom gereboot worden.

Het lijkt erop dat er iets kapot is gegaan. Of Plesk heeft zijn handen op een bepaald manier in het systeem zitten zodat de quotas niet aangepast, gechecked, etc mogen worden... of er is ies anders aan de hand met plesk... ik kon er in iedergeval erg weinig informatie over terugvinden.

Heeft er iemand hier ervaring mee en weet hoe het te herstellen is? Ik las op een forum dat Plesk 7.0.x in combinatie met Fedora Core1 soortgelijke problemen heeft en dat de enige remedie was in /etc/fstab de usrquota te verwijderen... een niet echt elegante oplossing, vooral omdat het hiervoor wel gewerkt heeft. Ik draai zelf Fedora Core1 en Plesk 7.1.6.

Ken het probleem, heeft niks met plesk te maken. Ik durf haast met zekerheid te zeggen dat je partitionering niet in blokken is gedaan,

heb jij
/boot
/tmp
swap
/ ?

Om dit probleem te verhelpen moet je de /home dir in een nieuwe partitie mounten... Probleem zit in quota management van fcore1.

Het vreemde is dat het gewerkt heeft tot ik handmatig de quota probeerde te herstellen en dat het probleem alleen verschijnt zodra Plesk wat met de quota wil doen. Het volgende staat in mijn fstab:

LABEL=/ / ext3 defaults,usrquota 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/hda2 swap swap defaults 0 0

We hebben dit probleem zelf ook gehad, na contact met plesk gehad te hebben en op forum een en ander gezocht zat er niets anders op dan de schijf te herindelen. Deze indeling is nu als volgt:

Code:

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/backup           /backup                 ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
LABEL=/home     /home   ext3    defaults,usrquota       1       2
none                    /proc                   proc    defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
LABEL=/tmp              /tmp                    ext3    defaults,defaults,rw,nosuid,nodev,noexec        1 2
LABEL=/var              /var                    ext3    defaults        1 2
/dev/hda6               swap                    swap    defaults        0 0
/dev/cdrom              /mnt/cdrom              udf,iso9660 noauto,owner,kudzu,ro 0 0

Het gaat erom dat de /home een aparte partitie krijgt van de / af. Daarmee gaat het fout. Bij ons crashde de quota management dusdanig dat hij als je de server wou rebooten hij bij de init zelfs op bleef hangen. Ik raad je dus ook aan deze indeling aan te passen.

Hmm ja herindelen (compleet verse install bedoel je waarschijnlijk) is geen optie... ik kan die IRC server geen dagen uit de lucht hebben voordat alles zover op orde en beveiligd is dat het weer terug kan... dan zijn alle users weggelopen.

Wel vreemd trouwens, er draaiden alweer een aantal van die "/usr/local/psa/admin/bin/usermng --isquotable" processen, waardoor de load enorm was... Ik was net van plan te gaan rebooten, blijken die nu opeens weer te zijn verdwenen, terwijl ze gewoonlijk niet te killen zijn. De load is weer normaal... de quota voor gewone users is ook weer te bereiken, behalve voor plesk domeinen dan.

Ik denk dat ik uit de fstab die usrquota maar ga verwijderen en dan tegen het eind van de contract periode een nieuwe server ga aanvragen met FC2 of 3.

Bedankt voor de antwoorden

workaround dat even gewerkt heeft voor ons is te vinden op "http://forum.plesk.com/showthread.php?threadid=13540&highlight=usermng+is quotable"

Je bedoelt de vervanging van de usrmng? Die zou in mijn versie (7.1.6)allang verwerkt moeten zitten. Het is al een erg oude bug die vorig jaar verholpen was... en het heeft ook gewerkt tot ik zelf met de quotas aan de gang ging.

Misschien moet ik even upgraden naar versie 7.1.7?

Nee, die upgrade heeft niet geholpen...