Moin,
Nominell sollte ja bei Befehl USB.Free der Befehl USB.cpomReleaseComport durch einen vorhergehenden Aufruf innerhalb der destroy automatisch aufgerufen werden.
Nach einem Blick in das root /var/lock ist die file *Lock...ttyUSBy* aber immer noch im Verzechnis.
Nun meine Frage?
Würde es Eurer Meinung nach Sinn machen diese beim Beenden nochmal auf Existent zu prüfen und bei vorhandensein zu löschen, oder dies in der unit "synaser" als Eigenständige Procedure Nachzutragen?.
Bzw, mit welchem Ziegelstein sorgt ihr für das löschen der entsprechenden File?
Auf dem Verzeichnis /var/Lock habe ich vorsorglich schon mal alle Rechte für den den zulässigen User freigegeben.
Gruß und angenehmen Samstag euch allen
Maik
Lock...ttyUSBx löschen
- Maik81SE
- Beiträge: 327
- Registriert: Fr 30. Sep 2011, 14:07
- OS, Lazarus, FPC: Debian 12 (L 3.4 FPC 3.2.2)
- CPU-Target: x86-64; avr
- Wohnort: Lübeck
- Kontaktdaten:
Lock...ttyUSBx löschen
Code: Alles auswählen
label.caption:= 'gnublin.no-ip.info'
- af0815
- Lazarusforum e. V.
- Beiträge: 6791
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Lock...ttyUSBx löschen
Die Frage ist einmal, warum du dich bei dem USB-Comport direkt mit USB kümmerst. ?
Das Lockfile wird ja von einem Prozess ja nicht zum Spaß geschrieben und du solltest mal den Grund ergründen, warum das Lockfile nicht verschwindet. Das heißt normalerweise das ein Prozess nicht korrekt heruntergefahren wurde. Was man nicht machen sollte, ist einfach den Lock zu entfernen - das ist so wie bei Kopfschmerzen den Kopf einfach abzuschneiden. Vor allen käme mir nie in den Sinn einem Benutzer dort Rechte zu geben.
In deinem Fall wird der Comport vermutlich von einem Prozess/Programm verwendet und ev. über einen Kill Befehl abgewürgt, so das es gar keine Möglichkeit hatte das Lock wieder zu löschen.
Siehe auch https://www.linux-magazin.de/ausgaben/2 ... bashing/2/ im Artikel unten steht ein Hinweis dazu.
Das Lockfile wird ja von einem Prozess ja nicht zum Spaß geschrieben und du solltest mal den Grund ergründen, warum das Lockfile nicht verschwindet. Das heißt normalerweise das ein Prozess nicht korrekt heruntergefahren wurde. Was man nicht machen sollte, ist einfach den Lock zu entfernen - das ist so wie bei Kopfschmerzen den Kopf einfach abzuschneiden. Vor allen käme mir nie in den Sinn einem Benutzer dort Rechte zu geben.
In deinem Fall wird der Comport vermutlich von einem Prozess/Programm verwendet und ev. über einen Kill Befehl abgewürgt, so das es gar keine Möglichkeit hatte das Lock wieder zu löschen.
Siehe auch https://www.linux-magazin.de/ausgaben/2 ... bashing/2/ im Artikel unten steht ein Hinweis dazu.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
- Maik81SE
- Beiträge: 327
- Registriert: Fr 30. Sep 2011, 14:07
- OS, Lazarus, FPC: Debian 12 (L 3.4 FPC 3.2.2)
- CPU-Target: x86-64; avr
- Wohnort: Lübeck
- Kontaktdaten:
Re: Lock...ttyUSBx löschen
Dies muß ich wohl bestätigen, wenn ich den Debugger "Abbreche" und nicht wie es sein soll das Programm an sich beende.af0815 hat geschrieben: Sa 26. Feb 2022, 15:24In deinem Fall wird der Comport vermutlich von einem Prozess/Programm verwendet und ev. über einen Kill Befehl abgewürgt, so das es gar keine Möglichkeit hatte das Lock wieder zu löschen.
Wobei ich auch schon in 1 von ca 300 - 500 Fällen das Glück hatte, das selbst bei einem Normalen Beenden die Lock-File noch da stand. o.O
Aber mit dem Wissen kann ich ja im Vorfeld schon mal eine Anfrage auf die Existieren File setzen und ggf. dann die Ausführung unterbinden, sofern diese sich in der FormCreate nicht löschen lässt.
Danke für den Hinweiß.
Code: Alles auswählen
label.caption:= 'gnublin.no-ip.info'