È assolutamente updatedbnecessario? Non uso mai locatee i miei server tendono ad avere dozzine di milioni di file che di solito fanno funzionare b per molto tempo e consumano I / O necessari per MySQL e / o altri software.
Posso semplicemente rimuoverlo da cron e aspettarmi che tutto funzioni? (con tutto ciò che intendo il solito software trovato sul server: linux, cpanel, mysql, apache, php ecc.).
Risposte:
Sì, puoi disabilitarlo nei croni o rimuovere il pacchetto che fornisce updatedb. Su un sistema Red Hat faresti i passaggi per determinare se qualcosa lo richiede prima della rimozione.
Per prima cosa scopri dove si trova il programma sul disco.
$ type updatedb
updatedb is /usr/bin/updatedb
Quindi scopri quale pacchetto fornisce updatedb.
$ rpm -qf /usr/bin/updatedb
mlocate-0.26-3.fc19.x86_64
Vedi se qualcosa richiede mlocate.
$ rpm -q --whatrequires mlocate
no package requires mlocate
Nulla lo richiede per poter rimuovere il pacchetto.
$ yum remove mlocate
/var/lib/mlocate?
Rimuovilo usando il tuo gestore pacchetti, se un altro pacchetto lo usa, lo saprai, poiché deve dipendere da esso (dipendenza del pacchetto).
Ho un server con Nginx, php-fpme mysql, e funziona magnificamente senza updatedb.
aptitude remove, aptitude whyo aptitude search '?installed ?recommends(mlocate)'. Tutto ciò mostrerà delle raccomandazioni per le dipendenze, oltre a quelle richieste. apt ora installa i pacchetti raccomandati di default, quindi sebbene non siano considerati essenziali, si può fare affidamento su di essi per fornire alcune utilissime funzioni secondarie.
Non sto andando molto lontano dicendo questo, ma molto probabilmente non è aggiornatob che sta causando i tuoi problemi. Probabilmente qualcos'altro che non vuoi, o un'applicazione di backup che non hai configurato a tuo piacimento o qualche problema di sicurezza con la struttura del tuo profilo / sistema.
Un altro caso in cui sembra che l'allocazione di memoria dei sistemi stia funzionando contro l'utente è lo scenario in cui uno "inconsapevole impilamento di file system virtuali". E questo è un problema. Una "bomba virtuale mal logica" per così dire.
Accade abbastanza frequentemente le unità USB formattate in fat32 su un sistema ext 4 che vengono poi trasferite su sistemi zfs che sono impostati in modo errato con la shell csh come shell di login man. Crea la ricorsione virtuale del problema "File system USB solo file di lettura" sul disco e formatta / monta l'unità su vFat da fat32, che a sua volta crea un settore di blocchi danneggiati ed estrae (praticamente sposta) una directory fino al suo livello delle directory padre, che causa il ciclo infinito! La directory non è fisicamente a livello gerarchico del genitore. La sintassi delle cause csh è la causa di ciò. * NOTA: l'unità viene letta solo su tutti i sistemi ma su un sistema di login zfs c-shell.
Disabilitare completamente gli aggiornamentib potrebbe creare una logica errata in riferimento all'allocazione della memoria e "l'effetto rollback". Se hai mai avuto un rollback quando non lo volevi, sai cosa intendo quando per due ore vale la riga di comando lo scripting è gestito da Fubar perché non hai allocato il tuo processo di elaborazione in memoria.
Ora se hai due o più processori fisici (ad es. Dual core o più) e ram ddr3, allora va bene. Fintanto che non esegui grafica pesante, nel qual caso se quel carico di potenza sta causando i tuoi problemi, aggiornatob sarebbe l'ultimo del tuo elenco. Se stai cercando di mascherare i tuoi movimenti nel sistema per qualche motivo, allora ci sono altri modi per farlo piuttosto che disabilitare l'aggiornamentob, e infatti aggiornatob rafforzerebbe le tue azioni che "non accade nulla" per quanto riguarda il travestimento al tuo sistema.
Abbastanza francamente basato sulla dimensione del file binario / usr / bin / updatedb e considerando l'architettura della comunicazione segnale / sistema con-nel sistema operativo e che Bash è 10 volte la dimensione di è un trattino di shell reciprocamente collegato o cenere la chiamata asincrona è molto economico sul sistema.
Se hai effettuato l'accesso alla shell eseguendo script sequenziali che hai scritto e sei un amministratore (ad esempio sudo), eseguendo il comando seguente:
~$ sudo bash
:~# ./script.sh
Quindi probabilmente vuoi creare una variabile locale all'interno del tuo script (updateb richiede privilegi di sistema, root / sudo / wheel di AKA), ad esempio:
#! /bin/sh
# Create local variables
UPD="updatedb"
echo "Beginning Execution of sequence "
Nel qual caso la sequenza utilizza STDOUT / STDIN da altri script di shell che hai scritto e che stai eseguendo come variabili con lo script principale o che hai un pacchetto di amministrazione personale o aziendale impostato in cui caricare / scaricare / port da cdrom o usb o qualsiasi altra cosa, che è estremamente grande e hanno script di installazione personali per loro, VUOI TENERE AGGIORNATOb. Quando la shell del terminale è aperta, questa è l'istanza dell'applicazione principale. Altre applicazioni possono / possono essere eseguite in modo asincrono ma l'aggiornamentob è uno dei meno costosi in termini di domanda globale di sistema / elaborazione. Molte volte, specialmente con lxdm Desk Enviro's e Lxterm (quella cosa è super veloce), ma non solo; senza aggiungere updateb ai miei script, il sistema mi ha segnalato errori che i file non esistono o che era successo qualcosa di strano. E mi piace COSA!
La shell è più veloce del sistema che gestisce, te lo garantisco!
In tal caso, dovresti chiamare la variabile updatedb per bloccare in memoria la sequenza precedente, come mostrato
echo "Updating local database "
$UPD
echo "Exiting script two "
exit
Vedi cosa sto dicendo? Se lo chiedi perché stai eseguendo test di velocità di esecuzione, ad es. In stile Andrew Tanenbaum che ce l'hai. Altri saggi usano lo strumento a tuo vantaggio.
locatenon è utile perché non posso essere sicuro che sia indicizzato. Quando i file sono più vecchi, vado per fzfuna ricerca confusa.
Almeno in ArchLinux, sembra che man-db.timere updatedb.timersiano abilitati di default (cioè: esistono i seguenti file), ma c'è 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. [...](output da systemctl enable {man-,update}db.timer).
Questi sono i collegamenti simbolici presenti nel filesystem:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer
Dovrebbe essere una questione di semplicemente rimuoverli.
Tuttavia, essi sarebbero stati ricreati ad ogni re / installazione / aggiornamento di man-db, mlocatepacchetti, rispettivamente.
Per ArchLinux, una possibile soluzione alternativa è avere un hook per pacman per rimuoverli.
Tuttavia, li rimuoverà ad ogni evento di questo tipo, anche se li desideri abilitati attraverso gli aggiornamenti.
In tal caso, è possibile disabilitare l'hook quando si desidera abilitare il timer.
Tuttavia, l'abilitazione del timer avrebbe effetto solo al momento della reinstallazione / installazione / aggiornamento del pacchetto, in quanto non esiste una sezione configurata nei .timerfile di unità predefiniti per indirizzare direttamente systemctl enablei timer. Sarebbe necessario
un manuale ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timero un ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timercomando per abilitare i timer e rimuovere i collegamenti per disabilitarli.
Potresti avere l'override delle unità personalizzate /etc/systemd/system/{man-,update}db.timer, fornendo WantedBy=multi-user.targetnella [Install]sezione per consentire systemtl enable|disable, ma i collegamenti /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerverrebbero comunque creati su re / installazione / aggiornamento, riattivando efficacemente i messaggi di posta elettronica .timer.
Potresti anche correre systemctl mask man-db.timer updatedb.timerper mascherare i timer.
Anche se sarebbe comunque possibile eseguire manualmente systemctl start man-db.service updatedb.serviceper avviare i servizi corrispondenti, non si sarebbe in grado di avviare manualmente i timer, per qualsiasi motivo l'utente si ritenga desideroso / necessario.
Questa soluzione alternativa non consente di sovrascrivere i /etc/systemd/system/{man-,update}db.timerfile di unità personalizzati presenti se desiderato / necessario, poiché systemd deve sostituirli con un collegamento simbolico /dev/nullper indicare un'unità mascherata.
Il mascheramento sembra essere la soluzione meno invadente.
Preferisco rimuovere manualmente /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerdopo ogni aggiornamento e avere l'override dei file di unità /etc/systemd/system/{man-,update}db.timercon una [Install]sezione con WantedBy=multi-user.targetper abilitare systemctl/ disabilitare manualmente .
Sfortunatamente, non esiste una soluzione semplice a questo, che almeno mi viene in mente in questo momento.
Ciò presuppone che i pacchetti man-db, mlocatesi vogliono / bisogno di essere tenuto installata nel sistema: rimuoverli non sarebbe una soluzione desiderata / utile.
Vedi anche questo: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/
rpmha anche--whatrecommends. Penso che Fedora abbia iniziato a considerarlo come un concetto negli ultimi due anni. (Molto tempo dopo che la parte debian / ubuntu era inadempiente nell'installazione delle dipendenze "raccomanda" e "richiede").