[s_theCapt]

#raspberrypi #raspbian #linux #programowanie
Mój program łączy się z portem COM na Raspbianie i tworzy plik /var/lock/LCK..ttyS0. W razie niepoprawnego zamknięcia programu (a tak go wyłączam, po prostu "poweroff" przez SSH) ten plik zostaje i po resecie już się nie łączy z portem (a program jest w autostarcie), bo " Permission error while locking the device (ttyS0)". Nie bardzo mogę usuwać ten plik z programu, bo nie chcę mu dawać praw administratora. Czy te locki w /var/lock nie powinny znikać po zamknięciu systemu? Jak zrobić żeby to robiły?

[l1ght]

tworzy plik /var/lock/LCK..ttyS0

Nie bardzo mogę usuwać ten plik z programu

@s_theCapt: kto tworzy ten plik?

[s_theCapt]

@l1ght: mój program, otwieram port poprzez klasę QSerialPort (C++, Qt) i ona tworzy ten plik i nie mogę tego zmienić chyba łatwo. ;c

[n.....a]

@s_theCapt: Zamknij port com przed wyjściem z programu

[l1ght]

Zamknij port com przed wyjściem z programu

@s_theCapt: +1 dla tego pana wyżej
pokaż

ls -ld /var/lock

i

ls -ld /run/lock

[szokiniedowierzanie]

@s_theCapt: najprawdopodobniej przy wyłączeniu przez "poweroff" system ubija Ci program(jak kill -9).
Aby to poprawić musisz w swojej aplikacji przechwycić sygnały SIGTERM i SIGHUP, a następnie zakończyć poprawnie działanie programu.
Zobacz jak ja to robię u siebie (też program w C++ i Qt) w linii 72, w pliku main.cpp:
https://github.com/sin2000/zdownloader/blob/master/src/zdownloader/src/main.cpp

[s_theCapt]

@l1ght: nie mogę na to liczyć, to jest hardware który klient może źle wyłączyć i co wtedy? Muszę mieć odporne na to rozwiązanie.
@szokiniedowierzanie: takiego czegoś szukałem, dziękuję!

[l1ght]

który klient może źle wyłączyć i co wtedy

@s_theCapt: sigkill i tak nigdy nie złapiesz, ten lock domyślnie powinien się tworzyć w /run/lock i po restarcie powinien zniknąć a w /var/lock jest symlink, coś masz zepsute, przy poprawnym wyjściu z aplikacji powinieneś tylko to złapać i zamknąć port.
daj wyniki poleceń

[s_theCapt]

@l1ght: ale ja nie będę poprawnie wychodził z tej aplikacji, to jest problem (a raczej nie mogę tego zagwarantować, bo nie ja będę tego używał)

drwxrwxrwt 3 root root 100 cze 18 13:36 /run/lock

[l1ght]

@s_theCapt: źle Ci napisałem

ls -al /var/lock
i
ls -al /run/lock
i ps -aux

zrób to jak odpalisz appke i jak zrestartujesz system i najlepiej wrzuć na pastebina czy cuś

[s_theCapt]

@l1ght:

[l1ght]

@s_theCapt: właścicielem pliku jest user który tworzy ten plik. Rozumiem że ty ten plik tworzysz w aplikacji a nie sam system to robi tak? Jeśli tak, to wypadało by po sobie posprzątać. Dziwi mnie fakt że po restarcie systemu pliki są nadal trzymane w /run/lock

[s_theCapt]

@l1ght: sądziłem, że robi to system, ale wychodzi na to, że robi to Qt, a więc pośrednio ja. A więc po prostu go usunę przed próbą łączenia i tyle, dzięki. :P

[l1ght]

go usunę przed próbą łączenia i tyle

@s_theCapt: co jeśli plik będzie prawidłowo utworzony i port rzeczywiście będzie zablokowany?
To niezłe działanie u klienta xD

[s_theCapt]

@l1ght: no ale go tworzy tylko moja aplikacja, tak? no po autostarcie po reboocie, mam pewność że to nie jest potrzebny plik. a ten raspberry służy tylko do odpalania tej jednej appki.

[l1ght]

@s_theCapt: rób jak uważasz, to Twoje pieniądze i Twój klient.

[s_theCapt]

@l1ght: ale nie no, pytam o radę, fajnie by było to zrobić inaczej, ale jeżeli zakładam, że ten raspberry może być nawet z prądu ot tak wyłączony i wtedy ma przestań działać? ;c

[l1ght]

być nawet z prądu ot tak wyłączony

@s_theCapt: dlatego uważam, że ten plik jest tworzony/przechowywany w dziwny sposób, cały /run to tmpfs i jest trzymany w ramie/swapie, po restarcie powinno być pusto.
https://www.networkworld.com/article/3403023/exploring-run-on-linux.html

[s_theCapt]

@l1ght: no ale on jest tworzony automatycznie przez biliotekę której używam, nie zmienię tego... a nie będzie automatycznie usuwany, bo niestety ta appka nie będzie zamykana poprawnie często na 100%. I też uważam, że po resecie powinno znikać, ale jak widzisz... nie dzieje się tak. ;c