Página 1 de 9 123456 ... ÚltimoÚltimo
+ Responder ao Tópico



  1. Fiquei sabendo ontem que o Thunder não pode ser desligado por falta de energia ou coisas do tipo em hipótese alguma.
    Se isso acontecer, tem que reinstalar o Thunder novamente, porque ele não inicia mais. Segundo informações que tive, isto é um problema do FreeBSD, sistema que o Thunder roda.

    Nunca tinha visto uma coisa dessas. Fiquei impressionado! Em três quedas de energia que tive durante 1 mês e meio, que duraram mais de 3 horas, o meu nobreak não aguentou tanto tempo e acabou desligando o servidor do thunder. Das 3 vezes, tive que reinstalar o Thunder tudo novamente, porque ele simplesmente não inciava mais.

    Gostaria de saber como vocês estão vivendo com isso e qual solução estão usando para esse problema.

    Abraços,
    Jonas Lima

  2. Citação Postado originalmente por jlima2001 Ver Post
    Fiquei sabendo ontem que o Thunder não pode ser desligado por falta de energia ou coisas do tipo em hipótese alguma.
    Se isso acontecer, tem que reinstalar o Thunder novamente, porque ele não inicia mais. Segundo informações que tive, isto é um problema do FreeBSD, sistema que o Thunder roda.

    Nunca tinha visto uma coisa dessas. Fiquei impressionado! Em três quedas de energia que tive durante 1 mês e meio, que duraram mais de 3 horas, o meu nobreak não aguentou tanto tempo e acabou desligando o servidor do thunder. Das 3 vezes, tive que reinstalar o Thunder tudo novamente, porque ele simplesmente não inciava mais.

    Gostaria de saber como vocês estão vivendo com isso e qual solução estão usando para esse problema.

    Abraços,
    Jonas Lima
    A informação está errada.

    Não é que não pode ficar sem energia. Ao reiniciar de modo incorreto, o UFS precisa sempre ser reparado. Existe uma reparação com journal, que é mais rápida, e quando o journal tbm está corrompido, é preciso fazer uma checagem full, que demora um pouco mais.

    Por padrão, a checagem full não era feita no boot, o que fazia com que o sistema não iniciasse caso o journal estivesse corrompido. Isso foi alterado na última atualização, e o HD do sistema sempre é checado a modo full no boot (o que aumenta o tempo de boot, mas pelo menos não causa mais problemas de inicialização).

    Agora os HDs de cache não são mais montados no boot, e sim após a inicialização do sistema, então nem esses podem mais interferir no boot, forçando uma reinstalação. Porém ainda falta a checagem com journal nos discos de cache que não está sendo feita, com isso eles podem vir sempre corrompidos após um desligamento incorreto, exigindo checagem manual (feito via web no painel, e não via comando) pra inicialização do serviço.

    Isso será corrigido na próxima atualização (provável que sai hoje ou amanhã, no máximo), sendo assim, somente corrompendo o journal de um HD de cache (o que é bem difícil), pra exigir manutenção manual pra se ter o sistema rodando novamente.



  3. Citação Postado originalmente por jlima2001 Ver Post
    Fiquei sabendo ontem que o Thunder não pode ser desligado por falta de energia ou coisas do tipo em hipótese alguma.
    Se isso acontecer, tem que reinstalar o Thunder novamente, porque ele não inicia mais. Segundo informações que tive, isto é um problema do FreeBSD, sistema que o Thunder roda.

    Nunca tinha visto uma coisa dessas. Fiquei impressionado! Em três quedas de energia que tive durante 1 mês e meio, que duraram mais de 3 horas, o meu nobreak não aguentou tanto tempo e acabou desligando o servidor do thunder. Das 3 vezes, tive que reinstalar o Thunder tudo novamente, porque ele simplesmente não inciava mais.

    Gostaria de saber como vocês estão vivendo com isso e qual solução estão usando para esse problema.

    Abraços,
    Jonas Lima
    Não vou entrar no mérito do produto ThunderCache, mas na atribuição de culpa ao FreeBSD.

    Conforme consta na documentação[1] do FreeBSD, a simples solução para situações de ocorrência de desligamento incorreto, pode ser provida com a automatização de verificação (e reparação, se necessária) do sistema de arquivos.

    Claro que, melhor do que desligar incorretamente, é desligar de forma apropriada. Com uso de sinalizações provindas de serviços específicos[2][3], seu sistema de suprimento de energia pode informar ao seu servidor, sobre a condição de autonomia dos bancos de baterias, disparando assim o normal e correto processo de desligamento.

    [1] http://www.freebsd.org/cgi/man.cgi?query=rc.conf
    [2] http://svnweb.freebsd.org/ports/head...?revision=HEAD
    [3] http://www.apcupsd.com

  4. Citação Postado originalmente por trober Ver Post
    Não vou entrar no mérito do produto ThunderCache, mas na atribuição de culpa ao FreeBSD.

    Conforme consta na documentação[1] do FreeBSD, a simples solução para situações de ocorrência de desligamento incorreto, pode ser provida com a automatização de verificação (e reparação, se necessária) do sistema de arquivos.

    Claro que, melhor do que desligar incorretamente, é desligar de forma apropriada. Com uso de sinalizações provindas de serviços específicos[2][3], seu sistema de suprimento de energia pode informar ao seu servidor, sobre a condição de autonomia dos bancos de baterias, disparando assim o normal e correto processo de desligamento.

    [1] http://www.freebsd.org/cgi/man.cgi?query=rc.conf
    [2] http://svnweb.freebsd.org/ports/head...?revision=HEAD
    [3] http://www.apcupsd.com

    O meu aqui está desativado pelo mesmo problema!



  5. Citação Postado originalmente por mjr88 Ver Post
    A informação está errada.

    Não é que não pode ficar sem energia. Ao reiniciar de modo incorreto, o UFS precisa sempre ser reparado. Existe uma reparação com journal, que é mais rápida, e quando o journal tbm está corrompido, é preciso fazer uma checagem full, que demora um pouco mais.

    Por padrão, a checagem full não era feita no boot, o que fazia com que o sistema não iniciasse caso o journal estivesse corrompido. Isso foi alterado na última atualização, e o HD do sistema sempre é checado a modo full no boot (o que aumenta o tempo de boot, mas pelo menos não causa mais problemas de inicialização).

    Agora os HDs de cache não são mais montados no boot, e sim após a inicialização do sistema, então nem esses podem mais interferir no boot, forçando uma reinstalação. Porém ainda falta a checagem com journal nos discos de cache que não está sendo feita, com isso eles podem vir sempre corrompidos após um desligamento incorreto, exigindo checagem manual (feito via web no painel, e não via comando) pra inicialização do serviço.

    Isso será corrigido na próxima atualização (provável que sai hoje ou amanhã, no máximo), sendo assim, somente corrompendo o journal de um HD de cache (o que é bem difícil), pra exigir manutenção manual pra se ter o sistema rodando novamente.

    Olá mjr88. Muito obrigado pela sua resposta. Estas informações que eu tive inicialmente foram com o pirigoso, ontem a noite. Como foi feita uma alteração recente no Thunder, pode ser que ele não estivesse a par disso.
    De qualquer forma, como disse, ontem a noite o Thunder foi desligado incorretamente e quando a energia voltou, ele não mais inicializou (deixei ele a noite toda ligada, e hoje pela manhã ainda não tinha inicializado).
    Não sei informar o erro na inicialização, pois ainda não liguei ele a um monitor para ver qual o problema (mas tarde terei esta informação), entretanto, deve ser o mesmo das outras vezes, que era:

    Código :
    Fast boot: skipping disk checks.mount: /dev/label/rootfs: R/W mount of / dev denied. Filesystem is not clean - run fsck. Forced mount will invalidate journal contents: Operation not permitted
    Mouting root will invalidate journal contents: Operation not permitted
    Mouting root filesystem rw failed, startup aborted
    ERROR: ABORTING BOOT (sending SIGTERM to parent)!
    Jul 17 04:24:41 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
    Enter full pathname of shell or RETURN for /bin/sh:

    O meu Thunder estava atualizado com os recentes updates disponibilizados no Painel de Controle (não reiniciei o servidor após as atualizações, somente o serviço), mesmo assim aconteceu o problema. O que acha que pode ser?

    Abraços,
    Jonas Lima






Tópicos Similares

  1. Usuario pode fazer upload mas não pode apagar
    Por ernany no fórum Servidores de Rede
    Respostas: 0
    Último Post: 13-12-2004, 22:26
  2. Não pode Ser a Micro$oft se apoderando do Linux!!!
    Por garupeiro no fórum UnderLinux
    Respostas: 8
    Último Post: 21-10-2004, 07:25
  3. Respostas: 10
    Último Post: 24-08-2004, 10:55
  4. Erro no gcc, não pode criar ecexutáveis
    Por vonlinkerstain no fórum Servidores de Rede
    Respostas: 4
    Último Post: 12-03-2004, 13:39
  5. Squid: "A URL solicitada não pôde ser recuperada"
    Por hsalbano no fórum Servidores de Rede
    Respostas: 2
    Último Post: 21-01-2004, 09:57

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L