Různé err v logu - jejich původ a závažnost? ... contract_valid.sh


#43

Ještě jsem zapoměl napsat (prozože jsem již využil volné sloty pro editaci, tak to musím psát jako nový příspěvek), že po každé editaci úloh je zapotřebí provést restart cronu.


#44

Toto jsou aktuální plánované úlohy

# trvale sledování resolver debug
#30 23 * * * /etc/resolver/resolver-debug.sh stop
#33 23 * * * /etc/resolver/resolver-debug.sh start

*/2 * * * * /etc/init.d/haas-proxy restart  
03 */6 * * * /etc/init.d/suricata-pakon restart
06 */6 * * * /etc/init.d/pakon-monitor restart
09 */6 * * * /etc/init.d/adblock reload 

Nějakou úpravu zvážím. Další úlohou je kontrola připojení k internetu každé 3 minuty (ping na bránu, DNS a IP v internetu …indikováno do LED) … na to také kouknu.

Pokud dám dva příkazy na jeden čas, tak se neprovedou ?.. to že běží ping někam přece nemůže zabránit stažení souboru ?


#45

Podle mého to bude dělat tento řádek:


#46

Jistě, provedou. Pak záleží podle priorit, které se provedou jako první.


#47

… samozřejmě kařdý příkaz se stejným časem na novém řádku.


#48

Měl jsem stejný problém.
Počet chyb se dramaticky snížil, když jsem změnil časy spouštění v /etc/cron.d/server-uplink.cron:
1 * * * * root /usr/share/server-uplink/registration_code.sh
3 * * * * root /usr/share/server-uplink/contract_valid.sh

Teď se mi chyba od “server_uplink” objevuje cca jednou až dvakrát denně kolem 06:00:
2019-01-29 06:01:07 err server_uplink[]: Failed to get registration code
2019-01-29 06:04:01 err server_uplink[]: Failed to download contract status
2019-01-30 06:01:07 err server_uplink[]: Failed to get registration code
2019-01-31 06:02:03 err server_uplink[]: Failed to get registration code
2019-02-01 06:01:08 err server_uplink[]: Failed to get registration code
2019-02-01 06:03:01 err server_uplink[]: Failed to download contract status
2019-02-02 06:01:08 err server_uplink[]: Failed to get registration code
2019-02-02 06:05:01 err server_uplink[]: Failed to download contract status

Mimochodem: “haas” se mi nerestartuje každe 2 minuty, ale jednou za 2 hodiny (v XX:30):
root@turris:~# cat /etc/cron.d/haas
MAILTO=""
30 */2 * * * root /usr/share/haas/register.sh


#49

a nejsou ty chyby takřka každé 2. hodiny? - mám podezření, že to dělá právě restart Honeypotu.

EDIT: odpovím si sám, nejsou, protože neběží procesy souběžně s restartem Honeypotu.

Jinak @JardaB to má zbytečně v této úloze, protože opravdu Honeypot se restartuje automaticky z /etc/cron.d/haas


#50

To je pěkná bejkárna, aby si člověk udělal rozvrh, co kdy si pouští sám router a co a kdy si naplánuje uživatel . Ty úlohy co se pouští v periodě hodina a více, to si lehce o minutku posuneme. Ale kratší periody “zum Beispiel” každé 3 minuty, tam se celé hodině vyhnout neumím.

A to Failed to download https://api.turris.cz/firewall/turris-ipsets.gz.sign také typicky 6:00 a.m. :slight_smile: a trvá to 10-15 minut Není to pravidelně každý den. Ono je otázka, zda to není protistranou.

Až budu mít chvilku tak to upravím dle doporučení a jak říkají doktoři … budu to pozorovat.


#51

Já třeba Honeypot nepoužívám a tyto problémy nemám (jasně, pár se jich tam objeví, ale to je opravdu vyjímka).


#52

… ono kdyz je vicero procesu spusteno ve stejny cas (fakticky nikoliv), tak on muze vyskocit kratkodobe procak na nejakou vyssi hodnotu … a nektere veci se muzou zakuckat … a z jine strany, kdyz bezi vicero veci paralelne a clovek nevi jestli tam neni nejake zavislost (jeden aktualizuje soubor, ktery jiny jiz ocekava …,

… kdyz neni dostupne cokoliv z .turris.cz (api, haas, repos) … tak holt hodne procesu s tim muze mit problem. a zvlaste, kdyz se zrovna refreshujou .pem fajly nebo se aktualizujou pravidla na firewallu , to pak lze ocekavat, ze ne vse a vzdy projde kosher… a nehlede na to ze provider sem tam muze shodit linku, neco u nej zrovinka kratkodobe nejde a wan si da renew …


#53

U mně to bylo skoro pravidelně každou hodinu. Jako myšlenka je prověření vlivu souběhu naplánovaných úloh dobrá, ale nezdá se mi to. Nastoupí vylučovací metoda a uvidíme.

Pokud mi běží connCheck.sh … kde jsou opakovaně položky sleep viz níže, má to specifický vliv na ostatní procesy ?

rainbow pwr d000f0 enable
sleep 0.3
rainbow pwr disable
sleep 0.7

#54

Podle mého nemá, synchronizace podsvícení přečte stav z čipu a uloží stav (pokud byl změněn), takže asi nemá.


#55

Má smysl takováto analýza úloh cronu ? Ty předchozí přesuny trochu pomohly.

Které úlohy by se neměly pokud možno potkat v čase ?

Dosud mi přetrvává jen chyba 2019-02-03 20:17:01 err server_uplink[]: Failed to download contract status


#56

Vy jste si dal fakt práci s výtvorem tabulky cronu… :astonished:, hustý… :+1:

Podle tý tabulky to dělá nethist souběžně s server-uplink, tak to posuňte - každopádně bych teď delší dobu pozoroval stav, může se opravdu stát, že druhá protistrana v ten čas nereaguje a pak dojde k chybě. Každopádně závažnost už je jen malá.

A nebo první nethist smazat a nechat tam jen jeden - s delším intervalem.


#57

Ten nethist obsahuje dvě řádky

MAILTO=""
*/2 * * * *	root	nethist_stats.lua
23 0,6,12,18 * * *	root	(cat /tmp/nethist.stats | sort ; echo "uptime = $(cat /proc/uptime | cut -d. -f1)" ) | logger -p info -t nethist ; rm /tmp/nethist.stats 

Ještě s tím nějak pohnu dle vašeho doporučení … a budu to pozorovat.


#58

Taky jsem u sebe na to kouknul a už asi s tím víc neprovedem než posunout časy.


#59

Chyba je neprůstřelná a vytrvalá … co je to za problém ? Je to závažné a jak na odstranění ? Na fóru je chyba k nalezení cca od poloviny roku 2018.

2019-02-05 07:59:01 info /usr/sbin/cron[17986]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
2019-02-05 07:59:01 info /usr/sbin/cron[17985]: (root) CMD (/usr/share/server-uplink/contract_valid.sh)
2019-02-05 07:59:01 err server_uplink[]: Failed to download contract status
2019-02-05 08:00:01 info /usr/sbin/cron[18028]: (root) CMD (nethist_stats.lua)

#60

Já tyto chyby v logu také mám - v různých časech, ale když kouknu do /usr/share/firewall/turris-ipsets.gz, tak zde vidím definice z nic.cz a tyto definice jsou pak aplikovány - což mi ke spokojenosti stačí.


#61

A neni renonc jen v “server-uplink.cron” cron fajlu, kde jsou dve ulohy spoustene ve stejnou dobu jedna chce ziskat registracni kod a druha validovat ? Takze soupnout o minutku tu validaci by mohlo helfnout…

0       *       *       *       *       root    /usr/share/server-uplink/registration_code.sh
0       *       *       *       *       root    /usr/share/server-uplink/contract_valid.sh

#62

V logu se mi casto objevuje “uci entry not found” hlaska. Obvykle kolem aktivit dhcp scriptu /etc/resolver/dhcp_host_domain_ng.py (overeno rucnym zpustenim).
Dneska po nutnych hratkach s dns/dhcp, jsem explicitne specificoval static_domains = ‘0’ a dynamic_domains= ‘1’ v /etc/config/resolver a nasledne se jiz hlaska neukazala.