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.
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 ?
Podle mého to bude dělat tento řádek:
Jistě, provedou. Pak záleží podle priorit, které se provedou jako první.
… samozřejmě kařdý příkaz se stejným časem na novém řádku.
1 Like
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
1 Like
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
1 Like
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. 
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.
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).
… 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 …
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.7Podle mého nemá, synchronizace podsvícení přečte stav z čipu a uloží stav (pokud byl změněn), takže asi nemá.
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
Vy jste si dal fakt práci s výtvorem tabulky cronu… 
, hustý… 
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.
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.
Taky jsem u sebe na to kouknul a už asi s tím víc neprovedem než posunout časy.
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)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čí.
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
1 Like
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.
1 Like