Problems using influxDB on an external SSD
-
Any other logs I can provide to solve the problem?
-
@meister-mopper said in Problems using influxDB on an external SSD:
better:
show logs only when it happensWhat do you mean by this?
-
Mar 24 18:28:31 ioBroker usbmount[300]: /dev/sda does not contain a filesystem or disklabel Mar 24 18:28:31 ioBroker systemd-udevd[169]: Process '/usr/share/usbmount/usbmount add' failed with exit code 1. Mar 24 18:28:31 ioBroker systemd-udevd[159]: Process '/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev' failed with exit code 1.Da ist wohl auf dem Speichermedium /dev/sda was krumm.
Und dann schalte den Desktop-Mist (mit Remote-Desktop) aus. Server immer ohne GUI, per SSH-Zugang betreiben. -
@thomas-braun said in Problems using influxDB on an external SSD:
/dev/sda does not contain a filesystem or disklabel
Was kann da falsch sein? Ich kann normal darauf zugreifen und lesen und schreiben.
Ich habe auf einer Seite gelesen, dass es falsch eingebunden ist und man nur mit Root Rechten darauf zugreifen kann und es daran liegen soll.
pi@ioBroker:~ $ ls -l /media insgesamt 32 lrwxrwxrwx 1 root root 4 Sep 28 15:54 usb -> usb0 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb0 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb1 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb2 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb3 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb4 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb5 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb6 drwxr-xr-x 2 root root 4096 Sep 28 15:54 usb7Wie kann ich das Problem beheben??
-
@thomas-braun Kann ich noch etwas machen? Ich habe leider das Problem immer noch nicht gelöst.
-
Keine Ahnung. Mir ist immer noch nicht klar, wie das Dateisystem gemounted wird. Per automount?
-
@thomas-braun sagte in Problems using influxDB on an external SSD:
dev/sda does not contain a filesystem or disklabel
bedeutet doch eher, das die Platte nicht korrekt formatiert ist
@Mathias2803 vllt hilft https://github.com/rbrito/usbmount/issues/24
-
Ja, hatte ich ja auch schon geschrieben.
-
Das mouten passiert durch "/etc/fstab" und dem Eintrag:
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw 0 2"
-
@crunchip
Die Platte ist normal ansprechbar. Ich kann dort Dateien schreiben und lesen.Nachdem ich Datenbank von influxDB von der Sicherungskopie, die auch auf der externen Platte liegt, wieder hergestellt habe, läuft das Logging auch auf der externen Platte ohne Probleme.
Jedoch sobald ich das System neu starte mit "sudo reboot" ist wieder alles kaputt und ich muss wieder alles kompliziert herstellen. Also zuerst alle Systeme deaktivieren, dann die DB löschen, aus dem BackUp wieder herstellen und wieder alles neu starten...
Schlimm ist wenn das System aus anderen Gründen neu startet, ich kein aktuelles BackUp habe,... jedes Mal Daten Verlust...
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
nofail,rw
Das sind zu wenig Optionen.
Ich würde da wenigstens 'defaults' noch setzen, besser noch den richtigen User, der drauf schreiben soll. -
@thomas-braun
Der Kommentar von Meister Mopper am 24 Mar 2022, 17:29 fand ich interessant.
Aber so wie er geschrieben war konnte ich ihn nicht umsetzten und ich hatte Angst, dass wenn ich etwas falsch mache, ich das komplette System zerstöre.Ich kann mir folgendes vorstellen:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
2.) dass nach dem Neustart die Zugriffsrechte der Platte nicht richtig sind (diese muss ich nach dem Löschen und wieder herstellen manuell setzten) und deshalb influxDB den Fehler macht.Oder natürlich etwas anderes. Aber wie ich das rausfinden und beheben kann, weiß ich leider nicht.
Ich unterstütze gerne mit Logs und freue mich über alle Tipps. Danke
-
@thomas-braun
Das hört sich nach meiner "Option 2" an. Kennst du dich da besser aus? Wie kann ich das Mouten "optimal" einstellen?- Also lange genug warten, dass infuxDB auf jeden Fall nach dem Mounten startet. Aber falls die Platte defekt ist, trotzdem nicht endlos hängen bleiben.
- InfluxDB oder besser alle Benutzer vollen schreibe und Lese Zugriffe haben
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
1.) dass das System hochfährt, die Platte erst nach dem Start von influxDB verbunden wird und sie deshalb an einer anderen Stelle etwas schreibt.
Die Reihenfolge wie Dienste gestartet werden kann man in systemd sehr genau definieren. Das mounten der Dateisysteme (per fstab) geschieht allerdings recht früh, das wird vermutlich nicht ursächlich sein.
-
@thomas-braun
Und wie stelle ich die Zugriffsrechte richtig ein? -
Schau in die man-page:
https://linux.die.net/man/8/mount
Da stehen alle Optionen für die einzelnen Dateisysteme drin.
-
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
"UUID="49441976-e29b-4acc-a8ee-71f4eb91255c" /mnt/mySSD ext4 nofail,rw,users 0 2"
Oder wie stelle ich ein, dass jeder volle Zugriffsrechte auf die Platte hat?
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
Ist es ausreichend, wenn ich an meinen mount Befehl "users" anhänge?
Nein, lt. man page beschreibt das nur, dass jeder user das Dateisystem mounten darf.
Die Rechte ergeben sich aus den Rechten des mount-Punktes.Man kann nach dem mounten z. B. so in der Art die Rechte vergeben:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data -
@thomas-braun said in Problems using influxDB on an external SSD:
sudo chown -R UserNameOfSudo:users /media/data sudo chmod -R g+rw /media/data
Aber das kann ich dann nicht in "/etc/fstab" reinschreiben. Ich müsste es in einen Chronjob nach dem Start? Oder wie lege ich das fest? Ist das dann nicht wieder zu spät, also erst nachdem schon influxDB gestartet ist?
-
@mathias2803 sagte in Problems using influxDB on an external SSD:
/media/data
Wie sehen die Rechte an /media/data aus, wenn das Dateisystem nicht gemounted ist?
