Tak u mě včera samovolný restart cca ve 23.33 (to mohl být připojený jedině mobil), předtím cca v 11.33 a 12.38 (dříve jsem to nesledoval).
Router běžel asi 20 hodin bez problému. Teď večer při připojení “podezřelého” zařízení s čipem RTL8723AU nastal cyklus restartů, který skončil, když jsem ono zařízení vypnul. Při problémech také nefungovalo odesílání firewallových záznamů (kdežto uCollect ano).
EDIT Je otázka, jestli je tohle náhoda, nebo ne.
Po aktualizaci mi nenaběhl vůbec.
Jsem tím taky postižen. Restarty ale nejsou samovolné, způsobí je jakékoliv připojení na WiFi síť. Zatím vyzkoušeny 2x mobilní tel. Samsung S4 a S5, tablet Prestigio a notebook Lenovo. Všiml jsem si toho až v neděli, dříve jsem to přičítal ISP nebo zatížené síti. Zařízení se prostě přihlašovala déle. Až právě v neděli na stolním PC vidím rovněž ztrátu připojení, kouknu na Turrise a vidím, že probíhá restart. Po restartu a obnově připojení již vše běží OK až do připojení dalšího zařízení. Situace trvá tak odhadem od minulého týdne.
Turris - RTRS02 1.1
3.8.2
4.4.89-d74822050ae7ec4a1e49c6af6d672787-2
Taky mám pocit, že to způsobovalo připojení určitého zařízení na Wi-Fi, ale zdaleka ne vždy. V každém případě update 3.8.2 to snad měl opravit, nicméně všichni víme, jak to skončilo. Po opětovném zprovoznění routeru (bez factory resetu) však zatím nenastal ani jeden samovolný restart - uptime už přes dva dny. Ale to se občas povedlo i minule, restarty byly velmi nepravidelné. Objevil se u někoho z vás ještě tento problém s restarty?
Zatím jsem bez restartu … tak se zdá, že update verze 3.8.2.1 to snad pořešila a že všechny ty samovolné restarty byly předzvěstí tristní situace, do které se routery 1.x v minulém týdnu dostaly
U mě Turris 1.0 běží 4 dny bez restartu na verzi 3.8.2.1.
Tak tohle jsem tedy nečekal 
teď se koukám jak to tu čtu a můj Turris se taky restartuje sám od sebe. DOŘITI! Jako pomalu chládnu a smiřuji se s tím že prostě nefunguje na stoprocent přesměrování portů budiž. A najednou koukám že aniž bych cokoliv dělal nebo nastavoval nebo vůbec cokoliv - tak se restartoval cca v jednu ráno a potom znovu před hodinou
Turris - RTRS01, 3.8.4, 4.4.91-d74822050ae7ec4a1e49c6af6d672787-0
Tohle už fakt začíná být k vzteku. Jediné co je momentálně doma k Turrisu připojeno je Ubiquiti 5GHz jako spoj do dílny a v dílně jede meteo stanice která co pět minut připojí wifi a odešle naměřená data. Připojuje se přes TP-Link který mám za tím Ubikem v dílně jako AP.
Jako já tedy nevím, ale od okamžiku kdy někdo pustil do světa tu záplatu co umrtvila Turris mám v podstatě skoro nonstop depresi a i když se snažím to vidět optimisticky (nasazení nového souborového systému, použití mikrosd karty, apod.) pořád se objevují nefunkčnosti a podivnosti které prostě otravují život tak že se zabývám myšlenkou na to pořídit něco jiného. Tolik let byl klid a vše fungovalo k naprosté spokojenosti - tak jsem byl spokojen 
a teď … restartování! Sedím si v klidu doma u počítače a dělám si práci - najednou koukám že síťové rozhraní je odpojeno a šmitec, zničehož nic. Tak musím čekat a čekat až naběhne a já můžu pokračovat.
Bohužel pro vyřešení náhodných restartu bude nutné připojit sériovou linku a zjistit, co se deje.
Log po té poslat na podporu.
Nebo pokud se Vám to nechce zapojovat seriovou linku, tak je možné poslat/předat osobně router CZ.NICu na diagnostiku, ale taky je možné, že se jim uvedena závada neprojeví.
1 Like
Měl jsem to v úmyslu, ale mně už se ty restarty od verze TurrisOS 3.8.2.1 nedějí … aktuálně mám uptime 4d 19 h, což odpovídá času, kdy jsem restartoval router po aktualizaci na TurrisOS 3.8.4
Na tyto softwarové restarty není potřeba (podle mě) sériová linka. Stačí upravit správně /etc/syslog-ng.conf
Já si tam přidal
destination log_na_hdd {
file("/mnt/zaloha/log/messages.log" perm(0644) suppress(5) template("${ISODATE} ${PRIORITY} ${PROGRAM}[${PID}]: ${MSGONLY}\n") log_fifo_size(256));
};
parametr perm(0644) je tam proto, aby se soubor dal číst i přes sambu, když se dá někam na sdílený disk, bez něho se tam nastaví jenom root práva a tak by nešel číst.
a pod to doplnit do log sekce destination(log_na_hdd)
log {
source(kernel);
source(src);
filter(f_turris_iptables);
destination(messages);
destination(log_na_hdd); # jen tento údaj tam doplnit, ne toto celé
};
Uložit a restartovat router [tedy až po zeditování následující sekce] (syslog-ng je tak svázán se systémem, že pouhý jeho restart nepomůže a všechny hlášky by to neukládalo).
Jo a taky to chce upravit i /etc/logrotate.conf aby ten soubor nerostl do nekonečna, přidáním na konec:
/cesta k uloženému souboru/log_na_hdd.log {
size=10M # velikost dle vašeho uvážení, po kompresi to nemá ani jedno mega
delaycompress
postrotate
/etc/init.d/syslog-ng restart
/etc/init.d/cron restart
endscript
}
(nezpomenou nechat prázný řádek na konci souboru 
)
Pro tyto softwarové chyby bych řekl že to stačí, záznam z konzole je ale nutností pro ty hardwarové.
Jo a tyto (podobné) úpravy by mohly být zmíněny v dokumentaci, hlavně sekce RC kde je občas potřeba odchytit nějaké mušky. @Pepe , @Tangero
Ohledně SW restartů si nejsem jistý. EDIT: Je potřeba to vyzkoušet, zda to bude platit i pro problém, který má @chemik582 .
S dokumentačí souhlasím. Oficiální dokumentaci má v režii @Nora.
Já pouze píší navody do komunitni dokumentaci a poradím ve foru avšak nijak nejsem spjat s Turris teamem potažmo CZ.NIC.
Jelikož jsem dělal pokusného králíčka ohledně těch restartů, tak to mám vyzkoušené. Softwarová chyba typu “panic kernel” se zapíše. O proti konzoli tam nejsou hlášky typu osahání si hardwaru při startu a start Ubootu, je tam vše co se s routerem děje už od začátku načítání kernelu.
Děkuji tohle určitě vyzkouším. Mám k turrisu připojený samostatně napájený usb hub a v něm je mikrosd karta (/mnt/mikrosd) kam mám už směrován Domoticz. Tak si tam pošlu i logy. Doufám že to pomůže. Ze včerejška na dnešek byl restart v 23:20 a potom v 02:20 (přesnost na minuty je zhruba, ale podle mého pozorování sedí).
Dnes celý den cestuju, ale hned jak to půjde provedu tu úpravu a o výsledek se podělím.
Kapku jsem upravil nepřesnosti v návodu. Jen upozorňuji, že pokud necháte jméno souboru stejné jako originál, co se zapisuje do /var/log/ (nepřidáte *.log) tak druhý soubor který by se ukládal na flasku bude mít stejná práva roota (bez možnosti čtení po síti). Chvilku mi trvalo než jsem na tu provázanost s právy ukládaných souborů přišel.
Na té úpravě pracuji. Ale mezitím jsem si při prohlížení logů všiml že se tam opakuje se železnou pravidelností část s přiloženého výpisu s tím že se …device number x… zvyšuje neustále o jedno. Nemůže to pak mít vliv jako že dojde na nějaký počet a restartuje aby mohl začít zas od nuly? A co se to tam děje??? Mám teď mikrosd kartu pod pamětí - ta by měla být nějak součástí systému a potom mám další mikrosd kartu vloženou do připojeného samostatně napájeného usb hubu a ta je /mnt/mikrosd - tam si zapisuju Domoticz konfigurace soubory *.py a podobně.
2017-10-25T13:02:28+02:00 crit mountd[5478]: ----------> mount ret = 0
2017-10-25T13:02:30+02:00 info kernel[]: [ 50.232776] usb 1-1.2.3: USB disconnect, device number 8
2017-10-25T13:02:30+02:00 info kernel[]: [ 50.418865] usb 1-1.2.3: new high-speed USB device number 9 using fsl-ehci
2017-10-25T13:02:30+02:00 info kernel[]: [ 50.519196] usb-storage 1-1.2.3:1.0: USB Mass Storage device detected
2017-10-25T13:02:30+02:00 info kernel[]: [ 50.533864] scsi host4: usb-storage 1-1.2.3:1.0
2017-10-25T13:02:31+02:00 crit mountd[5478]: /tmp/run/mountd/Disc-A1 has dissappeared … unmounting
2017-10-25T13:02:31+02:00 crit mountd[5478]: removing sda1
2017-10-25T13:02:31+02:00 notice kernel[]: [ 51.622317] scsi 4:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0 CCS
2017-10-25T13:02:31+02:00 notice kernel[]: [ 51.624883] sd 4:0:0:0: [sda] 15564800 512-byte logical blocks: (7.97 GB/7.42 GiB)
2017-10-25T13:02:31+02:00 notice kernel[]: [ 51.625488] sd 4:0:0:0: [sda] Write Protect is off
2017-10-25T13:02:31+02:00 debug kernel[]: [ 51.625500] sd 4:0:0:0: [sda] Mode Sense: 4b 00 00 08
2017-10-25T13:02:31+02:00 err kernel[]: [ 51.627467] sd 4:0:0:0: [sda] No Caching mode page found
2017-10-25T13:02:31+02:00 err kernel[]: [ 51.632853] sd 4:0:0:0: [sda] Assuming drive cache: write through
2017-10-25T13:02:31+02:00 info kernel[]: [ 51.652162] sda: sda1
2017-10-25T13:02:31+02:00 notice kernel[]: [ 51.654999] sd 4:0:0:0: [sda] Attached SCSI removable disk
2017-10-25T13:02:32+02:00 crit mountd[5478]: new mount : Disc-A1 -> sda1 (FAT)
2017-10-25T13:02:32+02:00 crit mountd[5478]: mounting /tmp/run/mountd/sda1
2017-10-25T13:02:32+02:00 crit mountd[8406]: mount -t vfat -o rw,uid=1000,gid=1000 /dev/sda1 /tmp/run/mountd/sda1
2017-10-25T13:02:32+02:00 warning kernel[]: [ 51.823287] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Co můžu vyzkoušet než spustím tu úpravu co je popisována pár příspěvků výše?
No pokud máte přípojné body nastavené a nic nepřipojujete Hot-plugin, tak bych zakázal spouštět mountd (což je utilitka na okamžité připojení disku do systému). V podstatě není potřeba, podle výpisu se ji nelíbí FAT na vašem disku sda1, nebo spíše si myslí že je tam FAT a systém to odmítne přimountovat.
Nevím jestli mám napovídat jak na to v <turris>/cgi-bin/luci/admin/system/startup u mountd změnit na Zakázáno a ještě potom kliknout na Stop
nebo přes příkazový řádek
/etc/init.d/mountd disable
/etc/init.d/mountd stopZa jakoukoliv nápovědu děkuji. Příkazy jsem použil přes terminál (ssh) a retsartoval jsem router. Bohužel ve výpisu /var/log/messages se opět pořád dokola opakuje tato část:
2017-10-25T22:47:57+02:00 info kernel[]: [ 123.730722] usb 1-1.2.3: USB disconnect, device number 19
2017-10-25T22:47:57+02:00 info kernel[]: [ 123.914989] usb 1-1.2.3: new high-speed USB device number 20 using fsl-ehci
2017-10-25T22:47:57+02:00 info kernel[]: [ 124.015297] usb-storage 1-1.2.3:1.0: USB Mass Storage device detected
2017-10-25T22:47:57+02:00 info kernel[]: [ 124.015629] scsi host15: usb-storage 1-1.2.3:1.0
2017-10-25T22:47:58+02:00 notice kernel[]: [ 125.099364] scsi 15:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0 CCS
2017-10-25T22:47:58+02:00 notice kernel[]: [ 125.101235] sd 15:0:0:0: [sda] 15564800 512-byte logical blocks: (7.97 GB/7.42 GiB)
2017-10-25T22:47:58+02:00 notice kernel[]: [ 125.102162] sd 15:0:0:0: [sda] Write Protect is off
2017-10-25T22:47:58+02:00 debug kernel[]: [ 125.102175] sd 15:0:0:0: [sda] Mode Sense: 4b 00 00 08
2017-10-25T22:47:58+02:00 err kernel[]: [ 125.102683] sd 15:0:0:0: [sda] No Caching mode page found
2017-10-25T22:47:58+02:00 err kernel[]: [ 125.108124] sd 15:0:0:0: [sda] Assuming drive cache: write through
2017-10-25T22:47:58+02:00 info kernel[]: [ 125.118211] sda: sda1
2017-10-25T22:47:58+02:00 notice kernel[]: [ 125.121218] sd 15:0:0:0: [sda] Attached SCSI removable disk
bylo by možné že v tom dělá neplechu ten napájený usb hub? Mám v něm momentálně jen usb jablotron dongl a tu paměťovou kartu, to by snad šlo pořešit menším nenapájeným hubem. Dřív jsem ještě připojoval usb tp-link wifi kartu, ale to jsem odebral při oživování takže jsou tam jen tyto dvě věci.
Na ty dve veci je hub z napajenim zbytecnej…zkus napajeni odpojit pokud to jde
Tak dnes v noci někdy těsně před půlnocí se mi Turris 1.1 sám restartoval. Já to nebyl, aktualizace to taky nebyla - tu mám nastavenou na 3:30 a navíc aktuální rc jsem neinstaloval.
Horší je, že se při startu nenahodily některé služby - lighttp (forris), lxc-kontejner, mosquitto, transmission, bc-gateway-usb-dongle. Všechno jsem ráno nahodil ručně.
Taky se mi neodesílaly fw záznamy. Spustil jsem nikolu ručně a pro jistotu restartoval cron.
Úplně stejně se mi to chovalo v úterý, kdy mi prasklá žárovka vyrazila pojistky. Dané služby jsem musel restartovat ručně.
Zařízení Turris - RTRS02 (na brtfs)
Verze Turris OS 3.8.5
Verze jádra 4.4.91-d74822050ae7ec4a1e49c6af6d672787-0
Zřejmě to budou dva nesouvisející problémy. Nahazování služeb možná vyřeší nová verze FW. Restarty budu dále sledovat.