Raspberry Pi: Ervaringen en Discussie - deel 2

[Freee!!]

RudolfR schreef op zondag 7 augustus 2022 @ 14:54:
[...]
Ja, zoiets kan, maar hoeft niet. macvlan noemen ze dat.

Het heeft zo zijn voordelen.

[synoniem]

dss58 schreef op zondag 7 augustus 2022 @ 12:04:
[...]

ook wel eens een paar keer een falende SD gehad, daarom is docker wat mij betreft niet gewenst voor de pi als ik het hier zo is lees, mocht pihole om die reden falen draait ie weer binnen een half uurtje en de meeste tijd is wachten

De meeste keren dat je een falende SD kaart hebt ligt het aan de voeding niet aan de SD kaart is mijn ervaring. Met mijn RPi 2 heb ik eigenlijk nog nooit falende SD kaartjes gehad maar met 3b en 4 wel maar dat was dus opgelost zodra ik een betere voeding gebruikte. En juist met pihole in docker ben in je 5 minuten weer in de lucht als er wat fout gaat.

[dss58]

Freee!! schreef op zondag 7 augustus 2022 @ 13:41:
[...]

Goede kwaliteit SD kaarten gebruiken, ik heb hier al langer dan ik me kan herinneren geen SD kaartproblemen gehad en ik heb 3 RPi's draaien (met Pi-Hole in docker).

ja klopt, kwam hier is meen ik een jaar terug een link tegen en heb er gelijk 5 besteld, dat zijn de kosten niet meer, met welk merk ik die failure had weet ik niet meer, in ieder geval gelijk weg gemikt
maar waarom heb je pihole in docker draaien ? draait er nog meer op ?
ik heb trouwens 7 pi's hier draaien, kan wel een cluster bouwen met kubernetes ofzo

RudolfR schreef op zondag 7 augustus 2022 @ 14:54:
[...]


Ja, zoiets kan, maar hoeft niet. macvlan noemen ze dat.

oh ja, gisteren toevallig een filmpje over gezien.

[ Voor 15% gewijzigd door dss58 op 07-08-2022 17:11 ]

[Freee!!]

synoniem schreef op zondag 7 augustus 2022 @ 16:04:
[...]
De meeste keren dat je een falende SD kaart hebt ligt het aan de voeding niet aan de SD kaart is mijn ervaring. Met mijn RPi 2 heb ik eigenlijk nog nooit falende SD kaartjes gehad maar met 3b en 4 wel maar dat was dus opgelost zodra ik een betere voeding gebruikte. En juist met pihole in docker ben in je 5 minuten weer in de lucht als er wat fout gaat.

Goede voeding is inderdaad wel een voorwaarde, dat heb ik altijd gehad.

[nitrodesign]

Hallo Mede Tweakers,

Hopelijk kunnen jullie mij in de juiste richting helpen. ik heb pas geleden een Raspberry Pi Pico W gekocht. De rede waarom ik deze had gekocht is dat ik een project voorbij zag komen wat wel leuk leek om te maken (https://www.tomshardware....y-pi-pico-powered-pumpkin).

Nu wil ik de LEDS voor een ander doeleinde gebruiken namelijk een soort van stoplicht.

Waarom wil Nitro een stoplicht .......
Wij hebben een dochtertje en die is nogal vroeg wakker, dus met het stoplicht wil ik aangeven wanneer ze papa mag roepen als ze wakker is .

Dus het plan is om een stoplicht te maken met 2x 8x8 LEDS (1x groen en 1x rood). Nu moeten de LEDS op rood blijven staan en om 07:00 mogen de LEDS op groen. tot bijvoorbeeld 09:00, na 09:00 mogen de LEDS weer uit en dan mogen ze om 20:00 op rood en ga zo maar door.

Nu is mijn vraag, weet de Raspberry Pi Pico hoe laat het is, of hoe programmeer je dat en hoe kun dan in combinatie met tijd aangeven wanneer welke LED aan moet.

Hierbij de LEDS die ik heb gekocht (https://opencircuit.nl/pr...rix-module-8x8-bouwpakket).

Hopelijk kunnen jullie mij hierbij helpen.

Groet,

Nitro

[ Voor 4% gewijzigd door nitrodesign op 08-08-2022 09:34 ]

[alesandro_46]

nitrodesign schreef op maandag 8 augustus 2022 @ 09:33:
Hallo Mede Tweakers,

Hopelijk kunnen jullie mij in de juiste richting helpen. ik heb pas geleden een Raspberry Pi Pico W gekocht. De rede waarom ik deze had gekocht is dat ik een project voorbij zag komen wat wel leuk leek om te maken (https://www.tomshardware....y-pi-pico-powered-pumpkin).

Nu wil ik de LEDS voor een ander doeleinde gebruiken namelijk een soort van stoplicht.

Waarom wil Nitro een stoplicht .......
Wij hebben een dochtertje en die is nogal vroeg wakker, dus met het stoplicht wil ik aangeven wanneer ze papa mag roepen als ze wakker is .

Dus het plan is om een stoplicht te maken met 2x 8x8 LEDS (1x groen en 1x rood). Nu moeten de LEDS op rood blijven staan en om 07:00 mogen de LEDS op groen. tot bijvoorbeeld 09:00, na 09:00 mogen de LEDS weer uit en dan mogen ze om 20:00 op rood en ga zo maar door.

Nu is mijn vraag, weet de Raspberry Pi Pico hoe laat het is, of hoe programmeer je dat en hoe kun dan in combinatie met tijd aangeven wanneer welke LED aan moet.

Hierbij de LEDS die ik heb gekocht (https://opencircuit.nl/pr...rix-module-8x8-bouwpakket).

Hopelijk kunnen jullie mij hierbij helpen.

Groet,

Nitro

Wellicht is WLED een optie?
Er is een build voor de Rpi Pico W.

[nitrodesign]

alesandro_46 schreef op maandag 8 augustus 2022 @ 09:38:
[...]

Wellicht is WLED een optie?
Er is een build voor de Rpi Pico W.

Ik neem aan dat WLED staat voor Wireless LED, maar als ik dit zo lees betekend dit dan dat ik mijn Rpi Pico W tot webserver maak waar ik een ledstrip koppel aan de contacten om hem zo aan te sturen ?

En volgens mij staat er in dat artikel dat het nog niet mogelijk is om WLED te gebruiken i.c.m. een Rpi Pico W. Ik kan overigens nergens iets vinden van Rpi Pico W met WLED.

[ Voor 15% gewijzigd door nitrodesign op 08-08-2022 11:54 ]

[alesandro_46]

nitrodesign schreef op maandag 8 augustus 2022 @ 09:51:
[...]


Ik neem aan dat WLED staat voor Wireless LED, maar als ik dit zo lees betekend dit dan dat ik mijn Rpi Pico W tot webserver maak waar ik een ledstrip koppel aan de contacten om hem zo aan te sturen ?

Jep

En volgens mij staat er in dat artikel dat het nog niet mogelijk is om WLED te gebruiken i.c.m. een Rpi Pico W. Ik kan overigens nergens iets vinden van Rpi Pico W met WLED.

Ah, toen ik er snel naar zocht dacht ik, vanwege de closed melding dat het opgelost was. Echter staat er:

I suggest to close this issue, at it seems out of reach at least for the next year.

Dus het werkt helaas niet.

Mocht je geïnteresseerd zijn in WLED voor jouw project. Zelf heb ik het draaien op:
1.ESP32 (Tinytronics)
2. Wemos D1 mini (opencircuit) echter zie ik op andere webshops dat dit bordje discontinued is en vervangen door de Wemos S2 mini (tinytronics). Ik weet niet of deze compatible is met WLED.
3. ESP-01 met RGB Led bordje (AliExpress)
Bovenstaande producten zijn ook rechstreeks in China te koop.

Maar ik ben nu tever offtopic gegaan. Mocht je vragen hebben hierover stuur me gerust een privé bericht.

[SebasFM]

alesandro_46 schreef op maandag 8 augustus 2022 @ 17:32:
2. Wemos D1 mini (opencircuit) echter zie ik op andere webshops dat dit bordje discontinued is en vervangen door de Wemos S2 mini (tinytronics). Ik weet niet of deze compatible is met WLED.

Bovenstaande producten zijn ook rechstreeks in China te koop.

offtopic:
Wemos als merknaam bestaat niet meer ivm de vele kloonbordjes die zich allemaal Wemos noemden. Maar de Lolin D1 Mini wordt nog steeds doorontwikkeld. Recent via hun officiele Lolin store op Ali nog D1 mini's besteld, versie 4.0.0. Zie hier de documentatie van het bordje.

[pennywiser]

Freee!! schreef op zondag 7 augustus 2022 @ 13:41:
[...]

Goede kwaliteit SD kaarten gebruiken, ik heb hier al langer dan ik me kan herinneren geen SD kaartproblemen gehad en ik heb 3 RPi's draaien (met Pi-Hole in docker).

Samsung Endurance of op zijn minst Evo.

[_Eend_]

pennywiser schreef op maandag 8 augustus 2022 @ 21:30:
[...]

Samsung Endurance of op zijn minst Evo.

In mijn RPi's heb ik altijd Sandisk of Samsung Evo kaartjes zitten, sommige daarvan draaien al jaren een webservertje en ik heb er nog nooit problemen mee gehad.

^{* _Eend_ klopt af...}

[pennywiser]

_Eend_ schreef op dinsdag 9 augustus 2022 @ 10:04:
[...]


In mijn RPi's heb ik altijd Sandisk of Samsung Evo kaartjes zitten, sommige daarvan draaien al jaren een webservertje en ik heb er nog nooit problemen mee gehad.

^{* _Eend_ klopt af...}

Sandisk heeft ook Endurance kaartjes, High en Max Endurance.

[fub]

nitrodesign schreef op maandag 8 augustus 2022 @ 09:33:
Waarom wil Nitro een stoplicht .......
Wij hebben een dochtertje en die is nogal vroeg wakker, dus met het stoplicht wil ik aangeven wanneer ze papa mag roepen als ze wakker is .

Mijn zus had dit voor haar kinderen opgelost met zo'n stekker-nachtlampje op zo'n stopcontact-schakelklok. Natuurlijk minder leuk knutselen, maar het werkte. Ook stukje goedkoper te implementeren...

[The Zep Man]

nitrodesign schreef op maandag 8 augustus 2022 @ 09:33:
Dus het plan is om een stoplicht te maken met 2x 8x8 LEDS (1x groen en 1x rood). Nu moeten de LEDS op rood blijven staan en om 07:00 mogen de LEDS op groen. tot bijvoorbeeld 09:00, na 09:00 mogen de LEDS weer uit en dan mogen ze om 20:00 op rood en ga zo maar door.

Je kan ook kijken naar een Luxafor. Dan heb je een product dat je makkelijk via software (zoals op een Pi m.b.v. een cron/systemd timer taakje) aan kan sturen. Kan je ook meteen gebruiken voor andere zaken (zoals thuis werken, en dat de kinderen je dan even niet mogen storen).

[ Voor 80% gewijzigd door The Zep Man op 09-08-2022 15:55 ]

[GeeBee]

Een Raspberry Pi icm een 32 x 64 LED-panel is ook snel in elkaar te zetten.

https://learn.adafruit.co...x-panel-to-a-raspberry-pi

[Verwijderd]

nitrodesign schreef op maandag 8 augustus 2022 @ 09:33:
stoplicht vraag met rpi pico

Ik weet dat dit het RPi topic is en geen idee of het hier gebruikelijk is om iets anders voor te stellen. (Ik wil dan ook niet overkomen als de gemiddelde stackoverflow antwoorder).

Een RPi lijkt me wat overkill om een LED matrix aan en uit te zetten op bepaalde tijdstippen op een dag, en misschien kan je hem nog gebruiken voor andere projectjes die je wilt beginnen.
Wat je wilt hebben voor de tijd bij te houden is een RTC (real-time clock) chip. Je geeft dat eenmaal de juiste tijd aan en dat blijft de tijd bijhouden zolang het gevoed wordt (soms wel langer dan het jaar 2100).
Een arduino met een RTC module lijkt me dan perfect voor deze toepassing, en leuk als je je tenen wilt dippen in het programmeren.

[_Eend_]

Verwijderd schreef op woensdag 10 augustus 2022 @ 11:24:
[...]


Ik weet dat dit het RPi topic is en geen idee of het hier gebruikelijk is om iets anders voor te stellen. (Ik wil dan ook niet overkomen als de gemiddelde stackoverflow antwoorder).

Een RPi lijkt me wat overkill om een LED matrix aan en uit te zetten op bepaalde tijdstippen op een dag, en misschien kan je hem nog gebruiken voor andere projectjes die je wilt beginnen.
Wat je wilt hebben voor de tijd bij te houden is een RTC (real-time clock) chip. Je geeft dat eenmaal de juiste tijd aan en dat blijft de tijd bijhouden zolang het gevoed wordt (soms wel langer dan het jaar 2100).
Een arduino met een RTC module lijkt me dan perfect voor deze toepassing, en leuk als je je tenen wilt dippen in het programmeren.

Een RPi Pico is een microcontroller ala Arduino, en die kost nog geen 10 euro, goedkoper dan veel Arduino's

[Verwijderd]

_Eend_ schreef op woensdag 10 augustus 2022 @ 11:31:
[...]


Een RPi Pico is een microcontroller ala Arduino, en die kost nog geen 10 euro, goedkoper dan veel Arduino's

Tiens. Mag je mijn vorig bericht achterwege laten. Had de prijzen niet opgezocht, maar zag dat het een RP2040 chip was.

De RP2040 is een 32-bit dual-core ARM Cortex-M0+ microcontroller op geïntegreerd circuit van de Raspberry Pi Foundation.

Gek dat ze die al kunnen verkopen onder de 10 euro.

[nero355]

Verwijderd schreef op donderdag 4 augustus 2022 @ 09:52:
Voor de rest ook bezig met een 3B+. Bedoeling is om er Kodi op te draaien en mss later uitbreiden met lokaal opslag ook (ik heb nog 2 2TB harde platen liggen).

NOFI, maar wat mij betreft zit je dan teveel te "houtje, touwtje" knutselen en kan je beter richting een kleine DIY NAS/HTPC denken waar je dat allemaal in propt!

Een Raspberry Pi kan allerlei dingen heel leuk doen, maar een NAS of HTPC/mediaspeler is het IMHO gewoon niet!

Verwijderd schreef op zondag 7 augustus 2022 @ 08:25:
Ik had een falende SD kaart in mijn 3B, dan maar eens een fresh install gedaan op een nieuwe 4B maar het valt wel op dat de temperatuur hier een stuk hoger is, 49° <-> 58° voor exact dezelfde load dat deze krijgt. Gewoon een ander bordje...

Daarom zou ik zo graag weer zo'n performance/verbruik verhoudingen test willen zien net als toen de 3B+ op de markt verscheen en minder daarin bleek te zijn dan de 2B en 3B

dss58 schreef op zondag 7 augustus 2022 @ 12:04:
ook wel eens een paar keer een falende SD gehad, daarom is docker wat mij betreft niet gewenst voor de pi als ik het hier zo is lees, mocht pihole om die reden falen draait ie weer binnen een half uurtje en de meeste tijd is wachten

Juist alleen effe je Docker meuk erop knallen en config files terugzetten is dan heel snel gedaan!

[dss58]

nero355 schreef op zaterdag 13 augustus 2022 @ 16:04:
[...]

NOFI, maar wat mij betreft zit je dan teveel te "houtje, touwtje" knutselen en kan je beter richting een kleine DIY NAS/HTPC denken waar je dat allemaal in propt!

Een Raspberry Pi kan allerlei dingen heel leuk doen, maar een NAS of HTPC/mediaspeler is het IMHO gewoon niet!


[...]

Daarom zou ik zo graag weer zo'n performance/verbruik verhoudingen test willen zien net als toen de 3B+ op de markt verscheen en minder daarin bleek te zijn dan de 2B en 3B


[...]

Juist alleen effe je Docker meuk erop knallen en config files terugzetten is dan heel snel gedaan!

een nieuwe van scratch af aan instellen en of je er dan docker meuk terug zet of in mijn geval pihole, mwa... zal weinig uit maken in tijd

[ZuinigeRijder]

Mijn oude Raspberry Pi type B Versie 2.0 met 512MB RAM uit 2013 heeft het altijd goed gedaan de afgelopen 9 jaar met Wheezy OS voor het uitlezen van mijn SMA omvormer met SMASpot en de data naar PVOutput te sturen. Echter er kwam een uitbreiding van zonnepanelen op mijn dubbele carport en nu was er het probleem dat ik eigenlijk de Solis omvormer data ook naar PVOutput wilde sturen.

Helaas was daar geen integratie van, gelukkig heb ik nu op de raspberry pi een zelfgemaakt script SolisCloud2PVOutput erop lopen. Helaas kreeg ik schrijfvouten met de SDHC kaart (kan ook wel na 9 jaar), zie dit issue. Nu draai ik het laatste OS Bulls Eye op mijn oude Raspberry Pi in combinatie met SBFSpot, SolisCloud2PVOutput script en een zelfgemaakt script om data van de twee PVOutput systemen te combineren. Hier is het CombinePVOutputSystems script te vinden op github.

Heb voor 1,50 euro (50% kortingsweek op de al belachelijke lage prijs van 3 euro) bij de blokker een Philips SDHC kaartje gekocht van 16 GB. Nu wil ik natuurlijk dat dit SDHC kaartje weer lang meegaat. Dus ik heb een aantal dingen gedaan zodat er minder (vaak) geschreven wordt naar de SDHC kaart.

Dingen die ik gedaan heb:

• met log2ram wordt de /var/log naar een RAM disk geschreven (60M van memory gereserveerd hiervoor)
• de logging van SolisCloud2PVOutput en CombinePVOutputSystems worden naar een subdirectory /var/log/rick geschreven
• Ik heb SBFSpot aangepast, zodat de database nu ook onder /var/log/rick staat
• journald max log levels op warning gezet
• logrotate op daily gezet en maar 4 dagen
• journaling gedisabled
• vm swappiness op 25 gezet i.p.v. 60

met sudo iotop -aok meet ik nu nog maar weinig schrijfactiviteit.

De volgende processen schrijven nog naar SDHC kaart:

• init splash
• dhcpcd -b -q
• bluetoothd (deze wordt 1x per 5 minuten gebruikt/gereset om de SMA omvormer uit te lezen)
• systemd-timesyncd
• log2ram (1x per dag of reboot rsync naar /var/hdd.log)

Hier het resultaat van 10 minuten iotop -aok draaien:

code:

$ sudo iotop -aok
Total DISK READ:         0.00 K/s | Total DISK WRITE:         0.00 K/s
Current DISK READ:       0.00 K/s | Current DISK WRITE:       0.00 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root          0.00 K    108.00 K  ?unavailable?  init splash
  382 be/4 root          0.00 K     52.00 K  ?unavailable?  dhcpcd -b -q
 5875 be/4 systemd-      0.00 K      4.00 K  ?unavailable?  systemd-timesyncd
 5885 be/4 root          0.00 K     56.00 K  ?unavailable?  bluetoothd

Het is niet heel veel data meer wat geschreven wordt, maar kan ik nog eenvoudig iets minder laten schrijven

[synoniem]

Ik neem aan dat je ook je SD-kaartje in /etc/fstab mount met defaults,noatime?

Daarnaast heb ik zelf het f2fs filesysteem gebruikt: /dev/mmcblk0p2 / f2fs defaults,noatime,discard 0 1

Als je er naar terug verlangd ik heb nog een Wheezy image

[ZuinigeRijder]

synoniem schreef op donderdag 18 augustus 2022 @ 14:52:
Ik neem aan dat je ook je SD-kaartje in /etc/fstab mount met defaults,noatime?

Ja:

code:

PARTUUID=986aab4d-02  /               ext4    defaults,noatime  0       1

Daarnaast heb ik zelf het f2fs filesysteem gebruikt: /dev/mmcblk0p2 / f2fs defaults,noatime,discard 0 1

Volgens deze link is het nog niet duidelijk of dit echt een verbetering is. Aangezien mijn vorige kaartje 9 jaar meegegaan heeft zonder log2ram (toen ik de Raspberry Pi aanschafte bestond dit hulpmiddel nog niet), neem ik aan dat zoveel mogelijk terugbrengen van schrijfacties eigenlijk al een hele stap is.

Terug naar de originele vraag, wat schrijft "init splash" buiten /var/log om en waar of hoe dit te voorkomen?

Idem voor dhcpcd -b -q. Ik denk dat deze hier schrijft:

code:

 $ ls -l /var/lib/dhcpcd
total 16
-rw-r--r-- 1 root root  42 Apr  4 14:18 duid
-rw-r--r-- 1 root root 548 Aug 18 10:12 eth0.lease
-rw-r--r-- 1 root root  97 Aug 18 16:10 eth0.lease6
-r-------- 1 root root 192 Apr  4 14:18 secret

Hier is beschreven om links te maken: "Move some system files to temp filesystem", ook voor dhcpcd. Maar dan links naar /var/log/[subdir] leggen

Ook voor bluetoothd, waar schrijft die naar? Zijn er tools die voor een proces kan laten zien waar geschreven wordt?

Als je er naar terug verlangd ik heb nog een Wheezy image

Nee hoor, fijn dat het laatste Pi OS ook op oude hardware draait

[ZuinigeRijder]

ZuinigeRijder schreef op donderdag 18 augustus 2022 @ 16:16:
[...]

Ook voor bluetoothd, waar schrijft die naar? Zijn er tools die voor een proces kan laten zien waar geschreven wordt?

Even mezelf quoten, je kunt strace gebruiken:

It captures and records all system calls made by a process and the signals received by the process.

bijvoorbeeld:

code:

$ sudo strace -p 382

levert onder andere op voor dhcpcd:

code:

openat(AT_FDCWD, "/var/lib/dhcpcd/eth0.lease6", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0644) = 14
write(14, "\7:\277\346\0\2\0\16\0\1\0\1*wq\213h\2\270\373\376;\0\1\0\16\0\1\0\1)\335"..., 97) = 97
close(14)

En bluetooth heeft een cache voor data van/naar SMA omvormer:

code:

/var/lib/bluetooth/<eigen bt adres>/cache/<sma bt adres>

Zou die cache directory naar /var/log/bluetooth/<eigen bt adres>/cache kunnen verhuizen via een link?

[ Voor 35% gewijzigd door ZuinigeRijder op 18-08-2022 17:07 ]

[ZuinigeRijder]

ZuinigeRijder schreef op donderdag 18 augustus 2022 @ 16:37:
....
En bluetooth heeft een cache voor data van/naar SMA omvormer:

code:

/var/lib/bluetooth/<eigen bt adres>/cache/<sma bt adres>

Zou die cache directory naar /var/log/bluetooth/<eigen bt adres>/cache kunnen verhuizen via een link?

Toch maar de stoute schoenen aangetrokken om te proberen de bluetoothd disk writes te voorkomen. De volgende commando's uitgevoerd:

code:

$ crontab -e # disable running SBFspot
$ sudo -i
# service bluetooth stop
# mv /var/lib/bluetooth /var/hdd.log/bluetooth
# cp -rp /var/hdd.log/bluetooth/ /var/log/bluetooth/
# ln -s /var/log/bluetooth /var/lib/bluetooth
# service bluetooth start
# logout
$ crontab -e # enable running SBFspot

Nu is de bluetooth directory onder de log2ram locatie en dus alles in memory.
Voorheen output van iotop -aok na ongeveer 10 minuten:

code:

$ sudo iotop -aok
Total DISK READ:         0.00 K/s | Total DISK WRITE:         0.00 K/s
Current DISK READ:       0.00 K/s | Current DISK WRITE:       0.00 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root          0.00 K    108.00 K  ?unavailable?  init splash
  382 be/4 root          0.00 K     52.00 K  ?unavailable?  dhcpcd -b -q
 5875 be/4 systemd-      0.00 K      4.00 K  ?unavailable?  systemd-timesyncd
 5885 be/4 root          0.00 K     56.00 K  ?unavailable?  bluetoothd

en nu na ongeveer 10 minuten:

code:

$ sudo iotop -aok
Total DISK READ:         0.00 K/s | Total DISK WRITE:         0.00 K/s
Current DISK READ:       0.00 K/s | Current DISK WRITE:       0.00 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root          0.00 K    224.00 K  ?unavailable?  init splash
  382 be/4 root          0.00 K     92.00 K  ?unavailable?  dhcpcd -b -q
31533 be/4 systemd-      0.00 K      4.00 K  ?unavailable?  systemd-timesyncd

Nu nog de disk writes van de overgebleven 3 proberen te voorkomen.......

[ZuinigeRijder]

ZuinigeRijder schreef op vrijdag 19 augustus 2022 @ 11:43:
[...]
Nu nog de disk writes van de overgebleven 3 proberen te voorkomen.......

Een leuk tooltje gevonden om alle file access te tracen, fatrace. Hiermee kun je zien welke processen lezen/schrijven en welke files Dus uitermate geschikt om de overgebleven disk schrijfacties te achterhalen......hier de output van ongeveer tien minuten.....

code:

$ sudo fatrace -t --filter=W
13:03:35.805695 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:03:35.810194 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:03:35.814586 dhcpcd(382): CW /var/lib/dhcpcd/eth0.lease6
13:03:37.706775 systemd-timesyn(1278): CW /var/lib/systemd/timesync/clock
13:05:38.561764 cron(1280): CW (deleted)
13:06:17.288772 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:06:17.291398 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:06:17.294933 dhcpcd(382): CW /var/lib/dhcpcd/eth0.lease6
13:06:19.195522 systemd-timesyn(1341): CW /var/lib/systemd/timesync/clock
13:09:04.408889 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:09:04.411647 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:09:04.414952 dhcpcd(382): CW /var/lib/dhcpcd/eth0.lease6
13:09:06.299630 systemd-timesyn(1373): CW /var/lib/systemd/timesync/clock
13:10:38.102485 cron(1375): CW (deleted)
13:11:18.930852 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:11:18.933624 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:11:18.937113 dhcpcd(382): CW /var/lib/dhcpcd/eth0.lease6
13:11:20.831444 systemd-timesyn(1436): CW /var/lib/systemd/timesync/clock
13:13:30.160480 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:13:30.163069 dhcpcd(382): W /var/lib/dhcpcd/eth0.lease6
13:13:30.168714 dhcpcd(382): CW /var/lib/dhcpcd/eth0.lease6
13:13:33.690113 systemd-timesyn(1465): CW /var/lib/systemd/timesync/clock

maar eens kijken of ik van de schrijfacties van dhcpcd en timesync weg kan krijgen
En wat dat cron doet verder onderzoeken......

[ZuinigeRijder]

De disk writes van dhcpcd weg kunnen krijgen met de volgende commando's:

code:

$ wacht totdat dhcpcd logging is voorbijgekomen met sudo fatrace -t --filter=W (ander terminal window)
$ sudo -i
# mv /var/lib/dhcpcd /var/log/dhcpcd
# ln -s /var/log/dhcpcd /var/lib/dhcpcd
# cp -rp /var/log/dhcpcd/ /var/hdd.log/dhcpcd/
# logout

[synoniem]

Ik vraag me toch af of zoiets als quashfs waarbij je filesystem readonly is niet een meer structurele oplossing is. Zodra je wat nieuws installeert loop je weer de kans dat je weer nieuwe schrijfacties krijgt.

[Webgnome]

Maar wat is er mis met schrijf acties? Als je backups maakt dan heb je toch na een kaartjescrash toch zo een nieuwe opgezet? Of je koppelt het geheel aan een fatsoenlijk medium zoals een ssd schijf oid?

[ZuinigeRijder]

@Webgnome ik gebruik de oude Raspberry Pi nergens anders voor, dus als ik met eenvoudige wijzigingen het aantal schrijfacties kan terugbrengen, is al heel mooi om de SDHC kaart zo lang mogelijk te laten meegaan. Ondertussen leer ik weer wat En misschien anderen die meelezen ook Dus op zich is er niets mis met de schrijfacties, maar als ze niet nodig zijn......

@synoniem Bedoelde je squashfs? Heb jij daar ervaring mee?

Natuurlijk moet er ook geschreven kunnen worden, maar reboots rm dagelijkse backup en de ramdisk is wel iets wat ik wil hebben. Dus ik heb het aantal schrijf acties een heel stuk teruggebracht.

P.S. ik weet nu ook waar de volgende fatrace van komt:

code:

13:10:38.102485 cron(1375): CW (deleted)

Iedere 5 minuten wordt een SBFSpot cronjob uitgevoerd. Even tijdelijk uitgezet en deze meldingen komen niet meer. En ik denk dat het "disk write" van "init splash" daarbij opgeteld wordt. En dat de timeserver daemon "disk writes" nog de enige zijn (en opgeteld worden bij "init splash"). Nu nog even het script aanpassen dat SBFSpot gewoon tussen 5 en 22 blijft draaien met 5 minuten sleep ertussen i.p.v. elke 5 minuten een cronjob

[nero355]

ZuinigeRijder schreef op donderdag 18 augustus 2022 @ 14:09:
Heb voor 1,50 euro (50% kortingsweek op de al belachelijke lage prijs van 3 euro) bij de blokker een Philips SDHC kaartje gekocht van 16 GB.

En ik maar grofweg € 15 blijven betalen voor een fatsoenlijk Sandisk 32 GB microSDXC kaartje

Nu wil ik natuurlijk dat dit SDHC kaartje weer lang meegaat. Dus ik heb een aantal dingen gedaan zodat er minder (vaak) geschreven wordt naar de SDHC kaart.

Hoewel het natuurlijk allemaal heel leerzaam is wat je hebt gedaan blijft er toch altijd nog de vraag wat de kwaliteit is van dat Philips SDHC kaartje en hoe lang die mee zal gaan dus als je veel Logging doet dan zou een 2,5 inch USB HDD of SSD misschien niet eens een heel gek idee zijn zoals @Webgnome al voorstelde!

Vergeet ook niet dat een voeding/adapter door de tijd heen zal slijten dus misschien moet je eens kijken of die niet aan vervanging toe is
Zelfs de voeding in mijn PC vindt het na 8 a 9 jaar vaak wel mooi geweest en wil dan graag met pensioen!

[ZuinigeRijder]

@nero355 ik was al verbaasd dat zo een Raspberry Pi zo lang meegaat En de voeding gebruik ik de adapter van een HTC Touch Diamond. Die is dus al uit 2008 Jammer genoeg geen Windows Mobile meer en geen TouchLockPro, BattClock of andere Windows Mobile applicaties meer van mij.

Kan geen echte ervaringen vinden van het Philips kaartje, behalve bij de blokker zelf. Stoepgarantie

Tja, bij een stroomuitval of spontane reboot helpt het ook wanneer er weinig geschreven wordt, want dan wordt de kans kleiner dat het net gebeurt tijdens schrijven.

[aawe mwan]

ZuinigeRijder schreef op vrijdag 19 augustus 2022 @ 17:40:
Kan geen echte ervaringen vinden van het Philips kaartje, behalve bij de blokker zelf. Stoepgarantie

Wat ik in de beschrijving van dit specifieke kaartje (type fm16sd45b) mis, is het A1 kenmerk.

Een kaartje met A1 is sowieso altijd veel sneller in random access, wat je bijvoorbeeld goed merkt bij elke apt-get update / upgrade.

Kaartjes zonder A1 zijn in het algemeen gemaakt volgens een al vele jaren oud ontwerp/productieproces en destijds toen ze nieuw waren, is het ontwerp „geoptimaliseerd” voor bewaren van grote bestanden (foto's en films) die niet zo vaak overschreven hoeven te kunnen worden. Dan zeg ik het op een aardige manier.

Daarnaast kan je aan de foto niet zien welke fabriek dit geproduceerd heeft voor de Chinees die licentiehouder is van de merknaam „Philips” en dat kan ook zomaar veranderen.

[DaRk PoIsOn]

@nero355 @ZuinigeRijder

Niet geheel relevant aan de sd-kaartjes, maar ik heb bij de Primera een Philips usb stick gehaald (128GB). Daarnaast had ik nog een Sandisk Cruzer (128GB). Mijn Xigmanas server draait al 2,5 jaar op die Philips stick terwijl die Sandisk het al meerdere malen heeft begeven op mijn andere server met Xigmanas en een virtual machine met pihole en jellyfin.

[synoniem]

ZuinigeRijder schreef op vrijdag 19 augustus 2022 @ 15:35:


@synoniem Bedoelde je squashfs? Heb jij daar ervaring mee?

Ik heb in het verleden hier mee geëxperimenteerd maar ik laat mijn Pi's tegenwoordig vanaf het netwerk booten en draaien met tftp en nfs.

[ZuinigeRijder]

@aawe mwan ik ben me bewust dat een anderhalf euro SDHC kaartje mogelijk slechter is dan een duur kaartje. Maar is een beetje koffiedik kijken volgens @DaRk PoIsOn

Wat verbazend is, dat mijn oude Transcent 16 GB SDHC 10 kaart van 2013 dus 9 jaar meegegaan is, zonder dat ik zoiets als log2ram ingesteld had (want dat was er toen nog niet), dus heeft 9 jaar 24 uur per dag schrijfacties overleefd op Wheezy OS Maar misschien was het oude kaartje nog geen A1 en juist nog niet geoptimaliseerd voor grote bestanden en heeft het daarom langer uitgehouden

Vergeleken met het Philips kaartje was deze 4x trager voor het lezen (80 MB/s vs. 20 MB/s). Maar goed dat ik alleen het schrijven aan het optimaliseren ben

Ik ben al een heel eind met optimalisatie, dus misschien krijg ik die timeserver cache writes ook nog wel weg of niet dan is dat wat er over blijft aan regelmatige schrijfacties iedere aantal minuten

[aawe mwan]

ZuinigeRijder schreef op vrijdag 19 augustus 2022 @ 20:55:
was deze 4x trager voor het lezen (80 MB/s vs. 20 MB/s). Maar goed dat ik alleen het schrijven aan het optimaliseren ben

80 MB/s klopt natuurlijk sowieso niet, maar het zou wel leuk zijn om even te kijken hoe snel jouw kaartje écht is. Dat varieert van 0,21 MB/s tot 8,2 MB/s, zie: https://www.pidramble.com...s/microsd-cards#2-model-b

[ZuinigeRijder]

aawe mwan schreef op vrijdag 19 augustus 2022 @ 21:28:
[...]


80 MB/s klopt natuurlijk sowieso niet, maar het zou wel leuk zijn om even te kijken hoe snel jouw kaartje écht is. Dat varieert van 0,21 MB/s tot 8,2 MB/s, zie: https://www.pidramble.com...s/microsd-cards#2-model-b

Haha, mijn Raspberry Pi model 1 Model B+ staat er niet bij, minst krachtige in de lijst is Raspberry Pi 2 Model B, de opvolger van mijn oudje

Ik zal eens een benchmark doen van het Philips kaartje, bouwen duurt iets langer op mijn Pi

[ZuinigeRijder]

En hier de resultaten van de 16 GB Philips SDHC kaart op mijn Raspberry Pi 1 B+

code:

Running hdparm test...

/dev/mmcblk0:
 Timing buffered disk reads:  64 MB in  3.03 seconds =  21.12 MB/sec

Running dd test...

51200+0 records in
51200+0 records out
419430400 bytes (419 MB, 400 MiB) copied, 33.4515 s, 12.5 MB/s

Running iozone test...
        Iozone: Performance Test of File I/O
                Version $Revision: 3.492 $
                Compiled for 32 bit mode.
                Build: linux-arm

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                     Alexey Skidanov, Sudhir Kumar.

        Run began: Fri Aug 19 22:02:35 2022

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Command line used: ./iozone -e -I -a -s 100M -r 4k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     1897     2160     3857     3938     3361     2161

iozone test complete.

microSD card benchmark complete!

Samenvatting volgens mij:

hdparm buffered: 21.12 MB/s
dd write: 12.5 MB/s
4K rand read: 3361 KB/s = 3.28 MB/s
4K rand write: 2161 KB/s = 2.11 MB/s

Oftewel:
Philips 16 GB Ultra Speed (C10 80 MB/s) 21.12 MB/s 12.5 MB/s 3.28 MB/s 2.11 MB/s

Even vergelijken met andere 16 GB kaartjes:
SanDisk Ultra 16GB 17.73 MB/s 7.3 MB/s 5.34 MB/s 1.52 MB/s
Sony (C10 70MB/s) 16GB 15.38 MB/s 8.9 MB/s 2.47 MB/s 0.24 MB/s
Kingston (C10) 16GB 17.78 MB/s 9.0 MB/s 5.75 MB/s 0.21 MB/s

Valt het Philips kaartje nog mee voor anderhalve euro

Valt me op dat de schrijf snelheid beter is dan de anderen hier opgesomd. Laat ik nu nog maar weinig schrijven

[synoniem]

synoniem schreef op vrijdag 19 augustus 2022 @ 19:57:
[...]

Ik heb in het verleden hier mee geëxperimenteerd maar ik laat mijn Pi's tegenwoordig vanaf het netwerk booten en draaien met tftp en nfs.

Het kan nog eenvoudiger tegenwoordig kun je met raspi-config bij de performance opties kiezen voor het overlay filesystem.
Moet je wel van te voren bluetooth, hciuart en het dhsys-swapfile services uitschakelen.

[ZuinigeRijder]

Ter lering en vermaak, ik ben erachter waar het proces met pid 1 "init splash" de schrijfacties doet.

Met het commando:
$ sudo strace -t -p 1 -e trace=write,open,openat

en dan in de buurt van de write acties.....

code:

openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-timesyncd.service/cgroup.subtree_control", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 48
write(48, "-cpu\n", 5)                  = 5
write(48, "-io\n", 4)                   = 4
write(48, "-pids\n", 6)                 = 6
....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-timesyncd.service/pids.max", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 50
write(50, "415\n", 4)                   = 4
...
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-timesyncd.service/cgroup.procs", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 50
write(50, "5621\n", 5)                  = 
....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-rfkill.service/cgroup.subtree_control", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 35
write(35, "-cpu\n", 5)                  = 5
write(35, "-io\n", 4)                   = 4
write(35, "-pids\n", 6)                 = 6
....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-rfkill.service/pids.max", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 35
write(35, "415\n", 4)                   = 4
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-rfkill.service/cgroup.procs", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 35
write(35, "5936\n", 5)                  = 5
...
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/system-bthelper.slice/[e-mail]/cgroup.subtree_control", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 36
write(36, "-cpu\n", 5)                  = 5
write(36, "-io\n", 4)                   = 4
write(36, "-pids\n", 6)                 = 6
...
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/system-bthelper.slice/[e-mail]/pids.max", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 36
write(36, "415\n", 4)                   = 4
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/system-bthelper.slice/[e-mail]/cgroup.procs", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 36
write(36, "5945\n", 5)                  = 5
.....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/bluetooth.service/cgroup.subtree_control", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 36
write(36, "-cpu\n", 5)                  = 5
write(36, "-io\n", 4)                   = 4
write(36, "-pids\n", 6)                 = 6
.....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/bluetooth.service/pids.max", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 36
write(36, "415\n", 4)                   = 4
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/bluetooth.service/cgroup.procs", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 36
write(36, "5949\n", 5)                  = 5
....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-hostnamed.service/cgroup.subtree_control", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 35
write(35, "-cpu\n", 5)                  = 5
write(35, "-io\n", 4)                   = 4
write(35, "-pids\n", 6)                 = 6
....
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-hostnamed.service/pids.max", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 37
write(37, "415\n", 4)                   = 4
openat(AT_FDCWD, "/sys/fs/cgroup/system.slice/systemd-hostnamed.service/cgroup.procs", O_WRONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 42
write(42, "5951\n", 5)                  = 5
....

Oftewel alles onder /sys/fs/cgroup/system.slice wordt er geschreven. In 1 uur wordt er minder dan 1 MB geschreven.

De systemd-timesyncd schrijft creëert per timesynchronisatie een lege-file met de timestamp, namelijk /var/lib/systemd/timesync/clock.

Daarmee eindigt denk ik de optimalisatie van schrijf acties. Want 1 MB per uur, is 24 MB per dag, is ongeveer 9 GB per jaar. En het is een 16 GB kaartje. Dus wanneer het schijfje 100x herschreven kan worden, gaat het kaartje 100 jaar mee Ben natuurlijk wel vergeten mee te tellen dat log2ram dagelijks eenmaal /var/log doet synchroniseren met /var/hdd.log. Ook dat dagelijks synchroniseren kun je trouwens uitzetten, maar is ook niet zoveel data.

Journaling heb ik weer aangezet, want willen natuurlijk de kans zo klein mogelijk houden dat het file systeem corrupt raakt bij wegschrijven

Disabling journaling can reduce wear, it will also make your Pi more likely to face filesystem corruption in the event of a crash or power outage.

.

[ZuinigeRijder]

ZuinigeRijder schreef op zaterdag 20 augustus 2022 @ 16:30:
Ter lering en vermaak
...

Daarmee eindigt denk ik de optimalisatie van schrijf acties. Want 1 MB per uur, is 24 MB per dag, is ongeveer 9 GB per jaar. En het is een 16 GB kaartje. Dus wanneer het schijfje 100x herschreven kan worden, gaat het kaartje 100 jaar mee Ben natuurlijk wel vergeten mee te tellen dat log2ram dagelijks eenmaal /var/log doet synchroniseren met /var/hdd.log. Ook dat dagelijks synchroniseren kun je trouwens uitzetten, maar is ook niet zoveel data.

Toch mijn RaspBerry Pi nog wat verder op dieet kunnen zetten. Resultaat nog maar 100K schrijven per uur, dus mijn kaartje gaat nog 1000 jaar mee

Onnodige services gestopt/disabled aangezien ik geen Wifi gebruik, geen modem gebruik en geen printer services gebruik. Zie ook deze pagina. De volgende services gedisabled:

code:

sudo systemctl --type=service --state=running

sudo systemctl stop wpa_supplicant.service
sudo systemctl stop cups-browsed.service
sudo systemctl stop cups.service
sudo systemctl stop triggerhappy.service
sudo systemctl stop ModemManager.service
sudo systemctl stop avahi-daemon.service

sudo systemctl disable wpa_supplicant.service
sudo systemctl disable cups-browsed.service
sudo systemctl disable cups.service
sudo systemctl disable triggerhappy.service
sudo systemctl disable ModemManager.service
sudo systemctl disable avahi-daemon.service

En Wifi niet laden:

code:

sudo nano /etc/modprobe.d/raspi-blacklist.conf
# WiFi
blacklist brcmfmac
blacklist brcmutil

En aangezien systemd-timesyncd ook nog (nul-file) schreef op disk, overgestapt op ntp.

code:

sudo -i
systemctl stop systemd-timesyncd
systemctl disable systemd-timesyncd
apt-get install ntp
/etc/init.d/ntp stop
/etc/init.d/ntp start
logout

Ook nog de polling interval van ntp wat lager gezet.
# minpoll 10 # 1024 seconds ~ 17 minutes
# maxpoll 12 # 4096 seconds ~ 70 minutes

code:

sudo service ntp stop

sudo nano /etc/ntp.conf


pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
---> veranderen in
pool 0.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst
pool 1.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst
pool 2.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst
pool 3.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst

sudo service ntp start

En tot slot kwam ik erachter dat /tmp nog niet gemount was als tmpfs. Ook dit verandert.

code:

sudo nano /etc/fstab
tmpfs /tmp tmpfs defaults,noatime,nosuid,size=10m 0 0

mount -a
df -h

Ik had het probleem dat mijn externe bluetooth soms bleef hangen in combinatie met SBFSpot, dus deed ik die 1x per 5 minuten resetten. Dit heb ik veranderd in 1x per uur, dan wordt uitgevoerd:

code:

        sudo ./usbreset /dev/bus/usb/001/005 > /dev/null 2>&1
        sudo ./usbreset /dev/bus/usb/001/006 > /dev/null 2>&1
        sleep 10
        sudo service bluetooth restart > /dev/null 2>&1
        sleep 20
        lsusb > /dev/null 2>&1
        /usr/bin/hciconfig hci0 -a > /dev/null 2>&1

Voor diegene die geïnteresseerd zijn in usbreset.c die ik gebruik:

code:

/* usbreset -- send a USB port reset to a USB device
http://blog.brainmassage.co.uk/2012/12/raspberry-pi-usb-reset-code/
gcc usbreset.c -o usbreset
resetusb /dev/bus/usb/${dev}
*/

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>

#include <linux/usbdevice_fs.h>


int main(int argc, char **argv)
{
    const char *filename;
    int fd;
    int rc;

    if (argc != 2) {
        fprintf(stderr, "Usage: usbreset device-filename\n");
        return 1;
    }
    filename = argv[1];

    fd = open(filename, O_WRONLY);
    if (fd < 0) {
        perror("Error opening output file");
        return 1;
    }

    printf("Resetting USB device %s\n", filename);
    rc = ioctl(fd, USBDEVFS_RESET, 0);
    if (rc < 0) {
        perror("Error in ioctl");
        return 1;
    }
    printf("Reset successful\n");

    close(fd);
    return 0;
}

Na al dat diëten is nu mijn output van het filesysteem:

code:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  3.6G  9.9G  27% /
devtmpfs         87M     0   87M   0% /dev
tmpfs           215M     0  215M   0% /dev/shm
tmpfs            86M  976K   85M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            10M     0   10M   0% /tmp
/dev/mmcblk0p1  253M   50M  203M  20% /boot
log2ram          60M  9.7M   51M  17% /var/log
tmpfs            43M   20K   43M   1% /run/user/1000

Vrij geheugen:

code:

$ free -m
               total        used        free      shared  buff/cache   available
Mem:             429          72         211          10         145         296
Swap:             99           0          99

En mijn /var/log is minder dan 10M, merendeel is journal (7M), dus eenmaal per dag zal log2ram dit synchroniseren.

code:

 $ sudo du -h /var/log
0       /var/log/timesync
64K     /var/log/sbfspot.3
0       /var/log/runit/ssh
0       /var/log/runit
960K    /var/log/rick
0       /var/log/private
0       /var/log/ntpstats
24K     /var/log/lightdm
6.9M    /var/log/journal/[subdir]
6.9M    /var/log/journal
0       /var/log/hp/tmp
0       /var/log/hp
16K     /var/log/dhcpcd
28K     /var/log/cups
4.0K    /var/log/bluetooth/[mac]/cache
4.0K    /var/log/bluetooth/[mac]
4.0K    /var/log/bluetooth
96K     /var/log/apt
9.7M    /var/log

[Seafarer]

ZuinigeRijder schreef op zondag 21 augustus 2022 @ 14:23:
[...]


Toch mijn RaspBerry Pi nog wat verder op dieet kunnen zetten. Resultaat nog maar 100K schrijven per uur, dus mijn kaartje gaat nog 1000 jaar mee

Onnodige services gestopt/disabled aangezien ik geen Wifi gebruik, geen modem gebruik en geen printer services gebruik. Zie ook deze pagina. De volgende services gedisabled:

code:

sudo systemctl --type=service --state=running

sudo systemctl stop wpa_supplicant.service
sudo systemctl stop cups-browsed.service
sudo systemctl stop cups.service
sudo systemctl stop triggerhappy.service
sudo systemctl stop ModemManager.service
sudo systemctl stop avahi-daemon.service

sudo systemctl disable wpa_supplicant.service
sudo systemctl disable cups-browsed.service
sudo systemctl disable cups.service
sudo systemctl disable triggerhappy.service
sudo systemctl disable ModemManager.service
sudo systemctl disable avahi-daemon.service

En Wifi niet laden:

code:

sudo nano /etc/modprobe.d/raspi-blacklist.conf
# WiFi
blacklist brcmfmac
blacklist brcmutil

En aangezien systemd-timesyncd ook nog (nul-file) schreef op disk, overgestapt op ntp.

code:

sudo -i
systemctl stop systemd-timesyncd
systemctl disable systemd-timesyncd
apt-get install ntp
/etc/init.d/ntp stop
/etc/init.d/ntp start
logout

Ook nog de polling interval van ntp wat lager gezet.
# minpoll 10 # 1024 seconds ~ 17 minutes
# maxpoll 12 # 4096 seconds ~ 70 minutes

code:

sudo service ntp stop

sudo nano /etc/ntp.conf


pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst
---> veranderen in
pool 0.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst
pool 1.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst
pool 2.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst
pool 3.debian.pool.ntp.org minpoll 10 maxpoll 12 iburst

sudo service ntp start

En tot slot kwam ik erachter dat /tmp nog niet gemount was als tmpfs. Ook dit verandert.

code:

sudo nano /etc/fstab
tmpfs /tmp tmpfs defaults,noatime,nosuid,size=10m 0 0

mount -a
df -h

Ik had het probleem dat mijn externe bluetooth soms bleef hangen in combinatie met SBFSpot, dus deed ik die 1x per 5 minuten resetten. Dit heb ik veranderd in 1x per uur, dan wordt uitgevoerd:

code:

        sudo ./usbreset /dev/bus/usb/001/005 > /dev/null 2>&1
        sudo ./usbreset /dev/bus/usb/001/006 > /dev/null 2>&1
        sleep 10
        sudo service bluetooth restart > /dev/null 2>&1
        sleep 20
        lsusb > /dev/null 2>&1
        /usr/bin/hciconfig hci0 -a > /dev/null 2>&1

Voor diegene die geïnteresseerd zijn in usbreset.c die ik gebruik:

code:

/* usbreset -- send a USB port reset to a USB device
http://blog.brainmassage.co.uk/2012/12/raspberry-pi-usb-reset-code/
gcc usbreset.c -o usbreset
resetusb /dev/bus/usb/${dev}
*/

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>

#include <linux/usbdevice_fs.h>


int main(int argc, char **argv)
{
    const char *filename;
    int fd;
    int rc;

    if (argc != 2) {
        fprintf(stderr, "Usage: usbreset device-filename\n");
        return 1;
    }
    filename = argv[1];

    fd = open(filename, O_WRONLY);
    if (fd < 0) {
        perror("Error opening output file");
        return 1;
    }

    printf("Resetting USB device %s\n", filename);
    rc = ioctl(fd, USBDEVFS_RESET, 0);
    if (rc < 0) {
        perror("Error in ioctl");
        return 1;
    }
    printf("Reset successful\n");

    close(fd);
    return 0;
}

Na al dat diëten is nu mijn output van het filesysteem:

code:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  3.6G  9.9G  27% /
devtmpfs         87M     0   87M   0% /dev
tmpfs           215M     0  215M   0% /dev/shm
tmpfs            86M  976K   85M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs            10M     0   10M   0% /tmp
/dev/mmcblk0p1  253M   50M  203M  20% /boot
log2ram          60M  9.7M   51M  17% /var/log
tmpfs            43M   20K   43M   1% /run/user/1000

Vrij geheugen:

code:

$ free -m
               total        used        free      shared  buff/cache   available
Mem:             429          72         211          10         145         296
Swap:             99           0          99

En mijn /var/log is minder dan 10M, merendeel is journal (7M), dus eenmaal per dag zal log2ram dit synchroniseren.

code:

 $ sudo du -h /var/log
0       /var/log/timesync
64K     /var/log/sbfspot.3
0       /var/log/runit/ssh
0       /var/log/runit
960K    /var/log/rick
0       /var/log/private
0       /var/log/ntpstats
24K     /var/log/lightdm
6.9M    /var/log/journal/[subdir]
6.9M    /var/log/journal
0       /var/log/hp/tmp
0       /var/log/hp
16K     /var/log/dhcpcd
28K     /var/log/cups
4.0K    /var/log/bluetooth/[mac]/cache
4.0K    /var/log/bluetooth/[mac]
4.0K    /var/log/bluetooth
96K     /var/log/apt
9.7M    /var/log

Zo leerzaam.
Is het energie verbruik ook afgenomen tijdens het diëeteren?

[ZuinigeRijder]

Seafarer schreef op zondag 21 augustus 2022 @ 15:08:
[...]

Zo leerzaam.
Is het energie verbruik ook afgenomen tijdens het diëeteren?

Het doel was vooral minder disk schrijfacties. Maar denk dat het energieverbruik niet zal zijn afgenomen. Nu staat mijn Pi toch al uit zijn neus te eten, alleen om de 5 minuten even de data via bluetooth van de SMA omvormer halen en sturen naar PVOutput, via netwerk iedere minuut de data van de Solis omvormer ophalen en sturen naar PVOutput indien veranderd en het combineren per 5 minuten van de SMA en Solis PVOutput naar een ander PVOutput account. En dan komen daarbij de andere normale zaken van de pi, zoals tijd synchronisatie.

Maar voor energie verbruik vermindering kun je nog HDMI disablen (25mA), on board LED's disablen (5mA per LED) en accessoires minimaliseren (50+ mA, toetsenbord/muis uit USB)., Wifi uitzetten (10+ mA). Zie ook deze post.

code:

Raspberry Pi 2 B
Pi State    Power Consumption
Idle    220 mA (1.1 W)
ab -n 100 -c 10 (uncached)  450 mA (~2.3 W)
400% CPU load (stress --cpu 4)  400 mA (~2.1 W)

[ZuinigeRijder]

Ik ben nu nog op zoek waar /sys/fs/cgroup gemount wordt, in welke configuratiefile. Want eigenlijk wil ik deze ook naar een tmpfs filesysteem verhuizen. in /etc/fstab staat het niet. En het mount commando geeft:

code:

$ mount|grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

Wie heeft cgroup2 ook als tmpfs gemount? En waar/hoe is dit geconfigureerd? Kan dit zonder problemen?

EDIT: lijkt bij mij in /proc/mounts -> self/mounts te staan.....daarin staat:

code:

cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0

Maar ook in /etc/mtab (denk dat dit de configuratiefile is?)

code:

cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0

Kan dit (zonder problemen) aangepast worden naar (weet niet of die cgroup2 nog iets speciaals is)?
Mede omdat het mount commando laat zien: "cgroup2 on /sys/fs/cgroup type cgroup2"

code:

tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
of moet er staan
tmpfs /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
of moet er staan
cgroup2 /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0

[ Voor 52% gewijzigd door ZuinigeRijder op 21-08-2022 21:47 ]

[synoniem]

/sys is een virtual file system dus alleen de map sys (als mountpoint) staat fysiek op je sd-kaart.

[ZuinigeRijder]

synoniem schreef op maandag 22 augustus 2022 @ 00:48:
/sys is een virtual file system dus alleen de map sys (als mountpoint) staat fysiek op je sd-kaart.

Ah bedankt, weer wat geleerd. Zie ook deze post.

The virtual filesystems (/proc /dev /sys) are only in kernel memory. They are never externalised to the SDCard. You can write to them all day (where allowed) and it's just waggling a few ones and zeros in RAM.

Oftewel concluderend, /sys/fs/cgroup is in memory schrijven op het virtuele systeem, dus de writes beneden directory "/sys/fs/cgroup/system.slice/" zijn in memory en de WRITES die ik zie met

code:

sudo strace -t -p 1 -e trace=write,open,openat

zijn schrijfacties in RAM De vraag is natuurlijk wel wat "sudo iotop -aok" dan laat zien, wat zijn dat voor disk writes, teruggebracht naar ongeveer 100K in 1 uur, strace laat deze writes dan niet zien Zie ook deze post:

ZuinigeRijder in "Raspberry Pi: Ervaringen en Discussie - deel 2"

Trouwens, deze blog "Filesystem Basics with the Raspberry Pi" vond ik ook verhelderend m.b.t. boot proces.

In this tutorial we are going to look at the filesystems on the Raspberry Pi and how they are used to boot Linux from an SD card.

[ZuinigeRijder]

Hoe doen jullie trouwens een image backup maken van de SD card. Via Windows een kopie maken of op de Raspberry Pi zelf? Na al dat aanpassen wik ik een image backup maken. Ben deze post aan het volgen:

back-up-raspberry-pi-as-disk-image

code:

sudo mkdir /dev/myusb
sudo mount /dev/sda1 /dev/myusb

sudo dd if=/dev/mmcblk0 of=/dev/myusb/rickpi.img bs=4M

Eigenlijk had ik dus 2 goedkope SDHC Philips kaartjes van anderhalve euro moeten kopen, had ik eenvoudiger een backup kunnen maken.

[Dutchess_Nicole]

ZuinigeRijder schreef op maandag 22 augustus 2022 @ 12:21:
Hoe doen jullie trouwens een image backup maken van de SD card. Via Windows een kopie maken of op de Raspberry Pi zelf? Na al dat aanpassen wik ik een image backup maken. Ben deze post aan het volgen:

back-up-raspberry-pi-as-disk-image

code:

sudo mkdir /dev/myusb
sudo mount /dev/sda1 /dev/myusb

sudo dd if=/dev/mmcblk0 of=/dev/myusb/rickpi.img bs=4M

Eigenlijk had ik dus 2 goedkope SDHC Philips kaartjes van anderhalve euro moeten kopen, had ik eenvoudiger een backup kunnen maken.

Niet. Heel veel van wat er op die RPI staat is niet interressant. Ik ben alleen geinteresseerd in de configuratiebestanden en de home directories, min of meer.

Bash:

[Unit]
Description=Pihole Backup Script
After=network.target

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
User=root
Group=root

ProtectSystem=full

ProtectHome=false

PermissionsStartOnly=false

WorkingDirectory=/opt/backup

ExecStart=/bin/bash -l -c /opt/backup/backup.sh %i

KillSignal=SIGTERM

Restart=on-abort
RestartSec=5s

UMask=007

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=pihole-backup  [root]

Ik gebruik dus een service die elke nacht een backup trekt van de dingen die ik wel wil hebben.

Bash:

#!/bin/bash
LEVEL=0
TYPE="full"
EXCLUDE_TAG="--exclude-if-present exclude.tag"
INCLUDE_PATH=("/home" "/var" "/etc" "/lib")
BACKUP_SERVER="<backupserver.tld>"
BACKUP_USER="<backupuser>"
BACKUP_PATH="<backup/path>"
BANDWIDTH=100000
IDENTITYFILE=<ssh key>

FILENAME=backup-`hostname`-l${LEVEL}-`date +%F`
echo "Starting backup sequence"
# mkdir -p ${CACHE_PATH}/${LEVEL}

if [ 0 -eq $LEVEL ] ; then
  TYPE="full"
elif [ 1 -eq $LEVEL ] ; then
  TYPE="incr"
fi

for path in ${INCLUDE_PATH[@]}
do

  echo "--removing old sets for ${path}--"
  duplicity \
    remove-all-but-n-full 7 --force \
    --no-encryption \
    --ssh-options="-oIdentityFile=${IDENTITYFILE}" \
    sftp://${BACKUP_USER}@${BACKUP_SERVER}:${BACKUP_PATH}${path}

  echo "-- Backing up ${path} --"
  duplicity \
    --full-if-older-than 1W \
    --no-encryption \
    ${EXCLUDE_TAG} \
    --ssh-options="-oIdentityFile=${IDENTITYFILE}" \
    ${path} \
    sftp://${BACKUP_USER}@${BACKUP_SERVER}:${BACKUP_PATH}${path}
done

echo "done"
exit 0

Dit komt dus netjes op mijn NAS te staan, die vervolgens weer naar een offsite backup locatie synct.

[synoniem]

ZuinigeRijder schreef op maandag 22 augustus 2022 @ 12:21:
Hoe doen jullie trouwens een image backup maken van de SD card. Via Windows een kopie maken of op de Raspberry Pi zelf? Na al dat aanpassen wik ik een image backup maken. Ben deze post aan het volgen:

back-up-raspberry-pi-as-disk-image

code:

sudo mkdir /dev/myusb
sudo mount /dev/sda1 /dev/myusb

sudo dd if=/dev/mmcblk0 of=/dev/myusb/rickpi.img bs=4M

Eigenlijk had ik dus 2 goedkope SDHC Philips kaartjes van anderhalve euro moeten kopen, had ik eenvoudiger een backup kunnen maken.

Ik maak een backup met rsync:

code:

sudo rsync -aAXHSv /* /path/to/shared/folder --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found,/home/*/.gvfs}

En ik heb een diskimage van de sd-kaart achter de hand dus ik schrijf de gebruiksklare image naar een sd-kaart en kopieer alles terug met rsync.

[Freee!!]

Ik heb een backup script van het internet geplukt en daarna aan mijn smaak en wensen aangepast. Dat script loopt elke nacht met een cron-job (verschillende Pi's op verschillende tijden).

[alesandro_46]

Zoiets als dit:
automated-raspberry-pi-backup-complete-image

[Freee!!]

alesandro_46 schreef op maandag 22 augustus 2022 @ 15:33:
Zoiets als dit:
automated-raspberry-pi-backup-complete-image

Dat was inderdaad mijn basis.

[ZuinigeRijder]

Heb nu eenmalig een backup image gemaakt en daarnaast de paar bestanden in 2 directory's gekopieerd.
Image was initieel 14.4 GB, na pishrink was deze nog maar iets van 4 GB en na gzip nog maar 1.8 GB. Hoop dat het nooit nodig zal zijn

[maxnl]

ZuinigeRijder schreef op maandag 22 augustus 2022 @ 09:08:

code:

sudo strace -t -p 1 -e trace=write,open,openat

zijn schrijfacties in RAM De vraag is natuurlijk wel wat "sudo iotop -aok" dan laat zien, wat zijn dat voor disk writes, teruggebracht naar ongeveer 100K in 1 uur, strace laat deze writes dan niet zien

strace logt alleen maar de syscalls die je opgeeft.
Zijn wel meer syscalls dan alleen write() die kunnen schrijven.
Zoals writev, pwrite64, pwritev,

En als een applicatie een bestand naar geheugen mapt met mmap, zie je het daadwerkelijke schrijven al helemaal niet terug met strace.

[MdO82]

Ben benieuwd of iemand mij een tip kan geven
Ik heb PiVPN op mijn raspberry draaien.

Maar nu wilde ik een nieuwe user toevoegen.
Via het commando pivpn -qr kan je heel makkelijk van een mobiel device de qr-code scannen en de rest gaat bijna vanzelf.

Echter als ik dezelfde user wil gebruiken vanaf een laptop dan krijg ik een invulveld voor een wachtwoord.
Op zich logisch want users worden aangemaakt met een password.

Echter kan ik nergens het wachtwoord achterhalen

Ik had pivpn al een keer verwijderd en opnieuw geinstalleerd, maar nog steeds geen vraag voor een wachtwoord.

Zag voorbeelden dat als je een user aanmaakt dat je een password op kan geven, maar die optie krijg ik niet.

Iemand een hint waar ik moet zoeken ?

[Webgnome]

MdO82 schreef op vrijdag 26 augustus 2022 @ 14:34:
Ben benieuwd of iemand mij een tip kan geven
Ik heb PiVPN op mijn raspberry draaien.

Maar nu wilde ik een nieuwe user toevoegen.
Via het commando pivpn -qr kan je heel makkelijk van een mobiel device de qr-code scannen en de rest gaat bijna vanzelf.

Echter als ik dezelfde user wil gebruiken vanaf een laptop dan krijg ik een invulveld voor een wachtwoord.
Op zich logisch want users worden aangemaakt met een password.

Echter kan ik nergens het wachtwoord achterhalen

Ik had pivpn al een keer verwijderd en opnieuw geinstalleerd, maar nog steeds geen vraag voor een wachtwoord.

Zag voorbeelden dat als je een user aanmaakt dat je een password op kan geven, maar die optie krijg ik niet.

Iemand een hint waar ik moet zoeken ?

deze pagina al eens doorgelezen? https://docs.pivpn.io/openvpn/

[MdO82]

Webgnome schreef op vrijdag 26 augustus 2022 @ 14:39:
[...]


deze pagina al eens doorgelezen? https://docs.pivpn.io/openvpn/

Zojuist gedaan en niet wijzer geworden daarvan

[Webgnome]

laat maar..

[ Voor 95% gewijzigd door Webgnome op 26-08-2022 15:02 ]

[streamnl]

MdO82 schreef op vrijdag 26 augustus 2022 @ 14:34:
Ben benieuwd of iemand mij een tip kan geven
Ik heb PiVPN op mijn raspberry draaien.

Maar nu wilde ik een nieuwe user toevoegen.
Via het commando pivpn -qr kan je heel makkelijk van een mobiel device de qr-code scannen en de rest gaat bijna vanzelf.

Echter als ik dezelfde user wil gebruiken vanaf een laptop dan krijg ik een invulveld voor een wachtwoord.
Op zich logisch want users worden aangemaakt met een password.

Echter kan ik nergens het wachtwoord achterhalen

Ik had pivpn al een keer verwijderd en opnieuw geinstalleerd, maar nog steeds geen vraag voor een wachtwoord.

Zag voorbeelden dat als je een user aanmaakt dat je een password op kan geven, maar die optie krijg ik niet.

Iemand een hint waar ik moet zoeken ?

Kan je de .conf file downloaden via Cyberduck ofzo?
En die dan weer installeren op je laptop?

Lukt dat wel?

Ik meen dat ik het zelf ooit op deze manier had gedaan.

[synoniem]

MdO82 schreef op vrijdag 26 augustus 2022 @ 14:34:
Ben benieuwd of iemand mij een tip kan geven
Ik heb PiVPN op mijn raspberry draaien.

Maar nu wilde ik een nieuwe user toevoegen.
Via het commando pivpn -qr kan je heel makkelijk van een mobiel device de qr-code scannen en de rest gaat bijna vanzelf.

Echter als ik dezelfde user wil gebruiken vanaf een laptop dan krijg ik een invulveld voor een wachtwoord.
Op zich logisch want users worden aangemaakt met een password.

Echter kan ik nergens het wachtwoord achterhalen

Ik had pivpn al een keer verwijderd en opnieuw geinstalleerd, maar nog steeds geen vraag voor een wachtwoord.

Zag voorbeelden dat als je een user aanmaakt dat je een password op kan geven, maar die optie krijg ik niet.

Iemand een hint waar ik moet zoeken ?

Je krijgt alleen de vraag voor een password met pivpn -a
Als je het commando pivpn -qr gebruikt krijg je het wachtwoord van de gebruiker van het mobiele device dat de qrcode genereert. Tenminste dat is wat ik uit de documentatie haal.

[MdO82]

synoniem schreef op vrijdag 26 augustus 2022 @ 15:29:
[...]

Je krijgt alleen de vraag voor een password met pivpn -a
Als je het commando pivpn -qr gebruikt krijg je het wachtwoord van de gebruiker van het mobiele device dat de qrcode genereert. Tenminste dat is wat ik uit de documentatie haal.

Dat dacht ik dus ook bij -a maar dat is niet zo

pivpn -a
Enter a Name for the Client: test
::: Client Keys generated
::: Client config generated
::: Updated server config
::: WireGuard reloaded
======================================================================
::: Done! test.conf successfully created!
::: test.conf was copied to /home/pi/configs for easytransfer.
::: Please use this profile only on one device and create additional
::: profiles for other devices. You can also use pivpn -qr
::: to generate a QR Code you can scan with the mobile app.

bij pivpn -qr krijg ik verder ook niks te zien

streamnl schreef op vrijdag 26 augustus 2022 @ 15:06:
[...]


Kan je de .conf file downloaden via Cyberduck ofzo?
En die dan weer installeren op je laptop?

Lukt dat wel?

Ik meen dat ik het zelf ooit op deze manier had gedaan.

Ik gebruik zelf winscp maar als ik hem download en toe wil voegen aan OpenVPN Connect welke ik op mijn laptop gebruik dan krijg ik de vraag voor het wachtwoord.




Staat mij ergens bij dat je tijdens de installatie van PiVPN een masterkey/systemkey moest instellen, maar die optie kreeg ik niet.

Of wellicht ben ik in de war met openvpn

[ Voor 29% gewijzigd door MdO82 op 26-08-2022 15:49 ]

[streamnl]

MdO82 schreef op vrijdag 26 augustus 2022 @ 15:44:
[...]


Dat dacht ik dus ook bij -a maar dat is niet zo

pivpn -a
Enter a Name for the Client: test
::: Client Keys generated
::: Client config generated
::: Updated server config
::: WireGuard reloaded
======================================================================
::: Done! test.conf successfully created!
::: test.conf was copied to /home/pi/configs for easytransfer.
::: Please use this profile only on one device and create additional
::: profiles for other devices. You can also use pivpn -qr
::: to generate a QR Code you can scan with the mobile app.

bij pivpn -qr krijg ik verder ook niks te zien


[...]


Ik gebruik zelf winscp maar als ik hem download en toe wil voegen aan OpenVPN Connect welke ik op mijn laptop gebruik dan krijg ik de vraag voor het wachtwoord.

[Afbeelding]


Staat mij ergens bij dat je tijdens de installatie van PiVPN een masterkey/systemkey moest instellen, maar die optie kreeg ik niet.

Of wellicht ben ik in de war met openvpn

Tijdens het installeren, heb jij voor OpenVPN of voor WireGuard gekozen?
In het geval van het laatste, gebruik dan eens de client van WireGuard zelf. KLIK

Ik kan me niet herinneren dat het bij mij zo lastig ging.

Met OpenVPN heb ik geen ervaring mee.

[MdO82]

streamnl schreef op vrijdag 26 augustus 2022 @ 15:59:
[...]

Tijdens het installeren, heb jij voor OpenVPN of voor WireGuard gekozen?
In het geval van het laatste, gebruik dan eens de client van WireGuard zelf. KLIK

Ik kan me niet herinneren dat het bij mij zo lastig ging.

Met OpenVPN heb ik geen ervaring mee.

opgelost

Ik had in het verleden gebruik gemaakt van openvpn maar om een bepaalde reden overgestapt naar pivpn.
Nu wilde ik dus een pivpn profile gebruiken in openvpn op mijn laptop

Winguard staat ook op de laptop en profiel geïnstalleerd. gelijk verbinding
zat gewoon verkeerd te kijken en de oorzaak te zoeken bij de pi ipv de laptop

[Freee!!]

ZuinigeRijder schreef op dinsdag 23 augustus 2022 @ 10:51:
Heb nu eenmalig een backup image gemaakt en daarnaast de paar bestanden in 2 directory's gekopieerd.
Image was initieel 14.4 GB, na pishrink was deze nog maar iets van 4 GB en na gzip nog maar 1.8 GB. Hoop dat het nooit nodig zal zijn

PiShrink is inderdaad heel fijn.

[nero355]

MdO82 schreef op vrijdag 26 augustus 2022 @ 14:34:
Ik heb PiVPN op mijn raspberry draaien.

Maar nu wilde ik een nieuwe user toevoegen.
Via het commando pivpn -qr kan je heel makkelijk van een mobiel device de qr-code scannen en de rest gaat bijna vanzelf.

Echter als ik dezelfde user wil gebruiken vanaf een laptop dan krijg ik een invulveld voor een wachtwoord.
Op zich logisch want users worden aangemaakt met een password.

NOFI, maar ehh... jouw output geeft je al de oplossing :

MdO82 schreef op vrijdag 26 augustus 2022 @ 15:44:

pivpn -a
Enter a Name for the Client: test
::: Client Keys generated
::: Client config generated
::: Updated server config
::: WireGuard reloaded
======================================================================
::: Please use this profile only on one device and create additional
::: profiles for other devices.

Ondertussen gelukkig opgelost, maar toch...

[MdO82]

nero355 schreef op vrijdag 26 augustus 2022 @ 16:20:
[...]

NOFI, maar ehh... jouw output geeft je al de oplossing :

[...]



Ondertussen gelukkig opgelost, maar toch...

En dan gewoon niet zien terwijl het er dus inderdaad staat

[Webgnome]

Hi,

misschien weten jullie dit. Ik heb zojuist een een nieuwe docker container gestart op mijn rpi 3. So far so good. Nu heb ik de interne poort 80 gemapped naar de externe poort 8081. Daarnaast heb ik op deze rpi ook ufw staan. Daar heb ik poort 8081 nog niet open gezet. Maar als ik vervolgens naar ipadres:8081 ga dan is die poort toch open en bereikbaar? Output van sudo ufw status:

code:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
DNS                        ALLOW       Anywhere
67/udp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
8080/tcp                   ALLOW       Anywhere
8200/tcp                   ALLOW       Anywhere
1900/udp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
DNS (v6)                   ALLOW       Anywhere (v6)
67/udp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
8080/tcp (v6)              ALLOW       Anywhere (v6)
8200/tcp (v6)              ALLOW       Anywhere (v6)
1900/udp (v6)              ALLOW       Anywhere (v6)

iemand een idee hoe dit kan?

[Airw0lf]

Webgnome schreef op zaterdag 27 augustus 2022 @ 07:18:
Hi,

misschien weten jullie dit. Ik heb zojuist een een nieuwe docker container gestart op mijn rpi 3. So far so good. Nu heb ik de interne poort 80 gemapped naar de externe poort 8081. Daarnaast heb ik op deze rpi ook ufw staan. Daar heb ik poort 8081 nog niet open gezet. Maar als ik vervolgens naar ipadres:8081 ga dan is die poort toch open en bereikbaar? Output van sudo ufw status:

code:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
DNS                        ALLOW       Anywhere
67/udp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
8080/tcp                   ALLOW       Anywhere
8200/tcp                   ALLOW       Anywhere
1900/udp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
DNS (v6)                   ALLOW       Anywhere (v6)
67/udp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
8080/tcp (v6)              ALLOW       Anywhere (v6)
8200/tcp (v6)              ALLOW       Anywhere (v6)
1900/udp (v6)              ALLOW       Anywhere (v6)

iemand een idee hoe dit kan?

Hoe heb je die mapping gemaakt?
Welke netwerken "leven" er allemaal?

[Webgnome]

Airw0lf schreef op zaterdag 27 augustus 2022 @ 07:54:
[...]


Hoe heb je die mapping gemaakt?
Welke netwerken "leven" er allemaal?

code:

services:
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    command: '--default-authentication-plugin=mysql_native_password'
    volumes:
      -  /mnt/ssd/docker/data/blog/mysql:/var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
  wordpress:
    image: wordpress:latest
    ports:
      - 8081:80
    restart: always
    depends_on:
      - db
    volumes:
      -  /mnt/ssd/docker/data/blog/www:/var/www/html
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress

De code van de compose file van die specifieke container. Verder draait er niets op 8081. Het gaat dan dus ook om dat ik toch bij die container kan terwijl UFW aan staat en die poort er niet tussen staat. Als ik vervolgens docker ps uitvoer krijg ik dat ook te zien:

code:

CONTAINER ID   IMAGE                  COMMAND                  CREATED          STATUS          PORTS                                                          NAMES
b0ff1b89519c   wordpress:latest       "docker-entrypoint.s…"   49 minutes ago   Up 48 minutes   0.0.0.0:8081->80/tcp, :::8081->80/tcp                          config-wordpress-1
d267744f039f   mariadb:10.6.4-focal   "docker-entrypoint.s…"   49 minutes ago   Up 49 minutes   3306/tcp                                                       config-db-1
1210b48f2170   php:8.1.0-apache       "docker-php-entrypoi…"   3 weeks ago      Up 3 weeks      80/tcp                                                         config-web-1
6554e94e16a0   domoticz/domoticz      "docker-entrypoint.s…"   3 months ago     Up 3 weeks      443/tcp, 6144/tcp, 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp   domoticz

[ Voor 26% gewijzigd door Webgnome op 27-08-2022 07:59 ]

[Airw0lf]

@Webgnome en draaien die containers met het bridge-netwerk? Of die van de host? Of nog iets anders (en wat)?

[Verwijderd]

Goedemorgen allemaal!

Ik heb onlangs een raspberry pi 4B gekocht voor pihole en pivpn. Ik heb een synology ds918+ 16gb ram ernaast waar ik alles eerst op wou doen maar op 1 of andere manier wou de vpn niet pihole gebruiken als ik met mijn mobiel ergens anders ben. Dit is nu dus opgelost door een nieuwe pi 4b te kopen en alles netjes te installeren.

Ik heb alleen nu 2 vragen.

Hoe kan ik de QR code van wireguard wat hij mij liet zien in die terminal achtige omgeving opslaan?

Ik heb ze al gescand met mijn mobiel en alles is erop geconnect maar ik wil de qr als backups hebben voor het geval dat. Ik kon vroeger op de macbook een deel van de scherm selecteren en een screenshot maken.

Is dit mogelijk op de raspberry pi os?

Vraag 2 is. Ik heb een ziggo max abonnement (annerveenschekanaal, wij hebben nog geen giganet) en af en toe heb ik dat bij bijvoorbeeld amazon prime video het geluid heel even er tussen uit klapt.

Ik las dat je bij pihole de dns naar die van ziggo moet veranderen en niet die van Google of open dns etc moet gebruiken om dit tegen te gaan wat ik ook braaf heb gedaan in pihole.

Dit haalde al veel problemen weg
Ik heb nu een 1 meter ethernetkabel categorie 5e tussen de raspberry en router. Als ik een categorie 6 kabel gebruik zou dit dan het laatste beetje problematiek eruit halen?

Mijn router is een synology rt2600ac

Aansluiting is als volgt:

Ziggo coaxkabel-->1.5m-->ziggo modem in bridge modus-->1.5m categorie 6 kabel-->synology router-->poort 1 en 2 categorie 6 kabel-->synology ds918+-->poort 3 categorie 5e kabel-->raspberry pi 4b 8gb fan kit edition met alleen raspberry pi os 64bit pivpn en pi hole en vnc (teamviewer server)-->poort 4--> categorie 6 kabel-->Philips hue bridge-->2 wireless accespoints van synology (mr2200ac) beide doen 3 streepjes qua verbinding.

Accespoints snelheid is dus gestoord snel. De televisie zit bedraad op 1 van de Accespoints (ook categorie 6 kabel)

Ik gebruik in pihole alleen de dbsl ad list van een medetweaker (via Google gevonden) en dan (lightswitch5 heet die geloof ik) adlist die op avoidthehack.com staan. Google amp ads laat ik door omdat Google home hub het niet lekker deed en google home zelf soms ook problemen gaf.

Van lightswitch5 gebruik ik:
de Facebook instagram ad
Ads&tracking
Dating
Hate&junk

In de router heb Ik de dns handmatig veranderd naar de ip van pihole. Ip6 staat uit. Alles werkt gewoon alleen dat laatste beetje lag wil ik eruit hebben.

Zou het kunnen zijn dat de 5e kabel mij nu nog bottleneckt?

Of is het toch raadzaam dietpi te gebruiken ipv raspberry pi os die ik via de imager heb geflashed op de micro sd?

Micro sd kaart is een samsung evo pro 128gb.

Wie o wie heeft het gouden antwoord erop?

[ Voor 11% gewijzigd door Verwijderd op 27-08-2022 10:33 ]

[Webgnome]

Airw0lf schreef op zaterdag 27 augustus 2022 @ 08:29:
@Webgnome en draaien die containers met het bridge-netwerk? Of die van de host? Of nog iets anders (en wat)?

die draaien 'standaard' oftewel niets speciaals ingesteld. Maar ik snap even niet wat dit te maken heeft met dat ufw de poort niet blokkeert?

[synoniem]

Docker gebruikt iptables om zijn verkeer tussen containers te regelen en dat sluit niet aan op de simpelere ufw interface. Dat is aan te passen maar niet heel eenvoudig maar zijn tooltjes voor. Meer uitleg hier https://www.howtogeek.com...cker-with-a-ufw-firewall/

[Webgnome]

synoniem schreef op zaterdag 27 augustus 2022 @ 12:22:
Docker gebruikt iptables om zijn verkeer tussen containers te regelen en dat sluit niet aan op de simpelere ufw interface. Dat is aan te passen maar niet heel eenvoudig maar zijn tooltjes voor. Meer uitleg hier https://www.howtogeek.com...cker-with-a-ufw-firewall/

Thanks. Dat wist ik niet. Ik ga de link eens bestuderen. Ik dacht altijd dat het juist de bedoeling van docker was om dingen makkelijker te maken. Maar blijkbaar toch ook weer niet.

[Airw0lf]

Webgnome schreef op zaterdag 27 augustus 2022 @ 12:10:
[...]

die draaien 'standaard' oftewel niets speciaals ingesteld. Maar ik snap even niet wat dit te maken heeft met dat ufw de poort niet blokkeert?

Precies dat.

Met de standaard bridge interface werkt het net wat anders dan met een "eigen" gemaakt bridge interface; laat staan een mac-vlan al dan niet i.c.m. promisc mode en gewone 802.1q vlans.

Dat wilde ik even zeker stellen voor deze suggestie:
https://github.com/chaifeng/ufw-docker

Maar komt op hetzelfde neer als de reactie van @synoniem.

[nero355]

Webgnome schreef op zaterdag 27 augustus 2022 @ 07:18:
misschien weten jullie dit. Ik heb zojuist een een nieuwe docker container gestart op mijn rpi 3. So far so good. Nu heb ik de interne poort 80 gemapped naar de externe poort 8081. Daarnaast heb ik op deze rpi ook ufw staan. Daar heb ik poort 8081 nog niet open gezet. Maar als ik vervolgens naar ipadres:8081 ga dan is die poort toch open en bereikbaar? Output van sudo ufw status:

code:

sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
DNS                        ALLOW       Anywhere
67/udp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
8080/tcp                   ALLOW       Anywhere
8200/tcp                   ALLOW       Anywhere
1900/udp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
DNS (v6)                   ALLOW       Anywhere (v6)
67/udp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
8080/tcp (v6)              ALLOW       Anywhere (v6)
8200/tcp (v6)              ALLOW       Anywhere (v6)
1900/udp (v6)              ALLOW       Anywhere (v6)

iemand een idee hoe dit kan?

Waarom staat hier geen BLOCK ALL aan het eind voor zowel IPv4 als IPv6 of gaat UFW ervan uit dat je weet dat die er sowieso is en dat dus niet weergeeft

IPtables doet ook geloof ik en als die twee aan elkaar gekoppeld zijn dan zou dat redelijk logisch zijn

Webgnome schreef op zaterdag 27 augustus 2022 @ 07:58:
De code van de compose file van die specifieke container. Verder draait er niets op 8081. Het gaat dan dus ook om dat ik toch bij die container kan terwijl UFW aan staat en die poort er niet tussen staat. Als ik vervolgens docker ps uitvoer krijg ik dat ook te zien:

code:

b0ff1b89519c   wordpress:latest   0.0.0.0:8081->80/tcp, :::8081->80/tcp

Ben ik gek of wordt daar voor IPv4 poort 8081 naar 80 gemapt en vervolgens voor IPv6 poort 8081 naar 80 gemapt

Verwijderd schreef op zaterdag 27 augustus 2022 @ 10:23:
Hoe kan ik de QR code van wireguard wat hij mij liet zien in die terminal achtige omgeving opslaan?

Door een screenshot te maken van je SSH sessie of zoiets te doen :

<willekeurig commando> >> bestandsnaam.txt 

Als je dan bijvoorbeeld zoiets doet :

ping -help >> AllePingOpties.txt 

en vervolgens dit doet :

cat AllePingOpties.txt 

Dan krijg je dit te zien :

Usage
  ping [options] <destination>

Options:
  <destination>      dns name or ip address
  -a                 use audible ping
  -A                 use adaptive ping
  -B                 sticky source address
  -c <count>         stop after <count> replies
  -D                 print timestamps
  -d                 use SO_DEBUG socket option
  -f                 flood ping
  -h                 print help and exit
  -I <interface>     either interface name or address
  -i <interval>      seconds between sending each packet
  -L                 suppress loopback of multicast packets
  -l <preload>       send <preload> number of packages while waiting replies
  -m <mark>          tag the packets going out
  -M <pmtud opt>     define mtu discovery, can be one of <do|dont|want>
  -n                 no dns name resolution
  -O                 report outstanding replies
  -p <pattern>       contents of padding byte
  -q                 quiet output
  -Q <tclass>        use quality of service <tclass> bits
  -s <size>          use <size> as number of data bytes to be sent
  -S <size>          use <size> as SO_SNDBUF socket option value
  -t <ttl>           define time to live
  -U                 print user-to-user latency
  -v                 verbose output
  -V                 print version and exit
  -w <deadline>      reply wait <deadline> in seconds
  -W <timeout>       time to wait for response

IPv4 options:
  -4                 use IPv4
  -b                 allow pinging broadcast
  -R                 record route
  -T <timestamp>     define timestamp, can be one of <tsonly|tsandaddr|tsprespec>

IPv6 options:
  -6                 use IPv6
  -F <flowlabel>     define flow label, default is random
  -N <nodeinfo opt>  use icmp6 node info query, try <help> as argument

For more details see ping(8).

Ik heb ze al gescand met mijn mobiel en alles is erop geconnect maar ik wil de qr als backups hebben voor het geval dat. Ik kon vroeger op de macbook een deel van de scherm selecteren en een screenshot maken.

Is dit mogelijk op de raspberry pi os?

Je draait een volledige Desktop erop dus ?!

Dan zou dat mogelijk kunnen zijn op het moment dat je op de PrintScreen knop op je toetsenbord ramt!

Spectacle onder KDE heeft in ieder geval die optie...

Ik heb een ziggo max abonnement (annerveenschekanaal, wij hebben nog geen giganet) en af en toe heb ik dat bij bijvoorbeeld amazon prime video het geluid heel even er tussen uit klapt.

IMHO moet je dat in je Ziggo verbinding zoeken of de manier waarop het apparaat waarmee je streamt is verbonden of zelfs eventuele kleine HDMI Handshake problemen en heeft het niks met Pi-Hole te maken!

Ik heb nu een 1 meter ethernetkabel categorie 5e tussen de raspberry en router. Als ik een categorie 6 kabel gebruik zou dit dan het laatste beetje problematiek eruit halen?

IMHO irrelevant, tenzij de kabel brak is geworden of de connectoren die erop zitten

Mijn router is een synology rt2600ac

Ik heb daar weleens een hope nare dingen over gelezen, maar waar dat mee te maken had weet ik niet meer...

Check eens of je firmware up-to-date is of misschien juist het beste een bepaalde versie moet zijn!

2 wireless accespoints van synology (mr2200ac) beide doen 3 streepjes qua verbinding.

Check ook eens of die up-to-date zijn en zo...

De televisie zit bedraad op 1 van de Accespoints (ook categorie 6 kabel)

Ik ken het specifieke model niet, maar je hebt kans dat het niet slim is om de boel zo aan te sluiten!

Reden : Als de poort van de Accesspoint en de poort waarop de TV aan de Accesspoint hangt een simpele Bridge zijn dan ontvangt je TV dus ook al het verkeer dat naar/over de Accesspoint heen gaat...

Ik gebruik in pihole alleen de dbsl ad list van een medetweaker (via Google gevonden) en dan (lightswitch5 heet die geloof ik) adlist die op avoidthehack.com staan. Google amp ads laat ik door omdat Google home hub het niet lekker deed en google home zelf soms ook problemen gaf.

Gooi die spyware meuk eens uit je huis! Dan kan je alle ads gewoon blokkeren!

Van lightswitch5 gebruik ik:
de Facebook instagram ad
Ads&tracking
Dating
Hate&junk

Ken ik verder niet dus je zou als test die meuk eens eruit kunnen gooien voor een tijdje...??

Zou het kunnen zijn dat de 5e kabel mij nu nog bottleneckt?

Of is het toch raadzaam dietpi te gebruiken ipv raspberry pi os die ik via de imager heb geflashed op de micro sd?

Allemaal onzin IMHO

[Webgnome]

nero355 schreef op zaterdag 27 augustus 2022 @ 14:15:
[...]

Waarom staat hier geen BLOCK ALL aan het eind voor zowel IPv4 als IPv6 of gaat UFW ervan uit dat je weet dat die er sowieso is en dat dus niet weergeeft

IPtables doet ook geloof ik en als die twee aan elkaar gekoppeld zijn dan zou dat redelijk logisch zijn

Geen idee. Dat heeft denk ik te maken met docker die er doorheen fietst ?

nero355 schreef op zaterdag 27 augustus 2022 @ 14:15:
[...]

Ben ik gek of wordt daar voor IPv4 poort 8081 naar 80 gemapt en vervolgens voor IPv6 poort 8081 naar 80 gemapt

Aangezien ik meerdere containers heb die allemaal poort 80 gebruiken moet ik naar buiten toe wel aangeven dat ze naar 8081 mappen omdat je anders gezeik krijgt met dubbele poorten. Standaard netwerk kennis dacht ik toch?

[sweetdude]

Verwijderd schreef op zaterdag 27 augustus 2022 @ 10:23:
Goedemorgen allemaal!

Ik heb onlangs een raspberry pi 4B gekocht voor pihole en pivpn. Ik heb een synology ds918+ 16gb ram ernaast waar ik alles eerst op wou doen maar op 1 of andere manier wou de vpn niet pihole gebruiken als ik met mijn mobiel ergens anders ben. Dit is nu dus opgelost door een nieuwe pi 4b te kopen en alles netjes te installeren.

Ik heb alleen nu 2 vragen.

Hoe kan ik de QR code van wireguard wat hij mij liet zien in die terminal achtige omgeving opslaan?

Ik heb ze al gescand met mijn mobiel en alles is erop geconnect maar ik wil de qr als backups hebben voor het geval dat. Ik kon vroeger op de macbook een deel van de scherm selecteren en een screenshot maken.

Is dit mogelijk op de raspberry pi os?

Vraag 2 is. Ik heb een ziggo max abonnement (annerveenschekanaal, wij hebben nog geen giganet) en af en toe heb ik dat bij bijvoorbeeld amazon prime video het geluid heel even er tussen uit klapt.

Ik las dat je bij pihole de dns naar die van ziggo moet veranderen en niet die van Google of open dns etc moet gebruiken om dit tegen te gaan wat ik ook braaf heb gedaan in pihole.

Dit haalde al veel problemen weg
Ik heb nu een 1 meter ethernetkabel categorie 5e tussen de raspberry en router. Als ik een categorie 6 kabel gebruik zou dit dan het laatste beetje problematiek eruit halen?

Mijn router is een synology rt2600ac

Aansluiting is als volgt:

Ziggo coaxkabel-->1.5m-->ziggo modem in bridge modus-->1.5m categorie 6 kabel-->synology router-->poort 1 en 2 categorie 6 kabel-->synology ds918+-->poort 3 categorie 5e kabel-->raspberry pi 4b 8gb fan kit edition met alleen raspberry pi os 64bit pivpn en pi hole en vnc (teamviewer server)-->poort 4--> categorie 6 kabel-->Philips hue bridge-->2 wireless accespoints van synology (mr2200ac) beide doen 3 streepjes qua verbinding.

Accespoints snelheid is dus gestoord snel. De televisie zit bedraad op 1 van de Accespoints (ook categorie 6 kabel)

Ik gebruik in pihole alleen de dbsl ad list van een medetweaker (via Google gevonden) en dan (lightswitch5 heet die geloof ik) adlist die op avoidthehack.com staan. Google amp ads laat ik door omdat Google home hub het niet lekker deed en google home zelf soms ook problemen gaf.

Van lightswitch5 gebruik ik:
de Facebook instagram ad
Ads&tracking
Dating
Hate&junk

In de router heb Ik de dns handmatig veranderd naar de ip van pihole. Ip6 staat uit. Alles werkt gewoon alleen dat laatste beetje lag wil ik eruit hebben.

Zou het kunnen zijn dat de 5e kabel mij nu nog bottleneckt?

Of is het toch raadzaam dietpi te gebruiken ipv raspberry pi os die ik via de imager heb geflashed op de micro sd?

Micro sd kaart is een samsung evo pro 128gb.

Wie o wie heeft het gouden antwoord erop?

Ik denk dat deze beter naar het PiHole draadje verplaatst kan worden maar, hieronder toch even wat reacties die vragen bij mij oproepen...

Hoe kan ik de QR code van wireguard wat hij mij liet zien in die terminal achtige omgeving opslaan?

Ik heb ze al gescand met mijn mobiel en alles is erop geconnect maar ik wil de qr als backups hebben voor het geval dat. Ik kon vroeger op de macbook een deel van de scherm selecteren en een screenshot maken.

je hebt VNC erop staat, maak een connectie erna toe vanaf een andere pc en maak een screenshot net zoals je met je macbook deed.

Vraag 2 is. Ik heb een ziggo max abonnement (annerveenschekanaal, wij hebben nog geen giganet) en af en toe heb ik dat bij bijvoorbeeld amazon prime video het geluid heel even er tussen uit klapt.

Ik las dat je bij pihole de dns naar die van ziggo moet veranderen en niet die van Google of open dns etc moet gebruiken om dit tegen te gaan wat ik ook braaf heb gedaan in pihole.

Dit is volgens mij iets met klokken en klepels. Je DNS server kan niet de oorzaak zijn dat het geluid out of sync gaat. in principe wordt er in de amazon app net zoals in viaplay of netflix video en geluid gebuffert

Mede tweaker @jpgview heeft een geweldige handleiding gemaakt om zowel PiHole met PiVPN met wireguard en unbound als upstreamDNS resolver in elkaar gesleuteld te krijgen.

De televisie zit bedraad op 1 van de Accespoints

deze snap ik niet helemaal, waarom bedraad op 1 van de accespoints? Ik haal namelijk niet uit je verhaal of de accespoints ook bedraad zijn aangesloten op je synology router.
Daarbij hebben de meeste tv's geen GBit netwerkpoort maar "Gbit capabale" effectief zijn die maar 100Mbit. de tv via wireless aansluiten geeft hem een hogere snelheid.

[nero355]

Webgnome schreef op zaterdag 27 augustus 2022 @ 14:26:
Geen idee. Dat heeft denk ik te maken met docker die er doorheen fietst ?

Was meer een vraag vanuit mijn kant

Aangezien ik meerdere containers heb die allemaal poort 80 gebruiken moet ik naar buiten toe wel aangeven dat ze naar 8081 mappen omdat je anders gezeik krijgt met dubbele poorten.
Standaard netwerk kennis dacht ik toch?

Snap ik, maar waarom staat het zo weergegeven Of was het jouw eigen keuze om IPv6 te laten voor wat het is of zo ??

sweetdude schreef op zaterdag 27 augustus 2022 @ 14:45:
deze snap ik niet helemaal, waarom bedraad op 1 van de accespoints?

Omdat geen Switch bij het TV meubel gok ik

Ik haal namelijk niet uit je verhaal of de accespoints ook bedraad zijn aangesloten op je synology router.

Dat is als het goed is wel zo, want dat haal ik wel uit zijn verhaal

Daarbij hebben de meeste tv's geen GBit netwerkpoort maar "Gbit capabale" effectief zijn die maar 100Mbit. de tv via wireless aansluiten geeft hem een hogere snelheid.

100 Mbps is meer dan genoeg om gebruik te maken van al die streamingdiensten dus daar mag het niet aan liggen!

Draadloos kan je eerder problemen opleveren dan dat het ze oplost, want veel makkelijker te storen en zo...

[Verwijderd]

Dank jullie wel voor de reacties!
Mijn televisie is een lg sk8500 plb zo uit mijn hoofd. Dat ding heeft brakke wifi. Toen ik wifi aanzette switchte hij constant heen en weer van router naar accespoint en vice versa waardoor netflix etc hele tijd ging bufferen en ik ongelukkige kinderen kreeg.

Voordeel was wel dat ik niet paw patrol meer zag en hoorde :-)

Toen ik het bedraad op de accespoint aansloot was het probleem weg.

Accespoint staat op de televisie meubel en de router, nas, hue bridge, elro k1 connector etc in de meterkast.

Accespoints zijn inderdaad draadloos aangesloten naar de router toe ivm sleuven in de muur frezen of gaten boren etc.

Daarnaast heb ik erg veel wifi spul van slimme thermostaat tot aan ip camera's, wasmachine en slimme koelkast etc 2 xboxxen, ps4 pro, ps3, apple tv telefoons, tablet etc etc etc.

Via wifi zitten er sowieso 80 apparaten op :-)

Router en accespoints draaien 1.3 laatste update.
Ik kan de hdmi kabels wel even switchen kijken of dat problemen geeft aangezien de televisie via hdmi arc geluid aan de soundbar geeft.

Zijn allemaal wel goldplated 1.4kabels van bol.com @Airw0lf weet dat ik er fan van ben :-)

Over de screenshot maken, slim idee! Ga ik direct doen!

Over dat ziggo dns in pihole zoek ik even op. Ik las het vannacht om 2.30 dus ik moet even in mijn geschiedenis zoeken :-)

[ Voor 22% gewijzigd door Verwijderd op 27-08-2022 16:53 ]

[nero355]

Verwijderd schreef op zaterdag 27 augustus 2022 @ 16:44:
Accespoints zijn inderdaad draadloos aangesloten naar de router toe ivm sleuven in de muur frezen of gaten boren etc.

Heb je geen telefoonaansluitingen die je kan hergebruiken

Bij mij zaten er prachtige CAT5e kabels achter de WCD's

Daarnaast heb ik erg veel wifi spul van slimme thermostaat tot aan ip camera's, wasmachine en slimme koelkast etc 2 xboxxen, ps4 pro, ps3, apple tv telefoons, tablet etc etc etc.

Via wifi zitten er sowieso 80 apparaten op :-)

Als dat allemaal over die eene "draadloze backbone" heen moet of daarvan bandbreedte/airtime opsnoept dan kan het allemaal een beetje teveel worden hé!

[Verwijderd]

nero355 schreef op zaterdag 27 augustus 2022 @ 17:58:
[...]

Heb je geen telefoonaansluitingen die je kan hergebruiken

Bij mij zaten er prachtige CAT5e kabels achter de WCD's


[...]

Als dat allemaal over die eene "draadloze backbone" heen moet of daarvan bandbreedte/airtime opsnoept dan kan het allemaal een beetje teveel worden hé!

Dat laatste dacht ik dus ook al daarom heb ik de router en accespoints van synology zodat ik bv in kan stellen dat de wasmachine de accespoint in de bijkeuken moet gebruiken en de oprit camera op de router moet zitten.

[nero355]

Verwijderd schreef op zaterdag 27 augustus 2022 @ 18:02:
Dat laatste dacht ik dus ook al daarom heb ik de router en accespoints van synology zodat ik bv in kan stellen dat de wasmachine de accespoint in de bijkeuken moet gebruiken en de oprit camera op de router moet zitten.

Good old BSSID Setting die op heel veel apparaten ontbreekt maar dan anders is leuk, echter niet de juiste oplossing/aanpak IMHO

[dss58]

@Verwijderd zoveel mogelijk bekabeld aan sluiten, het aantal devices zegt niet zoveel, wel de bandbreedte die ze opsnoepen daarbij komt dat er een hoop interferentie kan zijn vanuit alle kanten, buren enzo, en als je device bandbreedte eist zoals video heb je een minimaal sterk signaal nodig want al die data moet er over verstouwd worden.

[Verwijderd]

dss58 schreef op zaterdag 27 augustus 2022 @ 19:11:
@Verwijderd zoveel mogelijk bekabeld aan sluiten, het aantal devices zegt niet zoveel, wel de bandbreedte die ze opsnoepen daarbij komt dat er een hoop interferentie kan zijn vanuit alle kanten, buren enzo, en als je device bandbreedte eist zoals video heb je een minimaal sterk signaal nodig want al die data moet er over verstouwd worden.

Dank jullie wel voor de tips! Ik ga er mee bezig.
Hdmi kabel was inderdaad de boosdoener met het geluid!

Snap er niks van, €40 kabel en binnen 2 jaar stuk.

[sweetdude]

Verwijderd schreef op zaterdag 27 augustus 2022 @ 18:02:
[...]


Dat laatste dacht ik dus ook al daarom heb ik de router en accespoints van synology zodat ik bv in kan stellen dat de wasmachine de accespoint in de bijkeuken moet gebruiken en de oprit camera op de router moet zitten.

Als je de instelling kan maken of een apparaat op de accespoint zit of op de router wifi. waarom maak je dan de instelling voor de tv dan niet dat hij alleen op de router zit.

sowieso kun je dan nog wat tunen door alle klein verbruikers op 2,4Ghz te zetten zoals je wasmachine, vrieskist, stofzuiger etc.
Alles wat gaat streamen zoals xbox, laptop, pc, tv op 5Ghz

Maar je hebt zoals je zelf aangeeft veel wifi apparatuur, dan zou ik er echt voor kiezen om deze op de een of andere manier aan een kabel te hangen. Bijkomend voordeel is dat deze dan 2x 5GHz banden heeft (nu gebruikt hij er 1 van voor de backhaul)
Desnoods verplaatsen naar een plek waar je wel een onopvallend gat kunt boren of de kabel achter een plint verstoppen.

[nero355]

sweetdude schreef op zaterdag 27 augustus 2022 @ 19:57:
Waarom maak je dan de instelling voor de tv dan niet dat hij alleen op de router zit.

Omdat er dus heel veel apparaten geen BSSID optie hebben...

Verwijderd schreef op zaterdag 27 augustus 2022 @ 19:37:
Snap er niks van, €40 kabel en binnen 2 jaar stuk.

Dat is echt veel teveel geld voor een HDMI kabel !!!

Kijk effe rond in Zilveren HIFI-kabels gesmeed door elfen bij maanlicht #6 of zo en dan zal je zien dat je prima kabels voor € 10 a € 15 of zo kan kopen!

[sweetdude]

nero355 schreef op zondag 28 augustus 2022 @ 15:46:
[...]

Omdat er dus heel veel apparaten geen BSSID optie hebben...

[...]

....

Maakt dat wat ut dan, ik ken Synology mesh niet maar op mijn TP-Link kan ik gewoon aangeven of een device op 2,4Ghz, 5Ghz of automatisch een band krijgt. Maar ook of ik hij op accespoint 1,2 of beide preferred heeft.
Ik weet niet zeker of dit onder BSSID valt maar werkt wel.

[nero355]

sweetdude schreef op maandag 29 augustus 2022 @ 16:52:
Maakt dat wat ut dan

Ik vind dat elk apparaat gewoon zoiets moet hebben :

ik ken Synology mesh niet maar op mijn TP-Link kan ik gewoon aangeven of een device op 2,4Ghz, 5Ghz of automatisch een band krijgt. Maar ook of ik hij op accespoint 1,2 of beide preferred heeft.
Ik weet niet zeker of dit onder BSSID valt maar werkt wel.

Dat is dus in feite een workaround voor de gebreken van de Clients dat heel veel WiFi fabrikanten zijn gaan toepassen sinds een paar jaar...

[JorisV]

Heeft iemand een idee waarom mijn raspberry pi crashed?
Het is een raspberry pi 4b 4gb met de originele voeding en raspberry os lite headless die ik draai zonder een SD kaart maar met een SSD (500gb). Eens in de zoveel tijd (weken/maanden) is de pi ineens niet meer bereikbaar (via ssh). Ik heb een adapter gekocht om hem eens aan een monitor te hangen en dan krijg ik dit:



De ssd is dus niet meer bootable. Als ik het bestand systeem bekijk ziet dat er zo uit:


Ik door wat logs heen geploegd: /var/log/syslog, /var/log/deamon.log, var/log/kern.log, var/log/dpfg.log. Ik zie dat ook al was de pi niet bereikbaar er wel is geschreven in daemon.log maar dat om 5u het netwerk niet bereikbaar was.

Heeft iemand een idee waar verder te zoeken en hoe dit te verhelpen?

[Webgnome]

Wat staat er in de logs?

[JorisV]

Webgnome schreef op woensdag 31 augustus 2022 @ 10:45:
Wat staat er in de logs?

Tsja, heel veel, maar behalve 'network unreachable' om 5u kan ik geen errors vinden.

[Dutchess_Nicole]

JorisV schreef op woensdag 31 augustus 2022 @ 10:27:
Heeft iemand een idee waarom mijn raspberry pi crashed?
Het is een raspberry pi 4b 4gb met de originele voeding en raspberry os lite headless die ik draai zonder een SD kaart maar met een SSD (500gb). Eens in de zoveel tijd (weken/maanden) is de pi ineens niet meer bereikbaar (via ssh). Ik heb een adapter gekocht om hem eens aan een monitor te hangen en dan krijg ik dit:

[Afbeelding]

De ssd is dus niet meer bootable. Als ik het bestand systeem bekijk ziet dat er zo uit:
[Afbeelding]

Ik door wat logs heen geploegd: /var/log/syslog, /var/log/deamon.log, var/log/kern.log, var/log/dpfg.log. Ik zie dat ook al was de pi niet bereikbaar er wel is geschreven in daemon.log maar dat om 5u het netwerk niet bereikbaar was.

Heeft iemand een idee waar verder te zoeken en hoe dit te verhelpen?

Als het goed is maakt systemd-journald een /var/log/lastlog aan. Dat is de dmesg log van de vorige keer dat het systeem bootte.

Als er iets mis ging dat gelogd kon worden dan zal het daar in staan.

[JorisV]

Dutchess_Nicole schreef op woensdag 31 augustus 2022 @ 11:02:
[...]


Als het goed is maakt systemd-journald een /var/log/lastlog aan. Dat is de dmesg log van de vorige keer dat het systeem bootte.

Als er iets mis ging dat gelogd kon worden dan zal het daar in staan.

Dank voor de suggesties!
De datum van lastlog is van vóór dat de pi onbereikbaar werd. Als ik er in kijk staan er bijna alleen maar nullen in en een ip adres.

[Webgnome]

post de logs dan eens? misschien dat wij iets geks kunnen zien?

[JorisV]

Webgnome schreef op woensdag 31 augustus 2022 @ 11:26:
post de logs dan eens? misschien dat wij iets geks kunnen zien?

syslog

code:

Aug 30 00:00:55 rpi4 systemd[1]: Starting Rotate log files...
Aug 30 00:00:55 rpi4 systemd[1]: Starting Daily man-db regeneration...
Aug 30 00:00:55 rpi4 systemd[1]: logrotate.service: Succeeded.
Aug 30 00:00:55 rpi4 systemd[1]: Finished Rotate log files.
Aug 30 00:00:55 rpi4 systemd[1]: man-db.service: Succeeded.
Aug 30 00:00:55 rpi4 systemd[1]: Finished Daily man-db regeneration.
Aug 30 00:07:04 rpi4 systemd[1]: session-364.scope: Succeeded.
Aug 30 00:07:04 rpi4 systemd[1]: session-365.scope: Succeeded.
Aug 30 00:07:11 rpi4 systemd[1]: session-363.scope: Succeeded.
Aug 30 00:07:11 rpi4 systemd[1]: session-363.scope: Consumed 24.527s CPU time.
Aug 30 00:17:01 rpi4 CRON[776563]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 00:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9120064
Aug 30 00:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9023584
Aug 30 00:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9023584
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 454
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 00:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.595; max=545.825)Kibits/s
Aug 30 00:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.263; max=65.545)Mibits/s
Aug 30 00:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 00:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 00:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 01:03:01 rpi4 CRON[821011]: (root) CMD (/home/joris/scripts/backup-home.sh >/dev/null 2>&1)
Aug 30 01:03:01 rpi4 crontab[821015]: (root) LIST (root)
Aug 30 01:03:09 rpi4 postfix/pickup[738291]: 703FD40E16: uid=0 from=<root>
Aug 30 01:03:09 rpi4 postfix/cleanup[821157]: 703FD40E16: message-id=<[e-mail]>
Aug 30 01:03:09 rpi4 postfix/qmgr[33234]: 703FD40E16: from=<[e-mail]>, size=446, nrcpt=1 (queue active)
Aug 30 01:03:09 rpi4 postfix/cleanup[821157]: 77F5740C8D: message-id=<[e-mail]>
Aug 30 01:03:09 rpi4 postfix/qmgr[33234]: 77F5740C8D: from=<[e-mail]>, size=582, nrcpt=1 (queue active)
Aug 30 01:03:09 rpi4 postfix/local[821160]: 703FD40E16: to=<[e-mail]>, orig_to=<postmaster>, relay=local, delay=0.05, delays=0.03/0.01/0/0.01, dsn=2.0.0, status=sent (forwarded as 77F5740C8D)
Aug 30 01:03:09 rpi4 postfix/qmgr[33234]: 703FD40E16: removed
Aug 30 01:03:10 rpi4 postfix/smtp[821161]: 77F5740C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=smtp.gmail.com[142.250.102.108]:587, delay=1.1, delays=0/0.05/0.28/0.76, dsn=2.0.0, status=sent (250 2.0.0 OK  1661814190 t19-20020a056402525300b00445bda73fbesm4218982edd.33 - gsmtp)
Aug 30 01:03:10 rpi4 postfix/qmgr[33234]: 77F5740C8D: removed
Aug 30 01:17:01 rpi4 CRON[834605]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 01:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9140064
Aug 30 01:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9053824
Aug 30 01:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9053824
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 455
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 01:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.602; max=545.825)Kibits/s
Aug 30 01:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.290; max=65.545)Mibits/s
Aug 30 01:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 01:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 01:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 02:17:01 rpi4 CRON[892566]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 02:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9180064
Aug 30 02:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9083584
Aug 30 02:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9083584
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 457
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 02:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.617; max=545.825)Kibits/s
Aug 30 02:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.340; max=65.545)Mibits/s
Aug 30 02:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 02:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 02:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 03:10:01 rpi4 CRON[943738]: (root) CMD (test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r)
Aug 30 03:17:01 rpi4 CRON[950507]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 03:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9200064
Aug 30 03:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9113824
Aug 30 03:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9113824
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 458
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 03:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.624; max=545.825)Kibits/s
Aug 30 03:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.366; max=65.545)Mibits/s
Aug 30 03:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 03:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 03:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 04:17:01 rpi4 CRON[1008463]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 04:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9240064
Aug 30 04:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9143584
Aug 30 04:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9143584
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 460
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 04:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.639; max=545.825)Kibits/s
Aug 30 04:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.411; max=65.545)Mibits/s
Aug 30 04:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 04:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 04:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 05:17:01 rpi4 CRON[1066400]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 05:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9260064
Aug 30 05:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9173824
Aug 30 05:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9173824
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 461
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 05:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.647; max=545.825)Kibits/s
Aug 30 05:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.438; max=65.545)Mibits/s
Aug 30 05:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 05:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 05:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 06:11:07 rpi4 systemd[1]: Starting Daily apt upgrade and clean activities...
Aug 30 06:11:14 rpi4 systemd[1]: apt-daily-upgrade.service: Succeeded.
Aug 30 06:11:14 rpi4 systemd[1]: Finished Daily apt upgrade and clean activities.
Aug 30 06:11:14 rpi4 systemd[1]: apt-daily-upgrade.service: Consumed 6.913s CPU time.
Aug 30 06:17:01 rpi4 CRON[1124465]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 06:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9300064
Aug 30 06:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9203584
Aug 30 06:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9203584
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 463
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 06:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.663; max=545.825)Kibits/s
Aug 30 06:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.488; max=65.545)Mibits/s
Aug 30 06:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 06:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 06:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 06:25:01 rpi4 CRON[1132214]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Aug 30 06:56:55 rpi4 systemd[1]: Starting Daily apt download activities...
Aug 30 06:57:06 rpi4 systemd[1]: apt-daily.service: Succeeded.
Aug 30 06:57:06 rpi4 systemd[1]: Finished Daily apt download activities.
Aug 30 06:57:06 rpi4 systemd[1]: apt-daily.service: Consumed 11.444s CPU time.
Aug 30 07:17:01 rpi4 CRON[1182924]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 07:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9320064
Aug 30 07:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9233824
Aug 30 07:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9233824
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 464
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 07:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.671; max=545.825)Kibits/s
Aug 30 07:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.513; max=65.545)Mibits/s
Aug 30 07:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 07:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 07:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 08:17:01 rpi4 CRON[1240923]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 08:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9360064
Aug 30 08:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9263584
Aug 30 08:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9263584
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 466
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 08:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.688; max=545.825)Kibits/s
Aug 30 08:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.562; max=65.545)Mibits/s
Aug 30 08:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 08:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 08:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 09:17:01 rpi4 CRON[1298923]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 09:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9380064
Aug 30 09:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9293824
Aug 30 09:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9293824
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 467
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 09:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.695; max=545.825)Kibits/s
Aug 30 09:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.588; max=65.545)Mibits/s
Aug 30 09:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 09:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 09:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 10:17:01 rpi4 CRON[1356889]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 10:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9420064
Aug 30 10:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9323584
Aug 30 10:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9323584
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 469
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 10:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.709; max=545.825)Kibits/s
Aug 30 10:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.630; max=65.545)Mibits/s
Aug 30 10:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 10:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 10:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 11:17:01 rpi4 CRON[1414835]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 11:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9440064
Aug 30 11:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9353312
Aug 30 11:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9353312
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 470
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 11:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.717; max=545.825)Kibits/s
Aug 30 11:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.654; max=65.545)Mibits/s
Aug 30 11:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 11:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 11:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 11:47:55 rpi4 systemd[1]: Starting Cleanup of Temporary Directories...
Aug 30 11:47:55 rpi4 systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Aug 30 11:47:55 rpi4 systemd[1]: Finished Cleanup of Temporary Directories.
Aug 30 12:07:05 rpi4 avahi-daemon[375]: Withdrawing address record for 192.168.1.207 on eth0.
Aug 30 12:07:05 rpi4 avahi-daemon[375]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.207.
Aug 30 12:07:05 rpi4 avahi-daemon[375]: Interface eth0.IPv4 no longer relevant for mDNS.
Aug 30 12:17:01 rpi4 CRON[1472780]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 12:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9480064
Aug 30 12:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9383072
Aug 30 12:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9383072
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 472
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 12:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.731; max=545.825)Kibits/s
Aug 30 12:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.584; max=65.545)Mibits/s
Aug 30 12:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 12:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 12:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 13:17:01 rpi4 CRON[1530723]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 13:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9500064
Aug 30 13:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9413312
Aug 30 13:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9413312
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 473
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 13:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.738; max=545.825)Kibits/s
Aug 30 13:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.519; max=65.545)Mibits/s
Aug 30 13:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 13:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 13:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 14:17:01 rpi4 CRON[1588699]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 14:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9540064
Aug 30 14:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9443072
Aug 30 14:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9443072
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 475
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 14:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.752; max=545.825)Kibits/s
Aug 30 14:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.478; max=65.545)Mibits/s
Aug 30 14:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 14:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 14:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 15:17:01 rpi4 CRON[1646595]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 15:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9560064
Aug 30 15:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9473312
Aug 30 15:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9473312
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 476
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 15:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.760; max=545.825)Kibits/s
Aug 30 15:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.373; max=65.545)Mibits/s
Aug 30 15:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 15:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 15:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 16:17:01 rpi4 CRON[1704514]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 16:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9600064
Aug 30 16:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9503072
Aug 30 16:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9503072
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 478
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 16:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.772; max=545.825)Kibits/s
Aug 30 16:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.423; max=65.545)Mibits/s
Aug 30 16:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 16:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 16:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 17:17:01 rpi4 CRON[1762473]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 17:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9620064
Aug 30 17:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9533312
Aug 30 17:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9533312
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 479
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 17:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.780; max=545.825)Kibits/s
Aug 30 17:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.447; max=65.545)Mibits/s
Aug 30 17:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 17:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 17:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 18:17:01 rpi4 CRON[1820444]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 18:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9660064
Aug 30 18:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9563072
Aug 30 18:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9563072
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 481
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 18:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.793; max=545.825)Kibits/s
Aug 30 18:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.495; max=65.545)Mibits/s
Aug 30 18:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 18:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 18:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 19:17:01 rpi4 CRON[1878374]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 19:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9680064
Aug 30 19:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9593312
Aug 30 19:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9593312
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 482
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 19:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.800; max=545.825)Kibits/s
Aug 30 19:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.515; max=65.545)Mibits/s
Aug 30 19:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 19:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 19:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 20:17:01 rpi4 CRON[1936361]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 20:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9720064
Aug 30 20:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9623072
Aug 30 20:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9623072
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 484
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 20:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.815; max=545.825)Kibits/s
Aug 30 20:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.559; max=65.545)Mibits/s
Aug 30 20:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 20:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 20:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 21:17:01 rpi4 CRON[1994325]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 21:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9740064
Aug 30 21:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9653312
Aug 30 21:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9653312
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 485
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 21:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.821; max=545.825)Kibits/s
Aug 30 21:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.584; max=65.545)Mibits/s
Aug 30 21:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 21:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 21:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 22:17:01 rpi4 CRON[2052216]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 22:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9780064
Aug 30 22:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9683072
Aug 30 22:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9683072
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 487
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 22:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.835; max=545.825)Kibits/s
Aug 30 22:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.510; max=65.545)Mibits/s
Aug 30 22:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 22:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 22:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 30 23:17:01 rpi4 CRON[2110166]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 30 23:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9800064
Aug 30 23:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9713312
Aug 30 23:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9713312
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 488
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 30 23:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.843; max=545.825)Kibits/s
Aug 30 23:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.534; max=65.545)Mibits/s
Aug 30 23:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 30 23:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 30 23:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 00:00:55 rpi4 systemd[1]: Starting Rotate log files...
Aug 31 00:00:55 rpi4 systemd[1]: Starting Daily man-db regeneration...
Aug 31 00:00:55 rpi4 systemd[1]: logrotate.service: Succeeded.
Aug 31 00:00:55 rpi4 systemd[1]: Finished Rotate log files.
Aug 31 00:00:55 rpi4 systemd[1]: man-db.service: Succeeded.
Aug 31 00:00:55 rpi4 systemd[1]: Finished Daily man-db regeneration.
Aug 31 00:17:01 rpi4 CRON[2168168]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 00:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9840064
Aug 31 00:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9743072
Aug 31 00:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9743072
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 490
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 00:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.854; max=545.825)Kibits/s
Aug 31 00:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.581; max=65.545)Mibits/s
Aug 31 00:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 00:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 00:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 01:03:01 rpi4 CRON[2212678]: (root) CMD (/home/joris/scripts/backup-home.sh >/dev/null 2>&1)
Aug 31 01:03:01 rpi4 crontab[2212681]: (root) LIST (root)
Aug 31 01:04:27 rpi4 postfix/pickup[2187911]: 06FBB40E16: uid=0 from=<root>
Aug 31 01:04:27 rpi4 postfix/cleanup[2214098]: 06FBB40E16: message-id=<[e-mail]>
Aug 31 01:04:27 rpi4 postfix/qmgr[33234]: 06FBB40E16: from=<[e-mail]>, size=344, nrcpt=1 (queue active)
Aug 31 01:04:27 rpi4 postfix/cleanup[2214098]: 134E540C8D: message-id=<[e-mail]>
Aug 31 01:04:27 rpi4 postfix/local[2214100]: 06FBB40E16: to=<[e-mail]>, orig_to=<postmaster>, relay=local, delay=0.09, delays=0.07/0.02/0/0.01, dsn=2.0.0, status=sent (forwarded as 134E540C8D)
Aug 31 01:04:27 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 01:04:27 rpi4 postfix/qmgr[33234]: 06FBB40E16: removed
Aug 31 01:04:27 rpi4 postfix/smtp[2214101]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 01:04:27 rpi4 postfix/smtp[2214101]: connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable
Aug 31 01:04:27 rpi4 postfix/smtp[2214101]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=0.06, delays=0/0.04/0.01/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable)
Aug 31 01:10:49 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 01:10:49 rpi4 postfix/smtp[2220258]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 01:10:49 rpi4 postfix/smtp[2220258]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 01:10:49 rpi4 postfix/smtp[2220258]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=382, delays=382/0.05/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable)
Aug 31 01:17:01 rpi4 CRON[2226222]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 01:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9860064
Aug 31 01:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9773312
Aug 31 01:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9773312
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 491
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 01:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.861; max=545.825)Kibits/s
Aug 31 01:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.517; max=65.545)Mibits/s
Aug 31 01:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 01:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 01:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 01:20:49 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 01:20:49 rpi4 postfix/smtp[2229914]: connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable
Aug 31 01:20:49 rpi4 postfix/smtp[2229914]: connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable
Aug 31 01:20:49 rpi4 postfix/smtp[2229914]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=983, delays=983/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable)
Aug 31 01:40:49 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 01:40:49 rpi4 postfix/smtp[2249224]: connect to smtp.gmail.com[142.250.27.109]:587: Network is unreachable
Aug 31 01:40:49 rpi4 postfix/smtp[2249224]: connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable
Aug 31 01:40:49 rpi4 postfix/smtp[2249224]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=2182, delays=2182/0.05/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable)
Aug 31 02:17:01 rpi4 CRON[2284203]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 02:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9900064
Aug 31 02:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9803072
Aug 31 02:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9803072
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 493
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 02:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.876; max=545.825)Kibits/s
Aug 31 02:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.564; max=65.545)Mibits/s
Aug 31 02:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 02:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 02:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 02:20:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 02:20:50 rpi4 postfix/smtp[2287893]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 02:20:50 rpi4 postfix/smtp[2287893]: connect to smtp.gmail.com[142.250.27.109]:587: Network is unreachable
Aug 31 02:20:50 rpi4 postfix/smtp[2287893]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=4583, delays=4583/0.06/0.03/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.27.109]:587: Network is unreachable)
Aug 31 02:48:08 rpi4 systemd[1]: Starting Daily apt download activities...
Aug 31 02:48:17 rpi4 systemd[1]: apt-daily.service: Succeeded.
Aug 31 02:48:17 rpi4 systemd[1]: Finished Daily apt download activities.
Aug 31 02:48:17 rpi4 systemd[1]: apt-daily.service: Consumed 9.756s CPU time.
Aug 31 03:10:01 rpi4 CRON[2335496]: (root) CMD (test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r)
Aug 31 03:17:01 rpi4 CRON[2342280]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 03:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9920064
Aug 31 03:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9833312
Aug 31 03:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9833312
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 494
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 03:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.882; max=545.825)Kibits/s
Aug 31 03:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.474; max=65.545)Mibits/s
Aug 31 03:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 03:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 03:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 03:30:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 03:30:50 rpi4 postfix/smtp[2355672]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 03:30:50 rpi4 postfix/smtp[2355672]: connect to smtp.gmail.com[2a00:1450:4025:401::6d]:587: Network is unreachable
Aug 31 03:30:50 rpi4 postfix/smtp[2355672]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=8783, delays=8783/0.07/0.03/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:401::6d]:587: Network is unreachable)
Aug 31 04:17:01 rpi4 CRON[2400244]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 04:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9960064
Aug 31 04:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9863072
Aug 31 04:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9863072
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 496
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 04:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.895; max=545.825)Kibits/s
Aug 31 04:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.521; max=65.545)Mibits/s
Aug 31 04:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 04:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 04:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 04:40:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 04:40:50 rpi4 postfix/smtp[2423273]: connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable
Aug 31 04:40:50 rpi4 postfix/smtp[2423273]: connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable
Aug 31 04:40:50 rpi4 postfix/smtp[2423273]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=12983, delays=12983/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable)
Aug 31 05:00:10 rpi4 dockerd[582705]: time="2022-08-31T05:00:10.289476504+02:00" level=warning msg="Error getting v2 registry: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:10 rpi4 dockerd[582705]: time="2022-08-31T05:00:10.289566503+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:10 rpi4 dockerd[582705]: time="2022-08-31T05:00:10.294951580+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:20 rpi4 dockerd[582705]: time="2022-08-31T05:00:20.337623404+02:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:20 rpi4 dockerd[582705]: time="2022-08-31T05:00:20.337708200+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:20 rpi4 dockerd[582705]: time="2022-08-31T05:00:20.343289054+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:30 rpi4 dockerd[582705]: time="2022-08-31T05:00:30.364472086+02:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:30 rpi4 dockerd[582705]: time="2022-08-31T05:00:30.364566567+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:30 rpi4 dockerd[582705]: time="2022-08-31T05:00:30.370011200+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:40 rpi4 dockerd[582705]: time="2022-08-31T05:00:40.411193940+02:00" level=warning msg="Error getting v2 registry: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:40 rpi4 dockerd[582705]: time="2022-08-31T05:00:40.411364569+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:40 rpi4 dockerd[582705]: time="2022-08-31T05:00:40.417334717+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:50 rpi4 dockerd[582705]: time="2022-08-31T05:00:50.448620686+02:00" level=warning msg="Error getting v2 registry: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:50 rpi4 dockerd[582705]: time="2022-08-31T05:00:50.449852308+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:50 rpi4 dockerd[582705]: time="2022-08-31T05:00:50.454172577+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:01:00 rpi4 dockerd[582705]: time="2022-08-31T05:01:00.476435584+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:00 rpi4 dockerd[582705]: time="2022-08-31T05:01:00.476522343+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:00 rpi4 dockerd[582705]: time="2022-08-31T05:01:00.480607336+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:10 rpi4 dockerd[582705]: time="2022-08-31T05:01:10.523123938+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:10 rpi4 dockerd[582705]: time="2022-08-31T05:01:10.523271863+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:10 rpi4 dockerd[582705]: time="2022-08-31T05:01:10.530918667+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:20 rpi4 dockerd[582705]: time="2022-08-31T05:01:20.542533241+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.83.42.45:443: connect: network is unreachable"
Aug 31 05:01:20 rpi4 dockerd[582705]: time="2022-08-31T05:01:20.542615334+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.83.42.45:443: connect: network is unreachable"
Aug 31 05:01:20 rpi4 dockerd[582705]: time="2022-08-31T05:01:20.546957603+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.83.42.45:443: connect: network is unreachable"
Aug 31 05:01:30 rpi4 dockerd[582705]: time="2022-08-31T05:01:30.557299000+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:30 rpi4 dockerd[582705]: time="2022-08-31T05:01:30.557411629+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:30 rpi4 dockerd[582705]: time="2022-08-31T05:01:30.562340135+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:40 rpi4 dockerd[582705]: time="2022-08-31T05:01:40.601104742+02:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.33:443: connect: network is unreachable"
Aug 31 05:01:40 rpi4 dockerd[582705]: time="2022-08-31T05:01:40.601261667+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.33:443: connect: network is unreachable"
Aug 31 05:01:40 rpi4 dockerd[582705]: time="2022-08-31T05:01:40.608582454+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.33:443: connect: network is unreachable"
Aug 31 05:17:01 rpi4 CRON[2458252]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 05:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 9980064
Aug 31 05:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9893312
Aug 31 05:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9893312
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 497
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 05:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.902; max=545.825)Kibits/s
Aug 31 05:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.545; max=65.545)Mibits/s
Aug 31 05:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 05:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 05:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 05:50:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 05:50:50 rpi4 postfix/smtp[2490869]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 05:50:50 rpi4 postfix/smtp[2490869]: connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable
Aug 31 05:50:50 rpi4 postfix/smtp[2490869]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=17183, delays=17183/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable)
Aug 31 06:17:01 rpi4 CRON[2516209]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 06:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 10020064
Aug 31 06:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9923072
Aug 31 06:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9923072
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 499
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 06:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.915; max=545.825)Kibits/s
Aug 31 06:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.476; max=65.545)Mibits/s
Aug 31 06:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 06:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 06:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 06:25:01 rpi4 CRON[2523940]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Aug 31 06:57:55 rpi4 systemd[1]: Starting Daily apt upgrade and clean activities...
Aug 31 06:58:02 rpi4 systemd[1]: apt-daily-upgrade.service: Succeeded.
Aug 31 06:58:02 rpi4 systemd[1]: Finished Daily apt upgrade and clean activities.
Aug 31 06:58:02 rpi4 systemd[1]: apt-daily-upgrade.service: Consumed 7.023s CPU time.
Aug 31 07:00:51 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 07:00:51 rpi4 postfix/smtp[2558644]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 07:00:51 rpi4 postfix/smtp[2558644]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 07:00:51 rpi4 postfix/smtp[2558644]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=21384, delays=21384/0.06/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable)
Aug 31 07:17:01 rpi4 CRON[2574267]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 07:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 10040064
Aug 31 07:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9953312
Aug 31 07:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9953312
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 500
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 07:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.923; max=545.825)Kibits/s
Aug 31 07:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.387; max=65.545)Mibits/s
Aug 31 07:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 07:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 07:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 08:10:51 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 08:10:51 rpi4 postfix/smtp[2626286]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 08:10:51 rpi4 postfix/smtp[2626286]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 08:10:51 rpi4 postfix/smtp[2626286]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=25584, delays=25584/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable)
Aug 31 08:17:01 rpi4 CRON[2632262]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug 31 08:19:54 rpi4 rngd[442]: stats: bits received from HRNG source: 10080064
Aug 31 08:19:54 rpi4 rngd[442]: stats: bits sent to kernel pool: 9983072
Aug 31 08:19:54 rpi4 rngd[442]: stats: entropy added to kernel pool: 9983072
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2 successes: 502
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2 failures: 2
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Poker: 0
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Runs: 0
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Long run: 2
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Aug 31 08:19:54 rpi4 rngd[442]: stats: HRNG source speed: (min=226.402; avg=541.936; max=545.825)Kibits/s
Aug 31 08:19:54 rpi4 rngd[442]: stats: FIPS tests speed: (min=5.953; avg=49.322; max=65.545)Mibits/s
Aug 31 08:19:54 rpi4 rngd[442]: stats: Lowest ready-buffers level: 2
Aug 31 08:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 08:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us

lastlog

code:

S
c    pts/0                           192.168.1.105

[nero355]

JorisV schreef op woensdag 31 augustus 2022 @ 10:27:
Heeft iemand een idee waarom mijn raspberry pi crashed?

Het is een raspberry pi 4b 4gb met de originele voeding en raspberry os lite headless die ik draai zonder een SD kaart maar met een SSD (500gb).

Eens in de zoveel tijd (weken/maanden) is de pi ineens niet meer bereikbaar (via ssh).

Welke USB SSD is het of gebruik je een bepaalde SSD + Externe USB behuizing combinatie ?

De ssd is dus niet meer bootable. Als ik het bestand systeem bekijk ziet dat er zo uit:
[Afbeelding]

Ik heb geen idee welke bestanden daar wel moeten staan in zo'n situatie, maar zo te zien is er niks corrupt en heb je alleen te maken met bestanden die verdwijnen of begrijp ik je situatie verkeerd

Wat heb je tot nu toe na zo'n situatie gedaan ??

Ik zie dat ook al was de pi niet bereikbaar er wel is geschreven in daemon.log maar dat om 5u het netwerk niet bereikbaar was.

Heeft iemand een idee waar verder te zoeken en hoe dit te verhelpen?

Er was in het verleden een of ander probleem met willekeurig hangende Raspberry Pi modellen, maar volgens mij is dat niet bij jou van toepassing!

Het was ook iets dat alleen te fixen was door het gekke ding te vervangen

Webgnome schreef op woensdag 31 augustus 2022 @ 11:26:
post de logs (tussen quote tags indien heel lang!) dan eens?

@JorisV

[ Voor 6% gewijzigd door nero355 op 31-08-2022 15:56 ]

[Freee!!]

Ik heb in het verleden ook wel problemen gehad met RPi's die opeens onbereikbaar waren en nooit een afdoende verklaring gevonden. Mijn "oplossing" bestaat uit een wekelijkse, automatische reboot na de backup.

[synoniem]

JorisV schreef op woensdag 31 augustus 2022 @ 11:36:
[...]


syslog

code:

Aug 31 02:20:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 02:20:50 rpi4 postfix/smtp[2287893]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 02:20:50 rpi4 postfix/smtp[2287893]: connect to smtp.gmail.com[142.250.27.109]:587: Network is unreachable
Aug 31 02:20:50 rpi4 postfix/smtp[2287893]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=4583, delays=4583/0.06/0.03/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.27.109]:587: Network is unreachable)
Aug 31 03:19:54 rpi4 rngd[442]: stats: Entropy starvations: 0
Aug 31 03:19:54 rpi4 rngd[442]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Aug 31 03:30:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 03:30:50 rpi4 postfix/smtp[2355672]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 03:30:50 rpi4 postfix/smtp[2355672]: connect to smtp.gmail.com[2a00:1450:4025:401::6d]:587: Network is unreachable
Aug 31 03:30:50 rpi4 postfix/smtp[2355672]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=8783, delays=8783/0.07/0.03/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:401::6d]:587: Network is unreachable)
Aug 31 04:40:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 04:40:50 rpi4 postfix/smtp[2423273]: connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable
Aug 31 04:40:50 rpi4 postfix/smtp[2423273]: connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable
Aug 31 04:40:50 rpi4 postfix/smtp[2423273]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=12983, delays=12983/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:402::6d]:587: Network is unreachable)
Aug 31 05:00:10 rpi4 dockerd[582705]: time="2022-08-31T05:00:10.289476504+02:00" level=warning msg="Error getting v2 registry: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:10 rpi4 dockerd[582705]: time="2022-08-31T05:00:10.289566503+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:10 rpi4 dockerd[582705]: time="2022-08-31T05:00:10.294951580+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:20 rpi4 dockerd[582705]: time="2022-08-31T05:00:20.337623404+02:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:20 rpi4 dockerd[582705]: time="2022-08-31T05:00:20.337708200+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:20 rpi4 dockerd[582705]: time="2022-08-31T05:00:20.343289054+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:30 rpi4 dockerd[582705]: time="2022-08-31T05:00:30.364472086+02:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:30 rpi4 dockerd[582705]: time="2022-08-31T05:00:30.364566567+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:30 rpi4 dockerd[582705]: time="2022-08-31T05:00:30.370011200+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.34:443: connect: network is unreachable"
Aug 31 05:00:40 rpi4 dockerd[582705]: time="2022-08-31T05:00:40.411193940+02:00" level=warning msg="Error getting v2 registry: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:40 rpi4 dockerd[582705]: time="2022-08-31T05:00:40.411364569+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:40 rpi4 dockerd[582705]: time="2022-08-31T05:00:40.417334717+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:50 rpi4 dockerd[582705]: time="2022-08-31T05:00:50.448620686+02:00" level=warning msg="Error getting v2 registry: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:50 rpi4 dockerd[582705]: time="2022-08-31T05:00:50.449852308+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:00:50 rpi4 dockerd[582705]: time="2022-08-31T05:00:50.454172577+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://lscr.io/v2/\": dial tcp 3.64.83.114:443: connect: network is unreachable"
Aug 31 05:01:00 rpi4 dockerd[582705]: time="2022-08-31T05:01:00.476435584+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:00 rpi4 dockerd[582705]: time="2022-08-31T05:01:00.476522343+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:00 rpi4 dockerd[582705]: time="2022-08-31T05:01:00.480607336+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:10 rpi4 dockerd[582705]: time="2022-08-31T05:01:10.523123938+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:10 rpi4 dockerd[582705]: time="2022-08-31T05:01:10.523271863+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:10 rpi4 dockerd[582705]: time="2022-08-31T05:01:10.530918667+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:20 rpi4 dockerd[582705]: time="2022-08-31T05:01:20.542533241+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.83.42.45:443: connect: network is unreachable"
Aug 31 05:01:20 rpi4 dockerd[582705]: time="2022-08-31T05:01:20.542615334+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.83.42.45:443: connect: network is unreachable"
Aug 31 05:01:20 rpi4 dockerd[582705]: time="2022-08-31T05:01:20.546957603+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.83.42.45:443: connect: network is unreachable"
Aug 31 05:01:30 rpi4 dockerd[582705]: time="2022-08-31T05:01:30.557299000+02:00" level=warning msg="Error getting v2 registry: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:30 rpi4 dockerd[582705]: time="2022-08-31T05:01:30.557411629+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:30 rpi4 dockerd[582705]: time="2022-08-31T05:01:30.562340135+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://registry-1.docker.io/v2/\": dial tcp 54.242.59.189:443: connect: network is unreachable"
Aug 31 05:01:40 rpi4 dockerd[582705]: time="2022-08-31T05:01:40.601104742+02:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.33:443: connect: network is unreachable"
Aug 31 05:01:40 rpi4 dockerd[582705]: time="2022-08-31T05:01:40.601261667+02:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.33:443: connect: network is unreachable"
Aug 31 05:01:40 rpi4 dockerd[582705]: time="2022-08-31T05:01:40.608582454+02:00" level=error msg="Handler for POST /v1.25/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp 140.82.121.33:443: connect: network is unreachable"
Aug 31 05:50:50 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 05:50:50 rpi4 postfix/smtp[2490869]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 05:50:50 rpi4 postfix/smtp[2490869]: connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable
Aug 31 05:50:50 rpi4 postfix/smtp[2490869]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=17183, delays=17183/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.102.109]:587: Network is unreachable)
Aug 31 06:25:01 rpi4 CRON[2523940]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Aug 31 06:57:55 rpi4 systemd[1]: Starting Daily apt upgrade and clean activities...
Aug 31 06:58:02 rpi4 systemd[1]: apt-daily-upgrade.service: Succeeded.
Aug 31 06:58:02 rpi4 systemd[1]: Finished Daily apt upgrade and clean activities.
Aug 31 06:58:02 rpi4 systemd[1]: apt-daily-upgrade.service: Consumed 7.023s CPU time.
Aug 31 07:00:51 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 07:00:51 rpi4 postfix/smtp[2558644]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 07:00:51 rpi4 postfix/smtp[2558644]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 07:00:51 rpi4 postfix/smtp[2558644]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=21384, delays=21384/0.06/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable)
Aug 31 08:10:51 rpi4 postfix/qmgr[33234]: 134E540C8D: from=<[e-mail]>, size=480, nrcpt=1 (queue active)
Aug 31 08:10:51 rpi4 postfix/smtp[2626286]: connect to smtp.gmail.com[2a00:1450:4025:402::6c]:587: Network is unreachable
Aug 31 08:10:51 rpi4 postfix/smtp[2626286]: connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable
Aug 31 08:10:51 rpi4 postfix/smtp[2626286]: 134E540C8D: to=<[e-mail]>, orig_to=<postmaster>, relay=none, delay=25584, delays=25584/0.11/0.02/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com[142.250.102.108]:587: Network is unreachable)

lastlog

code:

S
c    pts/0                           192.168.1.105

Wat opvalt is dat het met name network errors zijn dus je Pi draait vrolijk door alleen je network gaat plat enig moment. Terwijl die apt update lijkt te lukken toch iets waar je Pi ook het internet voor op moet. Wat je zou kunnen proberen is of er nieuwe firmware voor je Pi beschikbaar is met name voor je network hardware.