É updatedbnecessário? Eu nunca uso locatee meus servidores tendem a ter dezenas de milhões de arquivos, o que geralmente faz com que o updatedb seja executado por um longo tempo e consuma a E / S necessária ao MySQL e / ou outro software.
Posso apenas removê-lo do cron e esperar que tudo funcione? (por tudo, refiro-me ao software usual encontrado no servidor: linux, cpanel, mysql, apache, php etc.).
Respostas:
Sim, você pode desativá-lo nos crons ou remover o pacote que fornece updatedb. Em um sistema Red Hat, você seguiria as etapas para determinar se algo exige isso antes da remoção.
Primeiro descubra onde o programa está localizado no disco.
$ type updatedb
updatedb is /usr/bin/updatedb
Em seguida, descubra qual pacote oferece updatedb.
$ rpm -qf /usr/bin/updatedb
mlocate-0.26-3.fc19.x86_64
Veja se algo requer mlocate.
$ rpm -q --whatrequires mlocate
no package requires mlocate
Nada requer isso para que você possa remover o pacote.
$ yum remove mlocate
/var/lib/mlocate?
Remova-o usando o gerenciador de pacotes, se outro pacote o usar, você saberá, pois ele precisa depender dele (dependência do pacote).
Eu tenho um servidor com Nginx, php-fpme mysql, e funciona lindamente sem updatedb.
aptitude remove, aptitude whyou aptitude search '?installed ?recommends(mlocate)'. Todos eles mostrarão recomendações de dependências, além das necessárias. O apt agora instala os pacotes recomendados por padrão, portanto, embora não sejam considerados essenciais, eles podem ser usados para fornecer uma sub-função muito útil.
Não vou me incomodar em dizer isso, mas é mais provável que não esteja atualizado; o que está causando seus problemas. Provavelmente, algo que você não deseja, um aplicativo de backup que você não configurou ao seu gosto ou algum problema de segurança com a estrutura do seu perfil / grupo de sistemas.
Outro caso em que parece que a alocação de memória dos sistemas está funcionando contra o usuário é o cenário em que um 'desconhece sistemas de arquivos virtuais de empilhamento'. E isso é booger do problema. Uma "bomba ilógica virtual", por assim dizer.
Freqüentemente acontece com unidades USB formatadas em fat32 em um sistema ext 4 que são transferidas para sistemas zfs configurados incorretamente com o shell csh como o shell de login do homem. Ele cria a recursão virtual do problema "sistema de arquivos USB somente para leitura de arquivos" no disco e formata / monta a unidade no vFat a partir do fat32, que por sua vez cria um setor de blocos defeituosos e extrai (move virtualmente) um diretório até sua nível de diretórios pai, o que causa o loop infinito! O diretório não está fisicamente no nível de hierarquia do pai. A sintaxe das causas csh é a causa disso. * NOTA: A unidade é somente leitura em todos os sistemas, exceto no sistema de login do zfs c-shell.
Desabilitar completamente o updatedb pode criar falta de lógica em relação à alocação de memória e ao "efeito de reversão". o script é baseado em Fubar porque você não alocou o processamento do seu trabalho na memória.
Agora, se você possui dois ou mais processadores físicos (por exemplo, dual core ou mais) e ddr3 ram, tudo bem. Contanto que você não esteja executando gráficos pesados, nesse caso, se essa carga de energia estiver causando problemas, o updatedb será o último da sua lista. Se você está tentando disfarçar seus movimentos para o sistema por algum motivo, há outras maneiras de fazê-lo, em vez de desabilitar o updatedb, e de fato o updatedb solidificaria suas ações que 'nada acontecem' quanto ao disfarce do sistema.
Francamente, com base no tamanho do arquivo binário / usr / bin / updatedb e considerando a arquitetura da comunicação de sinal / sistema com o sistema operacional e que o Bash é 10 vezes maior que o tamanho do traço de shell vinculado reciprocamente ou a chamada assíncrona é muito barato no sistema.
Se você está conectado ao shell executando scripts seqüenciais que você escreveu e é um administrador (por exemplo, sudo), executa o seguinte comando:
~$ sudo bash
:~# ./script.sh
Então você provavelmente deseja criar uma variável local dentro do seu script (updatedb precisa de privilégios do sistema, AKA 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 comercial configurado para fazer upload / download / porta do cdrom ou usb ou qualquer outra coisa, que seja extremamente grande e possua scripts de instalação pessoal, VOCÊ QUER MANTER-SE atualizadob. Quando o shell do terminal está aberto, essa é sua instância principal do aplicativo. Outros aplicativos podem / são executados de forma assíncrona, mas atualizadosb é um dos menos dispendiosos em termos de demanda geral do sistema / computação. Muitas vezes, especialmente com o lxdm Desk Enviro e o Lxterm (essa coisa é super rápida), mas não apenas; sem adicionar updatedb aos meus scripts, o sistema disparou erros que os arquivos não existem ou que algo maluco aconteceu. E eu sou como o que!
O shell é mais rápido que o sistema que ele administra, garanto!
Nesse caso, você chamaria a variável updatedb para bloquear a sequê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, no estilo Andrew Tanenbaum, do que o necessário. Caso contrário, use a ferramenta para sua vantagem.
locatenão é útil porque não posso ter certeza de que esteja indexado. Quando os arquivos são mais antigos, procuro fzfuma pesquisa confusa.
Pelo menos no ArchLinux, parece que man-db.timere updatedb.timersão ativadas por padrão (ou seja: existem os seguintes arquivos), mas não existe 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 systemctl enable {man-,update}db.timer).
Estes são os links simbólicos presentes no sistema de arquivos:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer
Deve ser uma questão de simplesmente removê-los.
No entanto, eles seriam recriados em cada re / instalação / upgrade de man-db, mlocatepacotes, respectivamente.
Para o ArchLinux, uma solução possível é ter um gancho para o pacman removê-los.
No entanto, eles seriam removidos em cada evento, mesmo que você os deseje ativados nas atualizações.
Nesse caso, você pode desativar o gancho ao ativar o timer.
Porém, ativar o timer entrará em vigor apenas na reinstalação / atualização do pacote, pois não há seção configurada nos .timerarquivos da unidade padrão para diretamente systemctl enableos timers.
Um manual ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timerou ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timercomando seria necessário para ativar o (s) cronômetro (s) e remover o (s) link (s) para desativá-los.
Você pode substituir unidades personalizadas /etc/systemd/system/{man-,update}db.timer, fornecendo WantedBy=multi-user.targetna [Install]seção para permitir systemtl enable|disable, mas os links /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerainda serão criados na reinstalação / atualização, reativando efetivamente os .timers.
Você também pode correr systemctl mask man-db.timer updatedb.timerpara mascarar os cronômetros.
Mesmo se ainda fosse possível executar manualmente systemctl start man-db.service updatedb.servicepara iniciar os serviços correspondentes, você não seria capaz de iniciar manualmente os cronômetros, por qualquer motivo que o usuário pudesse querer / precisar fazer.
Esta solução alternativa não permite a /etc/systemd/system/{man-,update}db.timerpresença de arquivos de unidade personalizados substituídos, se desejado / necessário, pois o systemd precisa substituí-los por um link simbólico /dev/nullpara significar uma unidade mascarada.
Mascarar parece ser a solução menos invasiva.
Prefiro remover manualmente /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerapós cada atualização e ter arquivos de unidade substituídos /etc/systemd/system/{man-,update}db.timercom uma [Install]seção WantedBy=multi-user.targetpara ativar systemctl/ desativar a manual .
Infelizmente, não há uma solução simples para isso, pelo menos, no momento, eu posso pensar.
Isso pressupõe que os pacotes man-db, mlocatesão queria / precisava ser mantido instalado 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/
rpmtambém tem--whatrecommends. Eu acho que o Fedora começou a encará-lo como um conceito nos últimos dois anos. (Muito tempo depois do lado do debian / ubuntu ter assumido o padrão de instalar dependências "recomendadas" e "dependentes").