hannes22
Anmeldungsdatum: 20. August 2009
Beiträge: 266
|
Moin, ich habe ein Programm, welches auf einen Chip zugreift. Wenn nun 2 Cronjobs zur gleichen Zeit gestartet werden ...
Ich möchte jetzt das Programm ändern und eine Lockdatei einführen.
(Mir ist klar das ich eigentlich einen Treiber schreiben müsste) Wird unter Ubuntu / Linux standardmäßig ein Dateisystem im Ram angelegt, das ich dafür nutzen könnte ? Danke schnonmal! Hannes
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8493
|
Schau mal unter Verzeichnisstruktur. Muss doch nicht unbedingt im RAM liegen oder? Ich würde die Datei einfach unter /tmp ablegen. Eine Alternative wäre eine Prüfung beim Start, ob schon eine Instanz läuft. Dann brauchst Du keine Lock-Datei.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
hannes22 schrieb: ich habe ein Programm, welches auf einen Chip zugreift. Wenn nun 2 Cronjobs zur gleichen Zeit gestartet werden ...
Warum 2 Cron-Jobs? Ich möchte jetzt das Programm ändern und eine Lockdatei einführen.
Du könntest dafür flock nutzen. (Mir ist klar das ich eigentlich einen Treiber schreiben müsste)
Eigentlich reicht doch auch ein Dienst, der das Auslesen zu eingestellten Zeitintervallen übernimmt. systemd/Timer Units sind z.B. eine gute Alternative zu Cron-Jobs, denn bei Systemd-Units gibt es standardmäßig das Feature, dass nur eine Instanz gestartet werden kann (wenn man die Unit nicht extra als Template für eine Instance-Variable schreibt).
|
hannes22
(Themenstarter)
Anmeldungsdatum: 20. August 2009
Beiträge: 266
|
Danke! Gute Ideen. Ja, es soll möglichst im Ram laufen, weil es sich um einen Raspi handelt und da mag ich es nicht wenn ständig auf die SD Karte geschrieben wird. Es ist ein Sender für Funksteckdosen und da kann es vorkommen, dass zwei gleichzeitig schalten sollen. In der crontab stehen die Zeilen nicht immer beieinander. Auf jeden Fall ist es fehlerträchtig. Ich werde mal über die Instanceprüfung nachdenken. Schönen Abend wünsche ich! Ach jetzt wo ich es schreibe, es ist ja ein Raspi. Ich hab nachgesehen, dort werden einige Ramdisks eingerichtet, unter anderen /run/lock/ wo jeder schreiben kann. Dann werde ich dies nehmen, das ist das einfachste. Schade das soetwas nicht auf einem PC eingerichtet wird. Ich hab mal auf einem PC nachgesehen, da gibt es genau das gleiche Verzeichnis, auch tmpfs! Super! Eure Ideen sind trotzdem gut. Nun aber: Schönen Abend wünsche ich! Hannes
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
hannes22 schrieb: Ach jetzt wo ich es schreibe, es ist ja ein Raspi. Ich hab nachgesehen, dort werden einige Ramdisks eingerichtet, unter anderen /run/lock/ wo jeder schreiben kann. Dann werde ich dies nehmen, das ist das einfachste. Schade das soetwas nicht auf einem PC eingerichtet wird. Ich hab mal auf einem PC nachgesehen, da gibt es genau das gleiche Verzeichnis, auch tmpfs! Super!
Häh bitte was? 😲 Auf welchen PCs wird kein tmpfs eingerichtet? Wenn hängt das wohl eher von der Distro und der Version dieser Distro ab. Du kannst auch einfach selbst ein tmpfs deklarieren in der /etc/fstab - das ich für /tmp sowieso immer. Weil /tmp so ein Verzeichnis ist, dass bei jedem reboot sonst eh geleert wird.
|
Dogeater
Anmeldungsdatum: 16. Juni 2015
Beiträge: 3381
|
Verstehe die Annahme auch nicht, dass es kein tmpfs auf normalen PCs geben sollte. Nur um klugzuscheißen: tmpfs muss im Kernel auch erlaubt worden sein, sonst tut es nicht. 😉 Allerdings dürfte das zu 99% auf alle Systeme zutreffen. Benötigter Kernel: Mit gutem Gewissen alle ab Version 2.6.30 (soweit mein Hirn erinnerungsbezogen noch funktioniert). Auf einem superlahmen USB-Stick habe ich mir die folgende fstab gebaut. #
# /etc/fstab
# Created by anaconda on Sun Feb 4 07:38:15 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
#UUID=b0bb2100-6245-4679-be1b-dbe7032df12e / ext4 defaults 1 1
#UUID=1660a090-7730-43c1-b8c2-321b38ec444f /home ext4 defaults 1 2
#noauto,users,noatime,flush,umask=111,dmask=000
UUID=b0bb2100-6245-4679-be1b-dbe7032df12e / ext4 rw,suid,dev,exec,auto,nouser,noatime 0 1
UUID=1660a090-7730-43c1-b8c2-321b38ec444f /home ext4 rw,suid,dev,exec,auto,nouser,noatime 0 2
tmpfs /home/burni/.cache tmpfs defaults 0 0
#tmpfs /home/burni/.mozilla/firefox tmpfs defaults 0 0
#tmpfs /usr/share tmpfs defaults 0 0
#tmpfs /usr/lib tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/run tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/cache tmpfs defaults 0 0
#https://de.wikibooks.org/wiki/Linux-Praxisbuch:_fstab
#rw,suid,dev,exec,auto,nouser,async
#relatime,nodiratime
#size=10M
#blksize=4096
#commit=600
Unzensiert, incl. Notizen meinerseits. tmpfs hat eine rosige Zukunft. Es fehlt halt noch die unkomplizierte Persistenz.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
Dogeater schrieb: Es fehlt halt noch die unkomplizierte Persistenz.
Das ist nicht die Aufgabe von tmpfs. Der richtige Ort für die Lockfiles vom TE ist übrigens /var/lock oder /run/lock, zumindest letzteres liegt im Standard in einem tmpfs ohne das man schwarze Magie anwenden müsste. mfg Stefan
|
Dogeater
Anmeldungsdatum: 16. Juni 2015
Beiträge: 3381
|
Absolut richtig. Dass man "Lösungen" dafür von github clonen muss und auf seinem System noch kompilieren muss, was dann fehlschlägt, weil es sich nicht um ein ArchLinux handelt, das ist vielleicht... ähm... eh ein ganz anderes Thema. 😬 Dafür braucht es aber eine allgemeingültige Lösung in den nächsten Jahren, ein Lösung, die nicht nur die Supermenschen die auch den vi bedienen können, anwenden können.
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
encbladexp schrieb: Dogeater schrieb: Es fehlt halt noch die unkomplizierte Persistenz.
Das ist nicht die Aufgabe von tmpfs. Der richtige Ort für die Lockfiles vom TE ist übrigens /var/lock oder /run/lock, zumindest letzteres liegt im Standard in einem tmpfs ohne das man schwarze Magie anwenden müsste.
Eine neue Zeile in /etc/fstab ist jetzt neuerdings schon schwarze Magie, soso 😊
|
hannes22
(Themenstarter)
Anmeldungsdatum: 20. August 2009
Beiträge: 266
|
Ich hatte vergessen das Thema als gelöst zu kennzeichnen. Trotzdem sehr interessant eure Diskussion. Aber eine Sache wäre da noch: Es werden u.a. 2 tmpfs eingerichtet nämlich /run/ und /run/lock/ was ich mir nicht erklären kann. 1.) Wenn /run/ ein tmpfs ist ist ja auch /run/lock/ auf dem tmpfs. Was soll der extra Eintrag? Die Möglichkeit für /run/lock/ eine Max.Größe anzugeben? Na gut. Aber: 2.) Das funktioniert ja gar nicht! (Na ja, offensichtlich schon.) Wenn es in root ein leeres /run/ gibt, kann dort ein tmpfs eingehängt werden, welches aber leer ist. Wo kommt dann der Einhängepunkt /run/lock her? Soll heißen ich könnte soetwas nicht in der fstab eintragen!? Ist ja nicht wirklich wichtig, bringt mich aber ans grübeln. Gruß Hannes
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
Also das versteh ich schon wieder nicht. Wo bitte ist denn jetzt das Problem? 😕
Du legst ein leeres Verzeichnis irgendwo an, das wird dein neuer mountpoint für die ramdisk (tmpfs). Und das muss auch nicht irgendwo in /tmp sein. Legs deine Tempfiles doch direkt nach /tmp und fertig. Für /run und /run/lock Dafür dürfte systemd verantwortlich ein. /run ist eine größere ramdisk als die in /run/lock, so siehts zB bei mir aus: Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
tmpfs tmpfs 1,7G 11M 1,7G 1% /run
tmpfs tmpfs 5,3M 4,1k 5,3M 1% /run/lock
|
hannes22
(Themenstarter)
Anmeldungsdatum: 20. August 2009
Beiträge: 266
|
Hallo Cosinus,
das ursprüngliche Problem ist mit /run/lock/ gelöst. Bei dieser Konstruktion
| Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
tmpfs tmpfs 1,7G 11M 1,7G 1% /run
tmpfs tmpfs 5,3M 4,1k 5,3M 1% /run/lock
|
fällt auf, das ich dies nicht mit der fstab erzeugen könnte. Also ich kann nicht tmpfs /A/ tmpfs /A/B/ erzeugen. Meines Wissens kann man Filesysteme nur an leere Verzeichnisse binden. Ich kann ein leeres /A/ erzeugen und dort das tmpfs anhängen. /A/ ist dann aber leer und ich kann mit der fstab kein tmpfs an /A/B/ hängen weil das nicht existiert. Ich erzeuge /A/ und /A/B/. Dann ist aber /A/ nicht leer und ich kann dort kein tmpfs anhängen. Einzige Möglichkeit, ich erzeuge /A/, hänge dort ein tmpfs ein und erzeuge dann /A/B/ auf dem tmpfs wo ich dann ein zweites tmpfs anhängen kann. Nur kann ich während der Verarbeitung der fstab keine Verzeichnisse erzeugen. Die Frage ist also wie bekommen die das hin? (reine Neugier, ich brauche das nicht)
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
Das Problem bei einer ramdisk (tmpfs) ist ja, das RAM flüchtiger Speicher ist - sprich bei jedem reboot ist alles wieder weg! Du müsstest also wenn du einen Mountpoint in einer ramdisk hast, bei jedem Hochfahren erstmal dieses Verzeichnis für diesen Mountpoint neu erstellen. Also zB so: 1. tmpfs nach /A mounten 2. mkdir /A/B 3. weiteres tmpfs nach /A/B mounten
Nun klarer?
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
cosinus schrieb: Eine neue Zeile in /etc/fstab ist jetzt neuerdings schon schwarze Magie, soso 😊
Ja, jede Lösung die "Ich muss in einer kryptischen Konfigurationsdatei was als root reinmalen" ist für einen Laien Schwarze Magie. mfg Stefan
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
encbladexp schrieb: cosinus schrieb: Eine neue Zeile in /etc/fstab ist jetzt neuerdings schon schwarze Magie, soso 😊
Ja, jede Lösung die "Ich muss in einer kryptischen Konfigurationsdatei was als root reinmalen" ist für einen Laien Schwarze Magie.
Als Mausschubser auf jeden Fall! 😈
|