Kann ich updatedb einfach deaktivieren?

Ist überhaupt updatedbnötig? Ich verwende nie locateund meine Server haben in der Regel Dutzende von Millionen von Dateien, was dazu führt, dass updatedb für eine lange Zeit ausgeführt wird und die von MySQL und / oder anderer Software benötigten E / A verbraucht.

Kann ich es einfach von cron entfernen und damit rechnen, dass alles funktioniert? (Mit allem meine ich die auf dem Server übliche Software: Linux, Cpanel, MySQL, Apache, PHP usw.).

Ja, Sie können es in den Cron deaktivieren oder das bereitgestellte Paket entfernen updatedb. Auf einem Red Hat-System müssen Sie vor dem Entfernen die erforderlichen Schritte ausführen, um festzustellen, ob etwas erforderlich ist.

1. Finden Sie zuerst heraus, wo sich das Programm auf der Festplatte befindet.

   $ type updatedb
   updatedb is /usr/bin/updatedb
   

2. Als nächstes erfahren Sie, was das Paket bietet updatedb.

   $ rpm -qf /usr/bin/updatedb
   mlocate-0.26-3.fc19.x86_64
   

3. Überprüfen Sie, ob etwas erforderlich ist mlocate.

   $ rpm -q --whatrequires mlocate
   no package requires mlocate
   

4. Nichts erfordert es, also können Sie das Paket entfernen.

   $ yum remove mlocate
   

Sie können das Scannen von Verzeichnissen mit vielen Dateien deaktivieren, /var/wwwindem Sie beispielsweise die /etc/updatedb.confKonfigurationsdatei bearbeiten . Wenn Sie es wirklich deaktivieren möchten, entfernen Sie einfach den Cronjob.

Entfernen Sie es mit Ihrem Paketmanager. Wenn ein anderes Paket es verwendet, wissen Sie, dass es davon abhängen muss (Paketabhängigkeit).

Ich habe einen Server mit Nginx, php-fpmund mysql, und es funktioniert wunderbar ohne updatedb.

Ich werde nicht zu weit gehen, indem ich das sage, aber höchstwahrscheinlich ist es nicht aktualisiert, was deine Probleme verursacht. Möglicherweise etwas anderes, das Sie nicht möchten, entweder eine Backup-Anwendung, die Sie nicht nach Ihren Wünschen konfiguriert haben, oder ein Sicherheitsproblem mit Ihrer Profil- / Systemgruppenstruktur.

Ein anderer Fall, in dem es den Anschein hat, dass die Systemspeicherzuweisung dem Benutzer zuwiderläuft, ist das Szenario, in dem man "nicht weiß, wie virtuelle Dateisysteme gestapelt werden". Und das ist ein Problem. Sozusagen eine 'virtuelle, unlogische Bombe'.

Es kommt ziemlich häufig vor, dass USB-Laufwerke, die in fat32 auf einem ext 4-System formatiert sind, auf zfs-Systeme übertragen werden, die nicht ordnungsgemäß mit der csh-Shell als man-Login-Shell eingerichtet sind. Es erstellt die virtuelle Rekursion des Problems "Nur-Datei-USB-Dateisystem" auf der Festplatte und formatiert / hängt das Laufwerk von fat32 in vFat ein, wodurch wiederum ein Sektor mit fehlerhaften Blöcken erstellt wird, und extrahiert (verschiebt) virtuell ein Verzeichnis bis zu seinem übergeordnete Verzeichnisebene, die die Endlosschleife verursacht! Das Verzeichnis befindet sich physisch nicht auf der Hierarchieebene des übergeordneten Elements. Die Syntax der csh-Ursachen ist die Ursache dafür. * HINWEIS: Das Laufwerk ist auf allen Systemen außer auf einem zfs-C-Shell-Anmeldesystem schreibgeschützt.

Das vollständige Deaktivieren von updatedb kann zu einer schlechten Logik in Bezug auf die Speicherzuweisung und den "Rollback-Effekt" führen. Wenn Sie jemals ein Rollback durchgeführt haben, als Sie es nicht wollten, wissen Sie, was ich meine, wenn die Befehlszeile zwei Stunden lang ist Die Skripterstellung ist fubar-ed, weil Sie Ihre Jobverarbeitung nicht in den Arbeitsspeicher aufgeteilt haben.

Wenn Sie nun zwei oder mehr physische Prozessoren (z. B. Dual Core oder mehr) und einen DDR3-RAM haben, ist das in Ordnung. Solange Sie nicht überlastete Grafiken verwenden. In diesem Fall steht updatedb an letzter Stelle auf Ihrer Liste, wenn diese Last Ihre Probleme verursacht. Wenn Sie versuchen, Ihre Bewegungen im System aus irgendeinem Grund zu verschleiern, gibt es andere Möglichkeiten, als updatedb zu deaktivieren, und updatedb würde in der Tat Ihre Aktionen festigen, dass "nichts passiert", was Ihr System verschleiert.

Ganz offen gesagt, basierend auf der Größe der Binärdatei / usr / bin / updatedb und unter Berücksichtigung der Architektur der Signal- / Systemkommunikation mit dem Betriebssystem und der Tatsache, dass Bash das 10-fache der Größe eines wechselseitig verknüpften Shell-Strichs oder eines asynchronen Aufrufs ist sehr günstig auf dem System.

Wenn Sie in der Shell angemeldet sind, in der von Ihnen geschriebene sequentielle Skripte ausgeführt werden, und ein Administrator (z. B. sudo) sind, führen Sie den folgenden Befehl aus:

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

Dann möchten Sie wahrscheinlich eine lokale Variable in Ihrem Skript erstellen (updatedb benötigt Systemprivilegien, AKA root / sudo / wheel), zB:

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

echo "Beginning Execution of sequence "

In diesem Fall verwendet die Sequenz STDOUT / STDIN aus anderen Shell-Skripten, die Sie in Ihrem Hauptskript als Variablen geschrieben und ausgeführt haben, oder Sie haben ein persönliches oder geschäftliches Administrationspaket eingerichtet, in das Sie von CD-ROM oder CD-ROM hochladen / herunterladen / portieren usb oder was auch immer, das ist extrem groß und hat persönliche Installationsskripte für sie, SIE MÖCHTEN AKTUALISIERT BLEIBEN. Wenn die Terminal-Shell geöffnet ist, ist dies Ihre Hauptanwendungsinstanz. Andere Anwendungen können / werden asynchron ausgeführt, werden jedoch aktualisiert. Dies ist eine der niedrigsten Kosten in Bezug auf die Gesamtnachfrage nach Systemen / Computern. Viele Male, besonders beim lxdm Desk Enviro und dem Lxterm (das Ding ist super schnell), aber nicht nur; Ohne meinen Skripten "updatedb" hinzuzufügen, hat das System mir Fehler gemeldet, die besagen, dass die Dateien nicht vorhanden sind oder dass etwas Verrücktes passiert ist. Und ich bin wie was!

Die Shell ist schneller als das System, das sie verwaltet. Ich garantiere Ihnen das!

In diesem Fall würden Sie die Variable updatedb aufrufen, um die vorherige Sequenz wie gezeigt im Speicher zu speichern

echo "Updating local database "

$UPD

echo "Exiting script two "

exit

Sehen Sie, was ich sage? Wenn Sie dies fragen, weil Sie Ausführungstests ausführen, zB Andrew Tanenbaum-Stil, dann haben Sie es. Andernfalls nutzen Sie das Tool zu Ihrem Vorteil.

Zumindest in ArchLinux scheint es, dass man-db.timerund updatedb.timerstandardmäßig aktiviert sind (dh: die folgenden Dateien existieren), aber es gibt 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. [...](Ausgabe von systemctl enable {man-,update}db.timer).

Dies sind die symbolischen Links, die im Dateisystem vorhanden sind:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer

Es sollte nur darum gehen, sie zu entfernen.
Allerdings würden sie bei jeder re / Installation / Upgrade von neu erstellt werden man-db, mlocatePakete, respectively.

Für ArchLinux besteht eine mögliche Problemumgehung darin, einen Haken zu haben, mit dem Pacman sie entfernen kann.
Sie werden jedoch bei jedem solchen Ereignis entfernt, selbst wenn Sie möchten, dass sie über Upgrades hinweg aktiviert werden.
In diesem Fall können Sie den Hook deaktivieren, wenn der Timer aktiviert werden soll.
Die Aktivierung des Timers würde jedoch nur bei Neuinstallation / Upgrade des Pakets wirksam, da in den Standard- .timerGerätedateien kein konfigurierter Abschnitt für die direkten systemctl enableTimer vorhanden ist.
Ein Handbuch ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timeroder ein ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timerBefehl wäre erforderlich, um den / die Timer zu aktivieren und die Verknüpfungen zu entfernen, um sie zu deaktivieren.

Sie haben möglicherweise die Möglichkeit , benutzerdefinierte Einheiten zu überschreiben /etc/systemd/system/{man-,update}db.timer, sofern dies WantedBy=multi-user.targetim entsprechenden [Install]Abschnitt vorgesehen systemtl enable|disableist. Die Links werden /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerjedoch weiterhin bei Neuinstallation / Upgrade erstellt, wodurch die .timers wieder aktiviert werden .

Sie können auch laufen systemctl mask man-db.timer updatedb.timer, um die Timer zu maskieren.
Selbst wenn es immer noch möglich wäre systemctl start man-db.service updatedb.service, die entsprechenden Dienste manuell zu starten, könnten Sie die Zeitgeber nicht manuell starten, aus welchem ​​Grund auch immer der Benutzer dies tun möchte / muss.
Bei dieser Problemumgehung ist es nicht möglich, benutzerdefinierte /etc/systemd/system/{man-,update}db.timerEinheitendateien bei Bedarf zu überschreiben , da systemd sie durch eine symbolische Verknüpfung ersetzen muss, um /dev/nulleine maskierte Einheit zu kennzeichnen.

Die Maskierung scheint die am wenigsten aufdringliche Lösung zu sein.
Ich bevorzuge das manuelle Entfernen /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timernach jedem Upgrade und das Überschreiben von Gerätedateien /etc/systemd/system/{man-,update}db.timermit einem [Install]Abschnitt WantedBy=multi-user.targetzum manuellen systemctlAktivieren / Deaktivieren.

Leider gibt es diesbezüglich keine einfache Umgehung, die ich mir derzeit zumindest vorstellen kann.
Dies setzt voraus , dass die Pakete man-db, mlocatewerden wollen / erforderlich gehalten im System installiert werden: Entfernen von ihnen würden eine gewünschte / nützliche Lösung nicht sein.

Siehe dazu auch: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/