Bekijk Volledige Versie : Show user pagina blijft laden en stopt DA
Als je in directadmin naar de pagina gaat met een overzicht van alle user accounts in directadmin(CMD_USER_SHOW) dan kun je daar op een gebruikersnaam klikken en krijg je normaal een pagina met alle gegevens van die klant(CMD_SHOW_USER), kun je die instellingen wijzigen en kun je inloggen als die klant. Bij allemaal werkt dat goed maar bij één user niet waardoor ik dus niets meer kan wijzigen aan die user, die pagina blijft laden en laden waarna DirectAdmin moet worden gerestart.
Heb dit nu voor de tweede keer bij een klant die Magento gebruikt, misschien toeval maar misschien ook wel niet.
Opnieuw restoren van de backup helpt helaas niet.
Iemand een oplossing hoe dit op te lossen zonder een nieuw account aan te maken?
Al in de conf file gekeken van de specifieke user of daar wellicht iets vreemds in staat ?
Heb het user.conf bestand naast een andere gezet maar zie geen vreemde dingen.
heb je de rechten van die file als eens vergeleken met die van een andere. Want heb dat ook als eens tegen gekomen en file stond op enkel lezen.
rackhost.be
04/08/09, 13:31
1. rechten controleren, DA heeft hiervoor handige scripts:
/usr/local/directadmin/scripts/set_permissions.sh -all
2. best ook even controleren in direct admin control panel, naar de timeout onder admin panel, deze eventueel aanpassen naar 60sec ofzo
Zojuist de rechten van die file gecontroleerd maar die is gewoon hetzelfde als bij de rest, namelijk lezen en schrijven (0600). Set_permissions.sh zojuist gedraaid maar heeft niet geholpen, wel handig script om te onthouden! En de timeout tijd stond al op 60.
In de DirectAdmin error log zijn zojuist 2 regels verschenen.
009:08:04-13:41:45: *** Segmentation fault *** Table::sortBy(user=klantnaam) : end : User: admin : 84.27.179.00 : /CMD_SHOW_USER : user= klantnaam : (null)
2009:08:04-13:42:45: Timeout from from 84.27.179.00 : last flagged: Table::sortBy(user= klantnaam) : end
Deze al bekeken en gedaan: http://help.directadmin.com/item.php?id=185
Als je gedaan hebt wat Erik hierjuist gepost heeft, kan je misschien best die output daarvan doormail naar DA support. Ik heb vroeger ook segmentation fouten gehad en na een paar uur kreeg ik een test compile terug van DA om te zien of het fixed was. Daarna verwerken ze die code in de volgende update.
Bij openen van pagina van een account checkt Directadmin ook bestandsgrootte etc. Als dat aantal erg groot is, krijg je timeout.
We hebben dit vaak gezien bij account met mailboxen die overvol zijn (meer dan 100.000 records). DirectAdmin geeft dan hier timeout
Oplossing was dan om mailbox eerst op te ruimen (via webmail inloggen), of in ergste geval gewoon te verwijderen.
vr.gr. Eef
In de vakantie is dit even blijven liggen maar toch even een update.
Deze al bekeken en gedaan: http://help.directadmin.com/item.php?id=185
Inmiddels uitgevoerd en contact gehad met de DirectAdmin support en het is opgelost door hun. :yes:
Dank voor het meedenken. :)
Misschien handig om de oplossing te plaatsen? Kunnen andere er ook van profiteren ;)
Misschien handig om de oplossing te plaatsen? Kunnen andere er ook van profiteren ;)
Ik denk dat DA support het opgelost heeft met een patch in hun programma (zoals ze voor mijn probleem ook gedaan hebben), zoniet is het misschien intersant om oplossing te posten.
Er is door DirectAdmin ingelogd en hun hebben het daarna opgelost heb er zelf niets meer aan gedaan. Wel een net mailtje met de problemen teruggehad. :)
"I found a very strange issue, which I believe to be possibly disk related.
I debugged the segfault down to the user.comments file belonging to *username*.
I simply used an editor to resave the "240" data that was in it.. to disk.
After doing that, it worked fine.
The segfault was because of an fclose call being made to an already closed pointer.
DA checks all opened files to ensure they're opened, so the filesystem was closing it on DA.. which shouldn't have happened.
After I resaved the user.comments file for *username* and *username2*, the issue went away, so it's a very odd one... but eithe way, is working now.
I'd recommend keeping a close eye on /var/log/messages to ensure the disk is ok."
Houd nu dus /var/log/messages extra in de gaten maar er gebeurd niets spannends.