Ich hatte ja vor vielen Monaten von der Version 4.2 ein Upgrade auf die Version 4.4 gemacht. Das große Problem war immer, die Repo-Datei unter /etc/yum.d wurde nie von Fedora 38 anerkannt. Bei jedem Update hat es übergangen.

Weil ja bald Fedora 40 herauskommt und damit auch der Support für Fedora 38 danach endet, wollte ich mich endlich um MongoDB 4.4 kümmern.

Ich habe mich entschlossen, auf die aktuellste Version 7.0 upzugraden. Also die repo-Datei auf 7.0 umgestellt. Wunderbar, lief auch bei

sudo dnf upgrade

durch. Keinerlei Fehlermeldungen. Nur ich kann MongoDB nicht mehr starten. Also nicht die Shell über mongosh und jedes Mal, wenn ich mit

sudo systemctl start mongod.service

gestartet habe, stürzt der Server innerhalb einer Sekunde ab.

Ich bin mit der KI von Google Gemini dabei, das zu beheben. Dafür ist die KI vorzüglich, denn sie macht das bedingungslos mit, während ein anderer Mensch das schon längst gesagt hätte: „Habe ich keine Lust dazu.“ (außer er bekäme dafür Geld – aber aus Jux und Dollerei würde mir keiner helfen).

sudo journalctl -u mongod

gibt Folgendes heraus:

Mär 27 16:53:58 localhost.localdomain systemd[1]: mongod.service: Failed with result ‚exit-code‘.
Mär 27 16:53:58 localhost.localdomain systemd[1]: mongod.service: Consumed 1.588s CPU time.
Mär 27 17:29:16 localhost.localdomain systemd[1]: Started mongod.service – MongoDB Database Server.
Mär 27 17:29:16 localhost.localdomain mongod[7946]: {„t“:{„$date“:“2024-03-27T16:29:16.788Z“},“s“:“I“, „c“:“CONTROL“, „id“:7484500, „ctx“:“main“,“msg“:“Environment variable MONGODB_CONFIG_OVERRIDE_NOFORK == 1,>
Mär 27 17:29:23 localhost.localdomain systemd[1]: mongod.service: Main process exited, code=exited, status=62/n/a
Mär 27 17:29:23 localhost.localdomain systemd[1]: mongod.service: Failed with result ‚exit-code‘.
Mär 27 17:29:23 localhost.localdomain systemd[1]: mongod.service: Consumed 1.425s CPU time.
Mär 27 17:29:41 localhost.localdomain systemd[1]: Started mongod.service – MongoDB Database Server.
Mär 27 17:29:41 localhost.localdomain mongod[8012]: {„t“:{„$date“:“2024-03-27T16:29:41.141Z“},“s“:“I“, „c“:“CONTROL“, „id“:7484500, „ctx“:“main“,“msg“:“Environment variable MONGODB_CONFIG_OVERRIDE_NOFORK == 1,>
Mär 27 17:29:45 localhost.localdomain systemd[1]: mongod.service: Main process exited, code=exited, status=62/n/a
Mär 27 17:29:45 localhost.localdomain systemd[1]: mongod.service: Failed with result ‚exit-code‘.
Mär 27 17:29:45 localhost.localdomain systemd[1]: mongod.service: Consumed 1.321s CPU time.
Mär 27 17:30:25 localhost.localdomain systemd[1]: Started mongod.service – MongoDB Database Server.
Mär 27 17:30:25 localhost.localdomain mongod[8117]: {„t“:{„$date“:“2024-03-27T16:30:25.560Z“},“s“:“I“, „c“:“CONTROL“, „id“:7484500, „ctx“:“main“,“msg“:“Environment variable MONGODB_CONFIG_OVERRIDE_NOFORK == 1,>
Mär 27 17:30:29 localhost.localdomain systemd[1]: mongod.service: Main process exited, code=exited, status=62/n/a
Mär 27 17:30:29 localhost.localdomain systemd[1]: mongod.service: Failed with result ‚exit-code‘.

Auffällig ist, dass es den Status 62 gibt.

sudo ps aux | grep mongod
sven 11554 0.0 0.0 222432 2176 pts/0 S+ 18:28 0:00 grep –color=auto mongod

ls -ld /var/lib/mongo /etc/mongod.conf
-rw-r–r–. 1 root root 680 27. Mär 17:51 /etc/mongod.conf
drwxr-xr-x. 4 mongod mongod 12288 27. Mär 18:22 /var/lib/mongo

(PS: Ich habe vorher natürlich ein Backup der 19 MB Datenbank gemacht).

Kommt jetzt einer mit Datenschutzbedenken an. Gerne. Dann kann er mir das Problem lösen, den Server wieder dauerhaft zum Laufen zu bringen und mir den Zugang zur Datenbank herstellen, ansonsten frage ich Gemini, die KI von Google munter darauf los. Ich habe keine Scheu damit. Klar, schauen Menschen auch darauf, wird auch hingewiesen, aber wie gesagt, solange Menschen mir bestimmt sagen werden, dass sie sich dafür nicht zuständig fühlen, ist es mir egal.

Die Datenbank möchte ich natürlich wieder benutzen und möglichst lange. Ja sie ist mir äußerst wichtig. Die MySQL und SQLite 3 Datenbanken sind für mich bedeutungslos, eher ein Nice-to-have.