Cześć!
Dodałem w najnowszej wersji konfigurację automatycznego czyszczenia kontaktów, w sekcji Contact Management, po rozwinięciu Advanced Filter:
Automatycznie usuwane będą kontakty spełniające zdefiniowane tam kryteria (typ, data ostatniego adverta).
Kontakty oznaczone w Existing Contacts jako "Chronione" (Protected) - nie zostaną usunięte.
Proszę o sprawdzenie, czy wszystko działa. W trakcie moich testów zauważyłem, że niektóre kontakty nie są usuwane z powodu jakiejś nietypowej struktury nazwy. Będę to jeszcze sprawdzał, aby zbadać co jest przyczyną.
Cześć!
Dodałem w najnowszej wersji konfigurację automatycznego czyszczenia kontaktów, w sekcji Contact Management, po rozwinięciu Advanced Filter:
<img alt="Image" src="https://github.com/user-attachments/assets/45acf822-9819-4d52-9e78-2c55224316f2" />
Automatycznie usuwane będą kontakty spełniające zdefiniowane tam kryteria (typ, data ostatniego adverta).
Kontakty oznaczone w Existing Contacts jako "Chronione" (Protected) - nie zostaną usunięte.
<img width="524" height="885" alt="Image" src="https://github.com/user-attachments/assets/9fee9b7e-1828-4bff-99d3-727e84a87d0c" />
Proszę o sprawdzenie, czy wszystko działa. W trakcie moich testów zauważyłem, że niektóre kontakty nie są usuwane z powodu jakiejś nietypowej struktury nazwy. Będę to jeszcze sprawdzał, aby zbadać co jest przyczyną.
<!-- github-comment-id:3797140699 -->
cos jest nie tak. Ustawilem godzine czyszczenia. Juz 3 razy sprawdzilem. Za kazdym razem po godzinie czyszczenia wiesza się docker meshcore-bridge. Musze go restartowac. Jeszcze bede obserwowac.
cos jest nie tak. Ustawilem godzine czyszczenia. Juz 3 razy sprawdzilem. Za kazdym razem po godzinie czyszczenia wiesza się docker meshcore-bridge. Musze go restartowac. Jeszcze bede obserwowac.
<!-- github-comment-id:3806232227 -->
To może nie jest wieszanie. Operacja usuwania jest bardzo wymagająca dla urządzenia i potrafi to dość długo czasu zajmować (kontakty są usuwane pojedynczo), podczas którego urządzenie dostaje poważnej zadyszki, co może wyglądać jak zawieszenie. Spróbuj dać na początek mniej restrykcyjne warunki, np. advert > 7 dni, albo nawet 14. Jak to przejdzie - zmniejsz czas.
To może nie jest wieszanie. Operacja usuwania jest bardzo wymagająca dla urządzenia i potrafi to dość długo czasu zajmować (kontakty są usuwane pojedynczo), podczas którego urządzenie dostaje poważnej zadyszki, co może wyglądać jak zawieszenie. Spróbuj dać na początek mniej restrykcyjne warunki, np. advert > 7 dni, albo nawet 14. Jak to przejdzie - zmniejsz czas.
<!-- github-comment-id:3806288450 -->
widze ze to trwa jak robie to recznie. Ustawie logowanie dockera i zobacze co sie dzieje w momencie czyszczenia. Ale ja tu pisze o niedostepnosci 2h
widze ze to trwa jak robie to recznie. Ustawie logowanie dockera i zobacze co sie dzieje w momencie czyszczenia. Ale ja tu pisze o niedostepnosci 2h
<!-- github-comment-id:3806436904 -->
Naprawdę dziwne, bo u mnie chodzi to na dwóch niezależnych urządzeniach (V3 i V4), i automatyczne czyszczenie przebiega bez problemów.
mc-webui | 2026-01-28 01:00:00,000 - app.archiver.manager - INFO - Running daily cleanup job...
mc-webui | 2026-01-28 01:00:00,001 - app.archiver.manager - INFO - Fetching contacts from device...
mc-webui | 2026-01-28 01:00:02,431 - app.archiver.manager - INFO - get_contacts_with_last_seen returned: success=True, contacts_count=201, error=
mc-webui | 2026-01-28 01:00:02,432 - app.archiver.manager - INFO - Converted 201 contacts to list format
mc-webui | 2026-01-28 01:00:02,432 - app.archiver.manager - INFO - Filter criteria: types=[1, 2, 3, 4], date_field=last_advert, days=7, name_filter=''
mc-webui | 2026-01-28 01:00:02,432 - app.archiver.manager - INFO - Found 36 contacts to clean up
Ręczne usuwanie korzysta z tej samej procedury co automatyczne.
Co pokazuje Twój log?
cd ~/mc-webui && docker compose logs -f | grep "app.archiver.manager"
Naprawdę dziwne, bo u mnie chodzi to na dwóch niezależnych urządzeniach (V3 i V4), i automatyczne czyszczenie przebiega bez problemów.
```
mc-webui | 2026-01-28 01:00:00,000 - app.archiver.manager - INFO - Running daily cleanup job...
mc-webui | 2026-01-28 01:00:00,001 - app.archiver.manager - INFO - Fetching contacts from device...
mc-webui | 2026-01-28 01:00:02,431 - app.archiver.manager - INFO - get_contacts_with_last_seen returned: success=True, contacts_count=201, error=
mc-webui | 2026-01-28 01:00:02,432 - app.archiver.manager - INFO - Converted 201 contacts to list format
mc-webui | 2026-01-28 01:00:02,432 - app.archiver.manager - INFO - Filter criteria: types=[1, 2, 3, 4], date_field=last_advert, days=7, name_filter=''
mc-webui | 2026-01-28 01:00:02,432 - app.archiver.manager - INFO - Found 36 contacts to clean up
```
Ręczne usuwanie korzysta z tej samej procedury co automatyczne.
Co pokazuje Twój log?
```
cd ~/mc-webui && docker compose logs -f | grep "app.archiver.manager"
```
<!-- github-comment-id:3809313287 -->
Dziś miałem totalny zwis Helteca, co się zresztą zdarza mi raz na kilka, kilkanaście dni. Na razie nie zdiagnozowałem z czym to jest związane, ale urządzenie w którymś momencie całkowicie przestaje odpowiadać na jakiekolwiek polecenia i pomaga wyłącznie odłączenie od zasilania i ponowne połączenie. Spróbuj może na twardo zrestartować swoje urządzenie i sprawdź, czy to coś pomaga.
Dziś miałem totalny zwis Helteca, co się zresztą zdarza mi raz na kilka, kilkanaście dni. Na razie nie zdiagnozowałem z czym to jest związane, ale urządzenie w którymś momencie całkowicie przestaje odpowiadać na jakiekolwiek polecenia i pomaga wyłącznie odłączenie od zasilania i ponowne połączenie. Spróbuj może na twardo zrestartować swoje urządzenie i sprawdź, czy to coś pomaga.
<!-- github-comment-id:3816067709 -->
To wygląda na jakiś problem z timeoutem. Ewidentnie przywiesza się na usuwaniu dużej liczby konkretnych kontaktów. Raz mi się zdarzył taki błąd, ale tylko na jednym kontakcie, więc nie wywalił całej maszyny. Będę to badał i dam znać.
Na razie sugeruję wyłączyć to automatyczne usuwanie i włączyć ręczną akceptację kontaktów, żeby nie zapchać urządzenia.
Pozdrawiam!
To jest bardzo cenna informacja! Dzięki!
To wygląda na jakiś problem z timeoutem. Ewidentnie przywiesza się na usuwaniu dużej liczby konkretnych kontaktów. Raz mi się zdarzył taki błąd, ale tylko na jednym kontakcie, więc nie wywalił całej maszyny. Będę to badał i dam znać.
Na razie sugeruję wyłączyć to automatyczne usuwanie i włączyć ręczną akceptację kontaktów, żeby nie zapchać urządzenia.
Pozdrawiam!
<!-- github-comment-id:3818711663 -->
Nie wiem jeszcze, czy to ma znaczenie, ale może warto spróbować.
Ja swoim maszynom testowym przydzieliłem 2CPU:
<img width="358" height="252" alt="Image" src="https://github.com/user-attachments/assets/92e76026-4f8b-44bb-b753-0e3ed2188112" />
Nie wiem jeszcze, czy to ma znaczenie, ale może warto spróbować.
<!-- github-comment-id:3822234160 -->
Chyba udało mi się zidentyfikować przyczynę problemu.
Co się dzieje?
Cleanup job wysyłał żądania usunięcia kontaktów jedno po drugim, bez żadnej przerwy. Na szybszym sprzęcie (2+ CPU) bridge nadąża, ale na wolniejszym (1 CPU) nie jest w stanie obsłużyć takiego "zalewu" żądań i zaczyna je odrzucać - stąd błędy "Broken pipe".
Co zmieniłem?
Throttling - dodałem 0.5s opóźnienia między usuwaniem kolejnych kontaktów
Retry logic - jeśli usunięcie się nie uda (szczególnie przy Broken pipe), system ponowi próbę do 2 razy z dłuższą przerwą
Efekt uboczny: dla 100 kontaktów cleanup potrwa teraz ~50-60 sekund zamiast kilku sekund, ale powinien działać stabilnie niezależnie od mocy sprzętu.
Jak przetestować?
Poprawka jest na gałęzi dev. Możesz ją przetestować:
cd ~/mc-webui
git fetch
git checkout dev
git pull
python3 -m app.version freeze
docker compose up -d --build
Ustaw auto-cleanup na najbliższą pełną godzinę i sprawdź logi:
Cześć!
Chyba udało mi się zidentyfikować przyczynę problemu.
## Co się dzieje?
Cleanup job wysyłał żądania usunięcia kontaktów jedno po drugim, bez żadnej przerwy. Na szybszym sprzęcie (2+ CPU) bridge nadąża, ale na wolniejszym (1 CPU) nie jest w stanie obsłużyć takiego "zalewu" żądań i zaczyna je odrzucać - stąd błędy "Broken pipe".
## Co zmieniłem?
1. **Throttling** - dodałem 0.5s opóźnienia między usuwaniem kolejnych kontaktów
2. **Retry logic** - jeśli usunięcie się nie uda (szczególnie przy Broken pipe), system ponowi próbę do 2 razy z dłuższą przerwą
Efekt uboczny: dla 100 kontaktów cleanup potrwa teraz ~50-60 sekund zamiast kilku sekund, ale powinien działać stabilnie niezależnie od mocy sprzętu.
## Jak przetestować?
Poprawka jest na gałęzi `dev`. Możesz ją przetestować:
```bash
cd ~/mc-webui
git fetch
git checkout dev
git pull
python3 -m app.version freeze
docker compose up -d --build
```
Ustaw auto-cleanup na najbliższą pełną godzinę i sprawdź logi:
```bash
docker compose logs -f | grep "app.archiver.manager"
```
Daj znać czy pomogło!
<!-- github-comment-id:3822283073 -->
Ja na Heltecu V3 mam ustawione aby czyścił starsze niż 7 dni, więc nie znajduje ich dużo:
Teraz ustawiłem bardziej restrykcyjnie - na starsze niż 1 dzień. Zobaczymy o 12. Muszę to jakoś powtórzyć u siebie, aby to zdiagnozować bezpośrednio.
Ja na Heltecu V3 mam ustawione aby czyścił starsze niż 7 dni, więc nie znajduje ich dużo:
<img width="1636" height="164" alt="Image" src="https://github.com/user-attachments/assets/a5bf9869-c52a-432b-af0c-ca4ff0048532" />
Teraz ustawiłem bardziej restrykcyjnie - na starsze niż 1 dzień. Zobaczymy o 12. Muszę to jakoś powtórzyć u siebie, aby to zdiagnozować bezpośrednio.
<!-- github-comment-id:3822915899 -->
Zostawię go na dłuższy czas, żeby się zebrało >300 kontaktów, bo przy tej liczbie działa bez problemu.
Ciągle nic :(
<img width="1667" height="172" alt="Image" src="https://github.com/user-attachments/assets/e7c2730a-d64e-48b4-8266-95ea776b6582" />
Zostawię go na dłuższy czas, żeby się zebrało >300 kontaktów, bo przy tej liczbie działa bez problemu.
<!-- github-comment-id:3823174050 -->
Jeszcze jedno mi przyszło do głowy, ponieważ jak pisałeś - ręczne usuwanie działa poprawnie.
Różnica między ręcznym a automatycznym cleanup:
Ręczny → działa w kontekście Flask (główny wątek)
Automatyczny → działa w wątku APScheduler (BackgroundScheduler)
Problem najprawdopodobniej leży w tym, jak biblioteka requests zarządza połączeniami HTTP w kontekście wątku schedulera. Domyślnie requests używa connection pooling (keep-alive), co może powodować "stale connections" w tle.
Dodałem nagłówek Connection: close do wszystkich żądań do bridge - to wymusza zamykanie połączenia po każdym żądaniu zamiast trzymania go w puli. Może to rozwiąże problem z "martwymi" połączeniami w kontekście schedulera.
Zaktualizuj proszę do najnowszej wersji i sprawdź jeszcze raz.
Jeszcze jedno mi przyszło do głowy, ponieważ jak pisałeś - ręczne usuwanie działa poprawnie.
Różnica między ręcznym a automatycznym cleanup:
- **Ręczny** → działa w kontekście Flask (główny wątek)
- **Automatyczny** → działa w wątku APScheduler (BackgroundScheduler)
Problem najprawdopodobniej leży w tym, jak biblioteka `requests` zarządza połączeniami HTTP w kontekście wątku schedulera. Domyślnie `requests` używa connection pooling (keep-alive), co może powodować "stale connections" w tle.
Dodałem nagłówek `Connection: close` do wszystkich żądań do bridge - to wymusza zamykanie połączenia po każdym żądaniu zamiast trzymania go w puli. Może to rozwiąże problem z "martwymi" połączeniami w kontekście schedulera.
Zaktualizuj proszę do najnowszej wersji i sprawdź jeszcze raz.
<!-- github-comment-id:3823243635 -->
Ja to robiłem etapami - najpierw wpisałem 30 dni, potem 7 a na końcu 2, żeby nie było dużo do usuwania na raz. Widocznie dlatego mi działało.
Spróbuję w kodzie zaszyć logikę, aby harmonogram nie usuwał więcej niż 30-40 kontaktów na raz.
Ręcznie czy w harmonogramie?
Ja to robiłem etapami - najpierw wpisałem 30 dni, potem 7 a na końcu 2, żeby nie było dużo do usuwania na raz. Widocznie dlatego mi działało.
Spróbuję w kodzie zaszyć logikę, aby harmonogram nie usuwał więcej niż 30-40 kontaktów na raz.
<!-- github-comment-id:3828128374 -->
Przygotuję usługę, która będzie działać na hoście, która będzie monitorować działanie kontenerów, a w razie problemów, będzie logować informacje diagnostyczne i próbować automatycznie restartować kontener. Dam znać, jak będzie gotowe.
Mnie ciągle nie udaje się doprowadzić do zawieszenia kontenera. Niezależnie od powyższego, będę próbował uruchomić usuwanie ok. 100 kontaktów na Heltecu V3.
Przepraszam za te kłopoty i dziękuję za cierpliwość i informacje zwrotne. Walczymy dalej :)
Przygotuję usługę, która będzie działać na hoście, która będzie monitorować działanie kontenerów, a w razie problemów, będzie logować informacje diagnostyczne i próbować automatycznie restartować kontener. Dam znać, jak będzie gotowe.
Mnie ciągle nie udaje się doprowadzić do zawieszenia kontenera. Niezależnie od powyższego, będę próbował uruchomić usuwanie ok. 100 kontaktów na Heltecu V3.
Przepraszam za te kłopoty i dziękuję za cierpliwość i informacje zwrotne. Walczymy dalej :)
<!-- github-comment-id:3828390980 -->
Jeśli nawet kontener się zawiesi - usługa go sama zrestartuje, a ponadto zapisze informacje diagnostyczne do późniejszej analizy.
Zasymulowałem tam niedostępność kontenera i status unhealthy:
Zainstaluj sobie tego watchdoga, do monitorowania statusu kontenera. Instrukcję instalacji i diagnozowania masz tutaj:
https://github.com/MarekWo/mc-webui/blob/dev/docs/watchdog.md
Jeśli nawet kontener się zawiesi - usługa go sama zrestartuje, a ponadto zapisze informacje diagnostyczne do późniejszej analizy.
Zasymulowałem tam niedostępność kontenera i status unhealthy:
<img width="1723" height="493" alt="Image" src="https://github.com/user-attachments/assets/19ee86c6-3ef1-44ac-b772-66368f70dc11" />
<!-- github-comment-id:3828449693 -->
wyczyscilem campaniona z poziomu flasher- meshcore. Restart dockerow i mam teraz tylko 6 kontaktow. Zobaczymy czy problem pojawi sie o 00:00. Bede czyscil >3 dni. Moze cos bylo ... na campanion.
wyczyscilem campaniona z poziomu flasher- meshcore. Restart dockerow i mam teraz tylko 6 kontaktow. Zobaczymy czy problem pojawi sie o 00:00. Bede czyscil >3 dni. Moze cos bylo ... na campanion.
<!-- github-comment-id:3828650686 -->
Grubo.... ale może faktycznie to był jedyny sposób :(
Ja teraz uzbierałem ponad 100 kontaktów do usunięcia na V3 - i poszło bez zgrzytów w 3 minuty.
To musiało być coś bardzo specyficznego na tym konkretnym urządzeniu, może jakiś uszkodzony rekord kontaktu... ciężko stwierdzić.
Grubo.... ale może faktycznie to był jedyny sposób :(
Ja teraz uzbierałem ponad 100 kontaktów do usunięcia na V3 - i poszło bez zgrzytów w 3 minuty.
<img width="1319" height="126" alt="Image" src="https://github.com/user-attachments/assets/2d2df457-f324-4db9-a9c0-240bbc04f187" />
To musiało być coś bardzo specyficznego na tym konkretnym urządzeniu, może jakiś uszkodzony rekord kontaktu... ciężko stwierdzić.
<!-- github-comment-id:3828713492 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Przydała by się opcja czyszczenia automatycznie codziennie o np. 00:01 wszystkich kontaktów bez advert >2d
Dobry pomysł. Najlepiej z możliwością wyboru typów kontaktów, które mają być automatycznie czyszczone.
Cześć!

Dodałem w najnowszej wersji konfigurację automatycznego czyszczenia kontaktów, w sekcji Contact Management, po rozwinięciu Advanced Filter:
Automatycznie usuwane będą kontakty spełniające zdefiniowane tam kryteria (typ, data ostatniego adverta).
Kontakty oznaczone w Existing Contacts jako "Chronione" (Protected) - nie zostaną usunięte.
Proszę o sprawdzenie, czy wszystko działa. W trakcie moich testów zauważyłem, że niektóre kontakty nie są usuwane z powodu jakiejś nietypowej struktury nazwy. Będę to jeszcze sprawdzał, aby zbadać co jest przyczyną.
juz aktualizuje i wlacze auto czyszczenie
Daj znać, czy działa jak trzeba i czy możemy zamknąć ten ticket.
Rano sprawdzę czy wyczyścił
Możesz sprawdzić w logach takim poleceniem na serwerze:
Powinieneś tam zobaczyć liczbę usuniętych rekordów kontaktów.
cos jest nie tak. Ustawilem godzine czyszczenia. Juz 3 razy sprawdzilem. Za kazdym razem po godzinie czyszczenia wiesza się docker meshcore-bridge. Musze go restartowac. Jeszcze bede obserwowac.
ustawie na 18 czyszczenie i wlacze logowanie do pliku
To może nie jest wieszanie. Operacja usuwania jest bardzo wymagająca dla urządzenia i potrafi to dość długo czasu zajmować (kontakty są usuwane pojedynczo), podczas którego urządzenie dostaje poważnej zadyszki, co może wyglądać jak zawieszenie. Spróbuj dać na początek mniej restrykcyjne warunki, np. advert > 7 dni, albo nawet 14. Jak to przejdzie - zmniejsz czas.
widze ze to trwa jak robie to recznie. Ustawie logowanie dockera i zobacze co sie dzieje w momencie czyszczenia. Ale ja tu pisze o niedostepnosci 2h
Reczne czyszczenie dziala i nie zaweisza dockera. Automatyczna zawsze knczy sie koniecznoscia restartu docker-a
Naprawdę dziwne, bo u mnie chodzi to na dwóch niezależnych urządzeniach (V3 i V4), i automatyczne czyszczenie przebiega bez problemów.
Ręczne usuwanie korzysta z tej samej procedury co automatyczne.
Co pokazuje Twój log?
Dziś miałem totalny zwis Helteca, co się zresztą zdarza mi raz na kilka, kilkanaście dni. Na razie nie zdiagnozowałem z czym to jest związane, ale urządzenie w którymś momencie całkowicie przestaje odpowiadać na jakiekolwiek polecenia i pomaga wyłącznie odłączenie od zasilania i ponowne połączenie. Spróbuj może na twardo zrestartować swoje urządzenie i sprawdź, czy to coś pomaga.
Taki blad. o 14 wyzwolone czyszczenie
mc-webui | 2026-01-29 14:00:05,088 - app.archiver.manager - WARNING - Failed to delete contact WWL_01_ZIELONKA_rpt: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,098 - app.archiver.manager - WARNING - Failed to delete contact OtwockSoplicowo-V4-RPT*: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,107 - app.archiver.manager - WARNING - Failed to delete contact Blonie1-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,117 - app.archiver.manager - WARNING - Failed to delete contact Siekierki-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,127 - app.archiver.manager - WARNING - Failed to delete contact TEST WEW: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,137 - app.archiver.manager - WARNING - Failed to delete contact Goclaw 01 RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,147 - app.archiver.manager - WARNING - Failed to delete contact DABROWKA-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,156 - app.archiver.manager - WARNING - Failed to delete contact Celestynów-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,166 - app.archiver.manager - WARNING - Failed to delete contact NOWOLIPKI-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,176 - app.archiver.manager - WARNING - Failed to delete contact TEST 1*: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,186 - app.archiver.manager - WARNING - Failed to delete contact TEST_WAW_STAROWKA: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,196 - app.archiver.manager - WARNING - Failed to delete contact Gnatowice 3 Test : [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,206 - app.archiver.manager - WARNING - Failed to delete contact Wy_Rpt: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,216 - app.archiver.manager - WARNING - Failed to delete contact Bialuty-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,225 - app.archiver.manager - WARNING - Failed to delete contact 🔋BSX75PL-Kobyłka-V3: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,235 - app.archiver.manager - WARNING - Failed to delete contact ANTONINOW-N-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,245 - app.archiver.manager - WARNING - Failed to delete contact 04-687-RPT-TESTING*: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,255 - app.archiver.manager - WARNING - Failed to delete contact siennicka Xiao: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,265 - app.archiver.manager - WARNING - Failed to delete contact 🌞BSX75PL-Ząbki-RPT*: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,274 - app.archiver.manager - WARNING - Failed to delete contact WWL-Marki1-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,284 - app.archiver.manager - WARNING - Failed to delete contact Otwock Test Mini-RPT: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,294 - app.archiver.manager - WARNING - Failed to delete contact Zales RPT TEST: [Errno 32] Broken pipe
mc-webui | 2026-01-29 14:00:05,304 - app.archiver.manager - WARNING - Failed to delete contact CHYLICE-RPT: [Errno 32] Broken pipe
I tylko docker compose restart meshcore-bridge pomaga
To jest bardzo cenna informacja! Dzięki!
To wygląda na jakiś problem z timeoutem. Ewidentnie przywiesza się na usuwaniu dużej liczby konkretnych kontaktów. Raz mi się zdarzył taki błąd, ale tylko na jednym kontakcie, więc nie wywalił całej maszyny. Będę to badał i dam znać.
Na razie sugeruję wyłączyć to automatyczne usuwanie i włączyć ręczną akceptację kontaktów, żeby nie zapchać urządzenia.
Pozdrawiam!
Podaj mi jeszcze jakie masz parametry hosta - pamięć / cpu.
heltec v3
Ja swoim maszynom testowym przydzieliłem 2CPU:
Nie wiem jeszcze, czy to ma znaczenie, ale może warto spróbować.
Cześć!
Chyba udało mi się zidentyfikować przyczynę problemu.
Co się dzieje?
Cleanup job wysyłał żądania usunięcia kontaktów jedno po drugim, bez żadnej przerwy. Na szybszym sprzęcie (2+ CPU) bridge nadąża, ale na wolniejszym (1 CPU) nie jest w stanie obsłużyć takiego "zalewu" żądań i zaczyna je odrzucać - stąd błędy "Broken pipe".
Co zmieniłem?
Efekt uboczny: dla 100 kontaktów cleanup potrwa teraz ~50-60 sekund zamiast kilku sekund, ale powinien działać stabilnie niezależnie od mocy sprzętu.
Jak przetestować?
Poprawka jest na gałęzi
dev. Możesz ją przetestować:Ustaw auto-cleanup na najbliższą pełną godzinę i sprawdź logi:
Daj znać czy pomogło!
test o 10. Dodanie CPU nic nie zmienilo.
Ja na Heltecu V3 mam ustawione aby czyścił starsze niż 7 dni, więc nie znajduje ich dużo:

Teraz ustawiłem bardziej restrykcyjnie - na starsze niż 1 dzień. Zobaczymy o 12. Muszę to jakoś powtórzyć u siebie, aby to zdiagnozować bezpośrednio.
Ciągle nic :(
Zostawię go na dłuższy czas, żeby się zebrało >300 kontaktów, bo przy tej liczbie działa bez problemu.
Jeszcze jedno mi przyszło do głowy, ponieważ jak pisałeś - ręczne usuwanie działa poprawnie.
Różnica między ręcznym a automatycznym cleanup:
Problem najprawdopodobniej leży w tym, jak biblioteka
requestszarządza połączeniami HTTP w kontekście wątku schedulera. Domyślnierequestsużywa connection pooling (keep-alive), co może powodować "stale connections" w tle.Dodałem nagłówek
Connection: closedo wszystkich żądań do bridge - to wymusza zamykanie połączenia po każdym żądaniu zamiast trzymania go w puli. Może to rozwiąże problem z "martwymi" połączeniami w kontekście schedulera.Zaktualizuj proszę do najnowszej wersji i sprawdź jeszcze raz.
Przy recznym kasowaniu 140 kontaktow oba dockery padly.
Przy kasowaniu 40 kontaktow app nie zawiesila sie.
Ręcznie czy w harmonogramie?
Ja to robiłem etapami - najpierw wpisałem 30 dni, potem 7 a na końcu 2, żeby nie było dużo do usuwania na raz. Widocznie dlatego mi działało.
Spróbuję w kodzie zaszyć logikę, aby harmonogram nie usuwał więcej niż 30-40 kontaktów na raz.
recznie robiłem. Teraz ustawię automat na 13 z kasowaniem podobnego wolumenu danych.
dziwne zachowanie bridge
zawisł mimo ze plan byl na czyszczenie na 13
Harmonogram sam się wyłączył?
Ja wyłączyłem
Przygotuję usługę, która będzie działać na hoście, która będzie monitorować działanie kontenerów, a w razie problemów, będzie logować informacje diagnostyczne i próbować automatycznie restartować kontener. Dam znać, jak będzie gotowe.
Mnie ciągle nie udaje się doprowadzić do zawieszenia kontenera. Niezależnie od powyższego, będę próbował uruchomić usuwanie ok. 100 kontaktów na Heltecu V3.
Przepraszam za te kłopoty i dziękuję za cierpliwość i informacje zwrotne. Walczymy dalej :)
Zainstaluj sobie tego watchdoga, do monitorowania statusu kontenera. Instrukcję instalacji i diagnozowania masz tutaj:
https://github.com/MarekWo/mc-webui/blob/dev/docs/watchdog.md
Jeśli nawet kontener się zawiesi - usługa go sama zrestartuje, a ponadto zapisze informacje diagnostyczne do późniejszej analizy.
Zasymulowałem tam niedostępność kontenera i status unhealthy:
Wrzucone i obserwujemy.
Przy okazji moje srodowisko:
pierwszy restart przy recznym czyszczeniu
mc-webui | 2026-01-31 15:26:36,174 - app.meshcore.parser - INFO - Loaded 0 DM messages
mc-webui | 2026-01-31 15:26:36,174 - app.meshcore.parser - INFO - Found 0 DM conversations
mc-webui | 2026-01-31 15:26:36,175 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:36] "GET /api/dm/conversations?days=7 HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:36,190 - app.meshcore.cli - INFO - Executing via bridge: contacts
mc-webui | 2026-01-31 15:26:37,815 - app.meshcore.cli - ERROR - Bridge request timeout after 12s
mc-webui | 2026-01-31 15:26:37,815 - app.meshcore.cli - WARNING - apply_to t=3 contact_info failed: Bridge timeout after 12 seconds
mc-webui | 2026-01-31 15:26:37,815 - app.meshcore.cli - INFO - Executing via bridge: apply_to t=4 contact_info
mc-webui | 2026-01-31 15:26:41,144 - app.meshcore.cli - ERROR - Bridge request timeout after 5s
mc-webui | 2026-01-31 15:26:41,148 - app.meshcore.cli - ERROR - Bridge request timeout after 12s
mc-webui | 2026-01-31 15:26:41,148 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:41] "GET /api/contacts HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:41,155 - app.meshcore.parser - INFO - Loaded 1031 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:41,165 - app.meshcore.parser - INFO - Loaded 1 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:41,165 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:41] "GET /api/status HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:41,171 - app.meshcore.parser - INFO - Loaded 0 DM messages
mc-webui | 2026-01-31 15:26:41,171 - app.meshcore.parser - INFO - Found 0 DM conversations
mc-webui | 2026-01-31 15:26:41,171 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:41] "GET /api/dm/updates?last_seen={} HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:41,177 - app.meshcore.cli - INFO - Executing via bridge: infos
mc-webui | 2026-01-31 15:26:44,979 - app.meshcore.cli - ERROR - Bridge request timeout after 12s
mc-webui | 2026-01-31 15:26:44,979 - app.meshcore.cli - WARNING - apply_to t=3 contact_info failed: Bridge timeout after 12 seconds
mc-webui | 2026-01-31 15:26:44,979 - app.meshcore.cli - INFO - Executing via bridge: apply_to t=4 contact_info
mc-webui | 2026-01-31 15:26:46,186 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:46] "GET /api/contacts/pending?types=1 HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:46,204 - app.meshcore.parser - INFO - Loaded 0 DM messages
mc-webui | 2026-01-31 15:26:46,204 - app.meshcore.parser - INFO - Found 0 DM conversations
mc-webui | 2026-01-31 15:26:46,204 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:46] "GET /api/dm/conversations?days=7 HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:46,218 - app.meshcore.cli - INFO - Executing via bridge: contacts
mc-webui | 2026-01-31 15:26:51,188 - app.meshcore.cli - ERROR - Bridge request timeout after 5s
mc-webui | 2026-01-31 15:26:51,196 - app.meshcore.parser - INFO - Loaded 1031 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,204 - app.meshcore.parser - INFO - Loaded 1 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,205 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/status HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:51,224 - app.meshcore.parser - INFO - Loaded 0 DM messages
mc-webui | 2026-01-31 15:26:51,224 - app.meshcore.parser - INFO - Found 0 DM conversations
mc-webui | 2026-01-31 15:26:51,225 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/dm/updates?last_seen={} HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:51,497 - app.meshcore.cli - ERROR - Cannot connect to meshcore-bridge: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))
mc-webui | 2026-01-31 15:26:51,497 - app.meshcore.cli - WARNING - apply_to t=4 contact_info failed: Cannot connect to meshcore-bridge service
mc-webui | 2026-01-31 15:26:51,498 - app.meshcore.cli - ERROR - No contacts parsed from any type
mc-webui | 2026-01-31 15:26:51,498 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/contacts/detailed HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:51,498 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/contacts/pending?types=1 HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:51,499 - app.meshcore.cli - ERROR - Cannot connect to meshcore-bridge: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))
mc-webui | 2026-01-31 15:26:51,499 - app.meshcore.cli - WARNING - apply_to t=4 contact_info failed: Cannot connect to meshcore-bridge service
mc-webui | 2026-01-31 15:26:51,499 - app.meshcore.cli - ERROR - No contacts parsed from any type
mc-webui | 2026-01-31 15:26:51,499 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/contacts/detailed HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:51,499 - app.meshcore.cli - ERROR - Cannot connect to meshcore-bridge: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))
mc-webui | 2026-01-31 15:26:51,500 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/contacts HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:51,503 - app.meshcore.cli - ERROR - Cannot connect to meshcore-bridge: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))
mc-webui | 2026-01-31 15:26:51,503 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/contacts HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:51,504 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/contacts/pending?types=1 HTTP/1.1" 500 -
mc-webui | 2026-01-31 15:26:51,534 - app.meshcore.parser - INFO - Filtered 8 messages from last 7 days (out of 200 total)
mc-webui | 2026-01-31 15:26:51,536 - app.meshcore.parser - INFO - Loaded 8 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,536 - app.meshcore.cli - INFO - Executing via bridge: infos
mc-webui | 2026-01-31 15:26:51,539 - app.meshcore.cli - INFO - Executing via bridge: infos
mc-webui | 2026-01-31 15:26:51,540 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/messages?limit=500&channel_idx=2&days=7 HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:51,540 - app.meshcore.cli - ERROR - Cannot connect to meshcore-bridge: HTTPConnectionPool(host='meshcore-bridge', port=5001): Max retries exceeded with url: /cli (Caused by NewConnectionError("HTTPConnection(host='meshcore-bridge', port=5001): Failed to establish a new connection: [Errno 111] Connection refused"))
mc-webui | 2026-01-31 15:26:51,544 - app.meshcore.cli - ERROR - Cannot connect to meshcore-bridge: HTTPConnectionPool(host='meshcore-bridge', port=5001): Max retries exceeded with url: /cli (Caused by NewConnectionError("HTTPConnection(host='meshcore-bridge', port=5001): Failed to establish a new connection: [Errno 111] Connection refused"))
mc-webui | 2026-01-31 15:26:51,559 - app.meshcore.parser - INFO - Loaded 1031 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,561 - app.meshcore.parser - INFO - Loaded 1031 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,583 - app.meshcore.parser - INFO - Loaded 1 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,583 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/status HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:51,589 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "POST /api/read_status/mark_read HTTP/1.1" 200 -
mc-webui | 2026-01-31 15:26:51,593 - app.meshcore.parser - INFO - Loaded 1 messages from /root/.config/meshcore/Bober_prox.msgs
mc-webui | 2026-01-31 15:26:51,594 - werkzeug - INFO - 192.168.1.245 - - [31/Jan/2026 15:26:51] "GET /api/status HTTP/1.1" 200 -root@grafana:~/mc-webui#
wyczyscilem campaniona z poziomu flasher- meshcore. Restart dockerow i mam teraz tylko 6 kontaktow. Zobaczymy czy problem pojawi sie o 00:00. Bede czyscil >3 dni. Moze cos bylo ... na campanion.
Grubo.... ale może faktycznie to był jedyny sposób :(
Ja teraz uzbierałem ponad 100 kontaktów do usunięcia na V3 - i poszło bez zgrzytów w 3 minuty.

To musiało być coś bardzo specyficznego na tym konkretnym urządzeniu, może jakiś uszkodzony rekord kontaktu... ciężko stwierdzić.
od 3 dni czyszczenie bez problemu.
wracam do branch main.
Super! Bardzo dziękuję za aktualizację. W takim razie pozwól, że zamknę wątek.
zamykaj