RPi Ubuntu zapewnić gracefully shutdown

[Behlur_Olderys]

Czasami wyłączam zasilanie od rpi "na chama" czyli z kontaktu Ale ostatnio spowodowało to corrupted FS. Nie mogłem wystartować serwera zdalnie, musiałem zrobić manualnie fsck. 

Czy da się temu jakoś zapobiec? Jest jakieś gotowe rozwiązanie które stosujecie? Chciałbym kiedyś mieć system postawiony naprawdę zdalnie i nie tracić kilku dni na przyjazd i zabawę manualną. Ktoś ma jakiś pomysł? 

UPS z wykrywaniem utraty zasilania, albo może redundancja sprzętowa, jakiś nadzorca, może jakiś dodatkowy moduł z bateryjką? Jak to ugryźć?

[Pikolaczek]

UPS z interface do systemu operacyjnego sprawdza się dobrze praktycznie zawsze.

(przy prawidłowej konfiguracji )

Ubuntu zwykle radzi sobie z wyłączeniem zasilania bez shutdown, ale jak zauważyłeś nie zawsze.

Na ten moment nie mam niestety innego pomysłu…

 

W

[lkosz]

Czemu nie wyłączasz zdalnie raspberry po ssh?

 

Metod na automatyczny graceful shutdown jest kilka. Najprostsza to niewielki powerbank USB (który nie ma wahnięć napięcia przy połączaniu/odłączaniu zasilania). Przez dzielnik napięcia podłączasz plus zasilania samego powerbanka do nóżki raspberry. Do tego prosty skrypt w pythonie wykrywający z jakimś opóźnienie stan niski na tej nóżce (typu 3 pod rząd, sprawdzane co 10s), i wyłączający raspberry.

[tomekL]

Jak masz połączenie zdalne to rób shutdown i włączaj kiedy potrzebujesz. Druga rzecz to instalacja systemu nie na karcie ale na małym dysku SSD. 

[r.ziomber]

3 godziny temu, tomekL napisał(a):

Druga rzecz to instalacja systemu nie na karcie ale na małym dysku SSD. 

Lub https://learn.adafruit.com/read-only-raspberry-pi/overview

+ zewnetrzny dysk na dane.

Nadal jednak programowo sprawdzałbym stan zasilania i wyłączał RPi.

Edytowane 24 Października 2023 przez r.ziomber

[tomekL]

35 minutes ago, r.ziomber said:

Lub https://learn.adafruit.com/read-only-raspberry-pi/overview

+ zewnetrzny dysk na dane.

Nadal jednak programowo sprawdzałbym stan zasilania i wyłączał RPi.

 

Oczywiście Niejasno opisałem. Wdrożyłbym obydwa moje punkty.

[Pikolaczek]

4 hours ago, tomekL said:

Druga rzecz to instalacja systemu nie na karcie ale na małym dysku SSD. 

To nie ma nic do rzeczy w sprawie graceful shutdown.

 

[Behlur_Olderys]

23 minuty temu, Pikolaczek napisał(a):

To nie ma nic do rzeczy w sprawie graceful shutdown.

 

 

 

Rozumiem, że corrupted fs może być zarówno na SSD jak i na karcie micro SD?

 

Najprościej będzie chyba dbać o to wyłączanie przez ssh

A jak już będę miał docelowy zestaw to zastanowię się nad prawdziwym UPS

Dzięki!

[szuu]

ciekawy problem!

dzisiejsze systemy plików same sie naprawiają w razie niespodziewanego przerwania pracy systemu przed zapisaniem wszystkiego więc czy to oznacza że linux w rpi jest pod tym względem jakoś upośledzony czy może wina leży po stronie karty, w której nagłe wyłączenie zasilania zaburza normalną pracę i wywołuje jakieś niespójności w danych?

[piotrfie]

53 minuty temu, szuu napisał(a):

oznacza że linux w rpi jest pod tym względem jakoś upośledzony

Nie. Współczesne systemy plików potrafią przeżyć na prawdę dużo, ale jak ma się pecha to można załatwić na amen każdy system plików w dowolnym systemie operacyjnym.

[tomekL]

2 hours ago, Behlur_Olderys said:

Rozumiem, że corrupted fs może być zarówno na SSD jak i na karcie micro SD?

 

 

Tak, ale mam 2 RaspPi, jednen na karcie, drugi na SSD. Ten na karcie zaliczył już 2 pady, ten drugi żadnego. Poza tym jak często padają Ci dyski SSD w komputerze. Dodatkowo działa szybciej na SSD. Ja kupiłem za grosze mały dysk SSD 120GB, chyba za 90 zł, 2 lata temu.

[lkosz]

1 godzinę temu, szuu napisał(a):

dzisiejsze systemy plików same sie naprawiają w razie niespodziewanego przerwania pracy systemu przed zapisaniem wszystkiego więc czy to oznacza że linux w rpi jest pod tym względem jakoś upośledzony czy może wina leży po stronie karty, w której nagłe wyłączenie zasilania zaburza normalną pracę i wywołuje jakieś niespójności w danych?

ext4 lub xfs oraz fsck standardowo używane we współczesnych linuksach są o wiele doskonalsze od tego, co było 15 lat temu, ale nadal mają ograniczone możliwości samonaprawy i wszystkiego nie przeżyją. To nie ZFS na raidz3. Jeśli dane nie zostały zapisane z buforów to skąd fsck ma to potem wyczarować? Mechanizmy samonaprawy systemu plików to ostateczność, a nie ficzer do używania na co dzień. Jeśli za każdym razem musi być odpalany fsck, to mamy do czynienia z niewłaściwym użyciem komputera lub sprzętem który zaraz całkiem padnie.
Po drugie mówimy o nagłym odcinaniu zasilania pamięci flash, jeszcze dodatkowo karcie pamięci - póki się nie wykonuje na niej żadnych zapisów, lub robi to bardzo rzadko, to konsekwencje są niewielkie/brak. Pamięci flash to nie dyski magnetyczne (w 2023 roku trzeba dodać: nie dyski z zapisem CMR, bo SMR to patola), którym nota bene również nie należy gwałtownie odcinać zasilania. Algorytmy zapisu w pamięciach flash, a zwłaszcza popularnych kartach sandiska są skomplikowane, operacje są buforowane, kasowanie odkładane na później, i póki to działa, to jest ok. Ale jak jest pad, to jest bardzo źle i czasem nie sposób to ręcznie posklejać, nie wspominając o prostym narzędziu, jakim jest fsck. Do tego dochodzi bufor operacji po stronie samego systemu operacyjnego, operacje dyskowe w linuksie nie są domyślnie synchroniczne. Dlatego należy system operacyjny zatrzymywać w cywilizowany sposób, nawet załączając synchroniczny zapis w systemie. To nie windows, nie trwa to pół dnia, tylko kilka-kilkanaście sekund.

 

2 godziny temu, Behlur_Olderys napisał(a):

Rozumiem, że corrupted fs może być zarówno na SSD jak i na karcie micro SD?

tak, najłatwiej to zrobić na karcie pamięci, minimalnie trudniej na SSD, ale zależy od technologii. SSD nie są jakimiś super odpornymi nośnikami. Dużo trudniej uszkodzić system plików na HDD (CMR). SMR HDD unikać jak ognia. Jeśli potrzebujesz wykonywać dużo zapisów na kartę pamięci, to kup kartę przystosowaną do takich obciążeń, bo inaczej będziesz zaliczać pady. Cudów nie ma, tanie karty pamięci się po prostu uszkadzają. Tak samo tanie SSD szlag trafia bardzo szybko. Co do zasady lepiej na raspberry korzystać z karty pamięci, a nie SSD po USB, bo niepotrzebnie zabierasz sobie przepustowość USB, oraz zależnie od wersji RPi - sieci. Jeśli potrzebujesz przerabiać duże ilości danych, to rpi5, a najlepiej NUC na architekturze x86, a dyski typu WD Red.

Edytowane 24 Października 2023 przez lkosz

[MateuszW]

32 minuty temu, lkosz napisał(a):

Dużo trudniej uszkodzić system plików na HDD

Jako ciekawostkę dodam, że HDD serwerowe od WD mają technologię zabezpieczenia przed uszkodzeniem danych wykorzystującą pamięć flash. Normalnie dysk operuje na buforze RAM, a w momencie utraty zasilania wykorzystuje energię wirowania talerzy do skopiowania bufora do flashu, dzięki czemu teoretycznie nie utraci żadnych danych. Jak to działa w praktyce - trudno sprawdzić  

[r.ziomber]

Nie testowane. trochę pseudokod C++. Pamiętajcie, by nie przekroczyć 3.3V na GPIO Raspberry Pi.

https://abyz.me.uk/rpi/pigpio/cif.html

 

#include <iostream>
#include <pigpio.h>
#include <chrono>
#include <thread>
#define PIN 7

int main ()
{
  if (gpioInitialise () < 0)
    {
      std::cerr << "Failed to initialize pigpio\n";
      return 1;
    }
  gpioSetMode (PIN, PI_INPUT);
  //gpioSetPullUpDown(PIN, PI_PUD_UP);
  auto lastTimePower = std::chrono::high_resolution_clock::now ();
  while (1)
    {
      if (gpioRead (PIN) == 1)
	lastTimePower = std::chrono::high_resolution_clock::now ();
      else
	{
	  auto now = std::chrono::high_resolution_clock::now ();
	  auto elapsed =
	    std::chrono::duration_cast <std::chrono::milliseconds>
	    (now - lastTimePower).count ();
	  if (elapsed >= 5000)
	    {
	      system ("sudo shutdown -h now");
	      //jesli nie ubije procesu przed kolejnym przejesciem petli
	      std::this_thread::sleep_for (std::chrono::milliseconds (10000));
	    }
      }
	 std::this_thread::sleep_for (std::chrono::milliseconds (100));
  }
      gpioTerminate ();
      return 0;
}

Całkiem prawdopodobne, że https://pl.wikibooks.org/wiki/C/time będzie wydajniejsze, nie mówiąc o prostszym użyciu od std::chrono::high_resolution_clock::now (); W końcu nie potrzebujemy milisekundowej dokładności.

https://pl.wikibooks.org/wiki/C/clock - to też warte rozważenia, bo po aktualizacji czasu systemowego z NTP nagle Unix time przeskoczy o 50 lat. O ile pomiar nie wykaże stanu niskiego if (gpioRead (PIN) == 1), nie powinno to wpłynąć na działanie programu. W przeciwnym razie może nie odczekać zakładanego minimalnego okresu braku zasilania if (elapsed >= 5000).

Edytowane 25 Października 2023 przez r.ziomber

[szuu]

3 godziny temu, lkosz napisał(a):

Jeśli dane nie zostały zapisane z buforów to skąd fsck ma to potem wyczarować?

dane które nie zostały zapisane pozwalam mu pominąć  ma tylko przywrócić najnowszy możliwy spójny stan systemu plików żeby nie było cyrków z uruchamianiem.

no i po to są filesystemy z księgowaniem żeby było to możliwe, i to nie probabilistycznie zależnie od pecha lub dnia tygodnia tylko za każdym razem. a więc skoro sam linux jest tam normalny i to potrafi, to w takim razie pewnie wina karty?

 

3 godziny temu, lkosz napisał(a):

Algorytmy zapisu w pamięciach flash, a zwłaszcza popularnych kartach sandiska są skomplikowane, operacje są buforowane, kasowanie odkładane na później, i póki to działa, to jest ok.

no właśnie, bo jednak fajnie by było gdyby jakieś minimalne założenia taki zapis na karcie spełniał (w rodzaju "wszystko albo nic") a nie taka samowolka.

 

ciekawe czy dałoby się poprawić sytuację przez wstawienie pomiędzy rpi i kartę jakiegoś prostego układu z kondensatorem podtrzymującym zasilanie samej karty, tak żeby zawsze zdążyła dokończyć swoje wewnętrzne machinacje nawet gdy prąd dla rpi już się skończył? (ktoś pewnie powie że to przekombinowane w porównaniu do UPS'a dla rpi ale jednak kusi tu prostota rozwiązania czysto hardwarowego i z o wiele mniejszym wymaganym zapasem energii niż powerbank który musiałby zasilić całe urządzenie i to przez dużo dłuższy czas)

[lkosz]

15 godzin temu, szuu napisał(a):

dane które nie zostały zapisane pozwalam mu pominąć  ma tylko przywrócić najnowszy możliwy spójny stan systemu plików żeby nie było cyrków z uruchamianiem.

no i po to są filesystemy z księgowaniem żeby było to możliwe, i to nie probabilistycznie zależnie od pecha lub dnia tygodnia tylko za każdym razem. a więc skoro sam linux jest tam normalny i to potrafi, to w takim razie pewnie wina karty?

niestety odzyskiwanie journala to tylko odzyskiwanie journala, na nośniku mogą być mimo to błędy, lub powstać, lub powstawać (nie takie ficzery mają pamięci flash), z którymi fsck może sobie nie poradzić. O ile je wykryje... zwykle to bywa tak, że błędy się robią, robią, przybywa, aż nagle są same błędy wejścia/wyjścia ext4 nie jest systemem plików, który by kontrolował bardzo dobrze spójność danych i umiał to naprawić. Na szczęście są alternatywy, ale to już raczej nie na jedną biedną kartę SD

Edytowane 25 Października 2023 przez lkosz

[mcbarlo]

19 godzin temu, MateuszW napisał(a):

Jako ciekawostkę dodam, że HDD serwerowe od WD mają technologię zabezpieczenia przed uszkodzeniem danych wykorzystującą pamięć flash. Normalnie dysk operuje na buforze RAM, a w momencie utraty zasilania wykorzystuje energię wirowania talerzy do skopiowania bufora do flashu, dzięki czemu teoretycznie nie utraci żadnych danych. Jak to działa w praktyce - trudno sprawdzić  

 

Dyski SSD np. Samsungi z serii PM i Intele DC mają podtrzymywanie bufora tak żeby zdążyły zapisać flash. Problem raczej jest z buforem dyskowym w RAM-ie, bo ten przy padzie zasilania zniknie bezpowrotnie. Myślę, że nie ma co wymyślać koła na nowo tylko trzeba kupić starego UPS-a APC i do tego kartę zarządzającą typu AP9616 albo AP9619 gdzie można podłączyć czujnik temperatury i wilgotności. Za pomocą SNMP można odczytać z niej informacje czy prąd jest, stan baterii i wiele innych rzeczy i zrobić z tych informacji dowolny użytek. :)

[Behlur_Olderys]

Jeśli będę robił już full-remote, to pewnie nie będę chciał oszczędzać na UPS.
Pytanie, czy są takie, które zapewniają 12V czy też trzeba się bawić w "redukcję" z 230V? 
No i rozumiem, że w lepszych modelach jest jakiś kabelek (usb? eth?) który można podpiąć do RPi i w jakimś protokole odpytać pana UPSa, czy czasem wtyczka nie wypadła z gniazdka...?  

[lkosz]

Rozumiem, że chcesz zasilać się z sieci energetycznej? To przydatny może się okazać program upsc (warto sprawdzić kompatybilność UPSa przed zakupem). Zasilacz porządny, 230-12V, lub ATX (trochę bezpieczników + zasilacze hasswell-ready dobrze się sprawdzają, ja akurat z tego korzystam, na balkon idzie 12V 4mm przewodem).

 

Możesz też drugie podejście - akumulator AGM, z niego zasilasz sprzęt, i pod niego podłączasz ładowarkę. Akumulator pracuje w takim układzie domyślnie w chwiejnym standby. Na raspberry pi pico można zrobić monitorowanie napięć + wyzwalanie eventów wyłączających sprzęt, albo to wyzwalanie na głównym komputerze odpytującym pi pico RESTem po wifi lub portem szeregowym.

 

Jeśli nie cieszysz się na myśl, że będzie trochę lutowania i elektroniki - lepiej iść w klasyczny UPS. Musisz się tylko zatroszczyć, żeby te 230V było bezpieczne w warunkach roszenia.

Edytowane 25 Października 2023 przez lkosz

[Behlur_Olderys]

35 minut temu, lkosz napisał(a):

Rozumiem, że chcesz zasilać się z sieci energetycznej? (...) Musisz się tylko zatroszczyć, żeby te 230V było bezpieczne w warunkach roszenia.

Tak, ale docelowo pewnie to będzie stacjonarne obserwatorium z zamykanym dachem, jest duża szansa, że roszenie nie będzie problemem.

[tomekL]

9 hours ago, Behlur_Olderys said:

Tak, ale docelowo pewnie to będzie stacjonarne obserwatorium z zamykanym dachem, jest duża szansa, że roszenie nie będzie problemem.

Jak dach jest zamknięty, to nie ma żadnego roszenia, bynajmniej u mnie w budce tak jest. Rosi się tylko podczas sesji.

[lkosz]

11 godzin temu, Behlur_Olderys napisał(a):

Tak, ale docelowo pewnie to będzie stacjonarne obserwatorium z zamykanym dachem, jest duża szansa, że roszenie nie będzie problemem.

niemniej - jest to pod chmurką. Instalacja elektryczna powinna tu być zabezpieczona jakby była na zewnątrz - przeciwporażeniowe, przed uszkodzeniem, przed wodą, przeciwprzepięciowo. W takich budynkach jest możliwa kondensacja pary wodnej w niesprzyjających warunkach. Plus oczywiście zabezpieczenia przeciwpożarowe i to takie wzięte na serio. Wystarczy że jakiś gryzoń wbije ząbki nie tam gdzie trzeba i nieszczęście gotowe, nie wspominając o błędach ludzkich, zacięciu się dachu, przeciekach, śniedzeniu styków itp. Albo jako alternatywa instalacja 12V, która też wymaga zabezpieczeń np. przeciwpożarowych, ale napięcie jest bezpieczne, więc o tę jedną część jest łatwiej.

[tomekL]

35 minutes ago, lkosz said:

niemniej - jest to pod chmurką. Instalacja elektryczna powinna tu być zabezpieczona jakby była na zewnątrz - przeciwporażeniowe, przed uszkodzeniem, przed wodą, przeciwprzepięciowo. W takich budynkach jest możliwa kondensacja pary wodnej w niesprzyjających warunkach. Plus oczywiście zabezpieczenia przeciwpożarowe i to takie wzięte na serio. Wystarczy że jakiś gryzoń wbije ząbki nie tam gdzie trzeba i nieszczęście gotowe, nie wspominając o błędach ludzkich, zacięciu się dachu, przeciekach, śniedzeniu styków itp. Albo jako alternatywa instalacja 12V, która też wymaga zabezpieczeń np. przeciwpożarowych, ale napięcie jest bezpieczne, więc o tę jedną część jest łatwiej.

Nie jestem elektrykiem i średnio się na tym znam, ale u siebie zrobiłem normalną małą rozdzielnicę, schemat gdzieś z netu zapożyczyłem, ma to co rozdzielnica w mieszkaniu. Nawiasem nie wiem czy to potrzebne skoro kabel idzie z głównej rozdzielnicy, gdzie tam wszystko też jest. Na pewno ładnie wygląda i bardziej profesjonalnie Dodatkowo ubezpieczyłem jeszcze swoją budkę, przed włamaniami i zdarzeniami losowymi na 25tys, składka 150 rocznie.

Ale mam pytanko, bo mnie zaintrygowałeś. Co rozumiesz dokładnie przez "zabezpieczenia przeciwpożarowe". Jakiego rodzaju to są zabezpieczenia?

[lkosz]

13 minut temu, tomekL napisał(a):

Ale mam pytanko, bo mnie zaintrygowałeś. Co rozumiesz dokładnie przez "zabezpieczenia przeciwpożarowe". Jakiego rodzaju to są zabezpieczenia?

Po pierwsze - bezpieczniki i zabezpieczenia nadprądowe, w części DC również. Nie można zasilacza dającego 50A czy nawet 10A podłączać do sprzętu na hura i liczyć że wszystko będzie dobrze. Bezpieczniki płytkowe 2-4A to mus. Spadek napięcia na bezpiecznikach nie przeszkadza sprzętowi astro. Wszystkie akumulatory powinny mieć obowiązkowo zabezpieczenia przeciwzwarciowe, przynajmniej jedno. Akumulatory litowe najlepiej dwa różnego typu. Następnie: takie wykonanie instalacji, że pożar w wyniku zwarcia ugasi się sam (samogasnące tworzywa, zainstalowanie w taki sposób, że drewno się nie zapali, zabezpieczenie drewna odpowiednimi środkami, dodatkowe osłony, płyty metalowe itp). Certyfikowane części założone w prawidłowy sposób zgodnie z normami. Podłoga niepalna, podział na strefy - zależnie od możliwości, nawet niedużymi skrzynkami metalowymi. Takie rozłożenie urządzeń, że pożar dowolnego, nie rozprzestrzeni się na sąsiedztwo (nawet UPS może się zapalić lub eksplodować, AGMy są względnie bezpieczne, ale mogą na skutek awarii elektroniki lub w środku - intensywnie gazować - nie jeden mechanik stracił zęby nachylając się z papierosem nad samochodem; ogniwa litowe też mają swoje kaprysy). Drugie to aktywne gaszenie - automat wykrywający ogień, odcinający zasilanie i emitujący środek gaśniczy - tutaj pewnie dwutlenek węgla. Jeśli mówimy o sprzęcie za dziesiątki tysięcy złotych - warto pomyśleć i o aktywnym gaszeniu. Ubezpieczenia są, ale mają masę gwiazdek i gwiazdeczek. I jeśli tylko wyjdzie, że instalacja elektryczna była nieodpowiedniej jakości lub bez odbioru - będzie problem. Z przydomowym obserwatorium pewnie wystarczy syrena alarmowa i gaśnica przy wejściu, ale jeśli mówimy o zdalnym obserwatorium, to zanim tam ktoś dobiegnie, to zostanie tylko popiół i diament z popękanej optyki.

[Bentoq]

1 hour ago, lkosz said:

(...) to zostanie tylko popiół i diament z popękanej optyki.

 

Ewentualnie upieczoną sowę

[ZbyT]

19 godzin temu, Behlur_Olderys napisał(a):

Jeśli będę robił już full-remote, to pewnie nie będę chciał oszczędzać na UPS.
Pytanie, czy są takie, które zapewniają 12V czy też trzeba się bawić w "redukcję" z 230V?

 

potrzebujesz zasilacz buforowy. W razie zaniku zasilania z sieci przejdziesz na zasilanie z akumulatora. Można to zrobić "prymitywnie" z samymi diodami rozdzielającymi lub coś bardziej skomplikowanego. Jeśli dołożysz tam jakiś najprostszy procesorek to możesz zrobić dowolne powiadomienie o przejściu na akumulator. Od wystawienia sygnału na jednym pinie (przez transoptor) po wysyłanie informacji przez UART, SPI, I2C czy jeszcze inaczej np. po wifi czy CAN, a do tego monitorować stan akumulatora, okresowe przechodzenie na zasilanie z aku (celem kontroli sprawności akumulatora plus ewentualny alarm uszkodzenia akumulatora). Możesz też zasilać setup z akumulatora przez całą sesję (przy braku zasilania z sieci) i zamykać system gdy akumulator rozładuję się do zadanej wartości. Możliwości masa, wszystko zależy od twojej fantazji

 

pozdrawiam