Posso apenas desativar o updatedb?

23

updatedb é necessário? Eu nunca uso locate e meus servidores tendem a ter dezenas de milhões de arquivos que geralmente fazem o updatedb rodar por um longo tempo e consumir I / O necessário para o MySQL e / ou outro software.

Posso apenas removê-lo do cron e esperar que tudo funcione? (por tudo quero dizer software usual encontrado no servidor: linux, cpanel, mysql, apache, php etc.).

    
por matt 05.02.2014 / 15:30

5 respostas

19

Sim, você pode desativá-lo no crons ou remover o pacote que fornece updatedb . Em um sistema da Red Hat, você daria os passos para determinar se algo precisa ser feito antes da remoção.

  1. Primeiro, descubra onde o programa está localizado no disco.

    $ type updatedb
    updatedb is /usr/bin/updatedb
    
  2. Em seguida, descubra qual pacote fornece updatedb .

    $ rpm -qf /usr/bin/updatedb
    mlocate-0.26-3.fc19.x86_64
    
  3. Veja se alguma coisa exige mlocate .

    $ rpm -q --whatrequires mlocate
    no package requires mlocate
    
  4. Nada requer que você possa remover o pacote.

    $ yum remove mlocate
    
por 05.02.2014 / 15:57
12

Você pode desabilitar a verificação de diretórios com muitos arquivos ( /var/www , por exemplo) editando o arquivo de configuração /etc/updatedb.conf . Se você realmente quiser desabilitá-lo, basta remover o cronjob.

    
por 05.02.2014 / 16:00
5

Remova-o usando o gerenciador de pacotes, se outro pacote usá-lo, você saberá, já que ele depende dele (dependência do pacote).

Eu tenho um servidor com Nginx , php-fpm e mysql e funciona lindamente sem updatedb .

    
por 05.02.2014 / 15:39
0

Eu não estou indo muito longe em um membro, dizendo isso, mas mais do que provável, não é atualizado que está causando seus problemas. Provavelmente, algo mais que você não quer, seja um aplicativo de backup que você não configurou para o seu 'gosto' ou algum problema de segurança com sua estrutura de grupo de perfis / sistemas.

Outro caso em que parece que a alocação de memória de sistemas está trabalhando contra o usuário é o cenário em que um 'desconhecimento de empilhamento de sistemas de arquivos virtuais'. E isso é booger de problema. Uma 'bomba virtual ilógica', por assim dizer.

Frequentemente acontece com drives USB formatados em fat32 em um sistema ext4 que são então transferidos para sistemas zfs que são configurados incorretamente com o shell csh como o shell de login man. Ele cria a recursão virtual do problema "Read-File only USB file system" no disco e formata / monta a unidade para vFat a partir de fat32, que por sua vez cria um setor de blocos defeituosos e extrai (virtualmente move) um diretório até seu diretório nível de diretórios pai, que causa o loop infinito! O diretório não está fisicamente no nível de hierarquia do pai. A sintaxe das causas do csh é a causa disso. * NOTA: A unidade é somente de leitura em todos os sistemas, exceto em um sistema de login do zfs c-shell.

Para desabilitar completamente o updatedb pode-se criar uma lógica insatisfatória em relação à alocação de memória e 'o efeito de reversão'. Se você já teve um rollback quando não queria, você sabe o que quero dizer quando vale duas horas de script de linha de comando é Fubar-ed porque você não alocou seu processamento de trabalho na memória.

Agora, se você tiver dois ou mais processadores físicos (por exemplo, dual core ou mais) e ddr3 ram, então tudo bem. Contanto que você não esteja executando gráficos pesados e, nesse caso, se essa carga de energia estiver causando seus problemas, o updatedb será o último da sua lista. Se você está tentando disfarçar seus movimentos para o sistema por algum motivo, então há outras maneiras de fazê-lo em vez de desabilitar o updatedb, e de fato o updatedb iria solidificar suas ações que 'nada acontecer' até o disfarce do seu sistema.

Bastante francamente baseado no tamanho do arquivo binário / usr / bin / updatedb e considerando a arquitetura da comunicação sinal / sistema dentro do sistema operacional e que o Bash é 10 vezes o tamanho do traço de concha reciprocamente ligado ou chamada assíncrona é muito barata no sistema.

Se você estiver logado no shell executando scripts sequenciais que escreveu, e você for um administrador (por exemplo, sudo), execute o seguinte comando:

~$ sudo bash
:~# ./script.sh

Em seguida, você provavelmente deseja criar uma variável local em seu script (o updatedb precisa de privilégios de sistema, como root / sudo / wheel), por exemplo:

#! /bin/sh
# Create local variables
UPD="updatedb"

echo "Beginning Execution of sequence "

Nesse caso, a sequência está usando STDOUT / STDIN de outros scripts de shell que você escreveu e está executando como variáveis em seu script principal ou diz que você tem um pacote de administração pessoal ou de negócios configurado onde você faz o upload / download / port de cdrom ou usb ou o que for, que é extremamente grande e tem scripts de instalação pessoal para eles, você quer manter updatedb. Quando o shell do terminal está aberto, essa é a sua instância principal do aplicativo. Outros aplicativos podem ser executados de forma assíncrona, mas o updatedb é um dos menos dispendiosos em termos de demanda geral de sistema / computação. Muitas vezes, especialmente com o lxdm Desk Enviro e o Lxterm (essa coisa é super rápida), mas não unicamente; sem adicionar o updatedb aos meus scripts, o sistema me disparou erros de que os arquivos não existem ou que algo maluco havia acontecido. E eu sou como o que!

O shell é mais rápido que o sistema que administra, eu garanto isso!

Nesse caso, você chamaria a variável updatedb para bloquear a seqüência anterior na memória, conforme mostrado

echo "Updating local database "

$UPD

echo "Exiting script two "

exit

Você vê o que estou dizendo? Se você perguntar isso, porque você está executando testes de velocidade de execução, ou seja, estilo Andrew Tanenbaum do que fazer. Outros sábios usam a ferramenta a seu favor.

    
por 22.08.2014 / 20:06
0

Pelo menos no ArchLinux, parece que man-db.timer e updatedb.timer estão habilitados por padrão (ex .: os arquivos a seguir existem), mas há no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. [...] (saída de systemctl enable {man-,update}db.timer ).

Estes são os links simbólicos que estão presentes no sistema de arquivos:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer e /usr/lib/systemd/system/multi-user.target.wants/updatedb.timer

Deve ser uma questão de simplesmente removê-los.
No entanto, eles seriam recriados a cada re / instalação / upgrade de man-db , mlocate packages, respectivamente.

Para o ArchLinux, uma solução possível é ter um gancho para o pacman para removê-los.
No entanto, eles serão removidos em cada um desses eventos, mesmo se você quiser que eles sejam ativados em upgrades.
Você poderia, nesse caso, desabilitar o gancho quando quiser que o timer esteja ativado.
Mas, habilitar o cronômetro entraria em vigor somente na re / instalação / atualização do pacote, já que não há nenhuma seção configurada nos arquivos .timer unit padrão para diretamente systemctl enable dos timers.
Um comando manual ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timer ou ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timer seria necessário para ativar o temporizador / s e remover o link / s para desativá-lo.

Você pode substituir as unidades personalizadas /etc/systemd/system/{man-,update}db.timer , fornecendo WantedBy=multi-user.target na seção [Install] para permitir systemtl enable|disable , mas os links /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timer ainda serão criados em re / installation / upgrade, reabilitando efetivamente a .timer s.

Você também pode executar systemctl mask man-db.timer updatedb.timer para mascarar os timers.
Mesmo se ainda fosse possível executar manualmente systemctl start man-db.service updatedb.service para iniciar os serviços correspondentes, você não seria capaz de iniciar manualmente os timers, por qualquer motivo que o usuário se encontrasse querendo / precisando fazê-lo. Essa solução alternativa não permite substituir os arquivos /etc/systemd/system/{man-,update}db.timer unit personalizados se desejado / necessário, pois o systemd precisa substituí-los por um link simbólico para /dev/null para indicar uma unidade mascarada.

O mascaramento parece ser a solução menos intrusiva.
Eu prefiro remover manualmente /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timer após cada atualização e ter arquivos de unidade de substituição /etc/systemd/system/{man-,update}db.timer tendo uma seção [Install] com WantedBy=multi-user.target para habilitar a habilitação / desativação manual systemctl .

Infelizmente, não há uma solução simples para isso, que, pelo menos, eu possa pensar neste momento.
Isso pressupõe que os pacotes man-db , mlocate sejam desejados / precisem ser mantidos instalados no sistema: removê-los não seria uma solução desejada / útil.

Veja também: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/

    
por 25.11.2018 / 23:32