De nerd para nerd, de Geek para Geek, de nerd para não nerd!

É, pessoALL, apesar do foco hoje estar 100% no http://www.appunix.com.br ainda uso este blog para dar algumas dicas (FREE) sobre WHM/CPANEL, e uma delas é baseada em um erro que acaba com a alegria de qualquer brazuca (ou sysadmin), um processo irritante que consome 100% da cpu. Este processo é o /usr/sbin/repquota -auv, o qual o cpanel o executa sozinho, do nada (e como quem quer nada), lol, e o pior, não adianta dar killall, kill -9, kill np que ele não encerra, isto é fato!!! Vamos parar de preencher a linguiça e sanar o negócio?

Bem, alguns passos podem ser seguidos para sanar, digamos que irei colocar do nível mais simples ao mais curioso de todos, ok?

Tente o seguinte [como root]:

rm /home/quota.group
rm /home/quota.user

/scripts/fixquotas

Se o processo ainda insistir em ficar como louco checa se seu disco está operando em ready only, uma forma de tentar isto é fazer assim:

touch /home/qualquercoisa e em seguida digitar stat /home/qualquercoisa, se mostrar somente leitura é hora de um reboot (e de preferência um fsck por parte do IDC).

Outro ponto extra é você executar o upcp –force e ver se o processo inicia, caso não, observe na hora (normalmente madrugada) se o processo executa e em seguida opera com o repquota, se isso ocorrer realmente é o versionamento ferrado, mude o estilo de update e faça upcp –force (normalmente release ou stable são os mais recomendados, troque um pelo outro e lembre-se de proteger com chattr os arquivos que lhe são importantes e o cpanel pode os sobrescrever (customizações, por exemplo, em temas do cpanel)).

Vamos finalizar com a dica mais extra?

lsattr /*.user

Se exibir proteções do tipo i–A, meu amigo, tira essa praga daí —-> chattr -iA /*.user

Com isso rode o comando na mão e veja que glorioso.

Se a glória não ocorrer você precisara aprofundar as coisas:

1. Identificar que partições estão usando sistema de quotas,
================
root@appunixlabs [~]# cat /etc/fstab | grep quota
LABEL=/ / ext3 defaults,usrquota 1 1
LABEL=/home /home ext3 defaults,usrquota 1 2
LABEL=/usr /usr ext3 defaults,usrquota 1 2
LABEL=/var /var ext3 defaults,usrquota 1 2
================

2. Reiniciar o Servidor e entrar em Single mode.

3. Rodar um fsck para cada partição (modo forçado)-> fsck -f /dev/sdX#

4. Recriar o sistema de journaling para cada partição. (tune2fs -O ^has_journal /dev/sdX#;tune2fs -O has_journal /dev/sdX#)

5. Rodar um fsck PADRÃO para cada partição.

6. rodar o comando /scripts/fixquotas

7. Reiniciar o sistema.

Ps: Se funcionar lembre-se que um whois neste domínio mostra minha casa, daí é só mandar uma caixa de bis do preto. (LOL)

Este é o erro que está ocorrendo com você?

Error: Runtime error in pmmcli:
(3, ‘GetDiskFreeSpace’, ‘The system cannot find the path specified.’)
Traceback (most recent call last):
File “C:\Program Files\Parallels\Plesk\admin\share\pmmcli\pmmcli.py”, line 1846, in main
data_action_response, errcode_response, error_message = actions.get(sys.argv[1][2:])(parameters)
File “C:\Program Files\Parallels\Plesk\admin\share\pmmcli\pmmcli.py”, line 1721, in make_dump
return ActionRunner(MakeDumpAction, backup_task_description, None).doActivity()
File “C:\Program Files\Parallels\Plesk\admin\share\pmmcli\pmmcli.py”, line 75, in doActivity
result = self.processor.doActivity()
File “C:\Program Files\Parallels\Plesk\admin\share\pmmcli\pmmcli.py”, line 860, in doActivity
if osutil.free_bytes(local_dump_directory) < (long(disk_space_required) * 1048576):
File “C:\Program Files\Parallels\Plesk\admin\lib\python\osutil.py”, line 188, in free_bytes
sectorsPerCluster, bytesPerSector, numFreeClusters, totalNumClusters = GetDiskFreeSpace(os.path.splitdrive(path)[0] + “\\”)
error: (3, ‘GetDiskFreeSpace’, ‘The system cannot find the path specified.’)

Se é, antes de tentar seu backup, atualize o plesk para uma versão mais recente e o problema deverá estar sanado.

Uma coisa interessante que observei hoje foi o quão importante é o software REALMENTE livre.

Na instituição que presto serviço de consultoria o dono da empresa comprou um software mais ou menos naquele estilo “embutido”, aonde os compradores pagam por algo não customizado, ou seja, enlatado.

Não por ter algo contra Delphi, até por que conheço ótimos desenvolvedores nesta linguagem, mas pelo fonte fechado (após compilação).

Uma coisa que a maior parte dos “desenvolvedores” não faz é documentar o fonte e pior, não testa sua aplicação. Foi mais ou menos nisto que “clamei” para ter o fonte do sistema criado em Delphi e “enlatado”.

Minha ira concretizou-se quanto tentei gerar um relatório de produtos com uma marca X, o qual, no momento em que instruí o sistema para tal feito recebi uma mensagem (bug) com erros da aplicação, resultante de que?

Adivinhe -> Software mal debuggado.

Segue a fotinha “maldita”:

Sem mais reclamações, somente lamentando por não poder ver o fonte e fazer modificações que possam ajudar na usabilidade deste software.

Lamentável.

Se você está percebendo MUITOOOOOOOOOOOOOOOOOOOOOOOOOS Crashes no Mysql, por favor, se você é mais um adepto do Cpanel/WHM – NÃO DEIXE de clicar em update config – marcar current, em seguida, vá ao console e digite:

/script/upcp –force

Isso vai atualizar seu cpanel e principalmente o Mysql para versão sem bugs.

Por que?

Esta versão 5.0.51 está apresentando crashes violentos na família redhat (fedora/centos/rhel) – perdendo até bases de dados em casos extremos.

Nota oficial:

http://bugs.mysql.com/bug.php?id=34459

Fonte: EU mesmo