Cron: spuštění každých 5 minut

[beer]

No, právě že by mi pořád přibívaly chyby i v případě úspěšného průběhu, a to tyto:

Kód: [Vybrat]

warning: templates not found /usr/share/git-core/templates
Reinitialized existing Git repository in /mnt/sdcard/public-ipv4-turris/.git/

On branch master                                                             

Your branch is up-to-date with 'origin/master'.                                 

nothing to commit, working directory clean                               

fatal: remote origin already exists.                           

Everything up-to-date                       

Branch master set up to track remote branch master from origin.

[Reklama]

[nobody]

No, právě že by mi pořád přibívaly chyby i v případě úspěšného průběhu, a to tyto:
[...]

pokud script pousteny cronem neco zobrazi pri uspesnem prubehu je to spatne, nema zobrazovat absolutne nic

pokud uzivatel pouziva stejny skript i pro pousteni rucne, kdy chce zobrazovat i uspesny prubeh, muze jednoduse ve skriptu detekovat jestli je pousteno uzivatelem nebo cronem a podle toho zobrazovat nebo nezobrazovat...

a error nechat zobrazovat(/preposilat/ukladat) vzdy...

[beer]

Já tyhle chyby za chyby nepovažuji, warning ohledně templates mne netrápí, to, že je up to date znamená, že nebyla detekována změna a tudíž není co commitnout, nepotřebuju to dělat složitější, když to funguje, jak má, chybový výstup cronu mohu posílat do souboru v /tmp/ (kam jsem si to dneska nastavil, abych vám ty chyby napsal). Proč bych měl dělat skript složitější? Pro to není přece žádný důvod, aby tam byly nějaké detekce pro to, jestli je to spuštěné uživatelem nebo ručně. Kdo by chtěl, může se inspirovat a vymyslet lepší způsob. Účelem je připojení se na router i když se změní ip adresa.

https://github.com/jiri001meitner/public-ipv4-turris

připojuji se například z keyboxu přes https a webový prohlížeč na rhcloudu takto:

v bash profilu mám

Kód: [Vybrat]

alias ssh_ipv4="~/app-root/data/ssh_ipv4.sh"
a v souboru ~/app-root/data/ssh_ipv4.sh

Kód: [Vybrat]

ssh root@$(curl "https://raw.githubusercontent.com/jiri001meitner/service.meitner.cz/master/ipv4.txt") -C -F ~/app-root/data/ssh/ssh_config -p číslo portu

v ~/app-root/data/ssh/ mám samozřejmě klíče chráněné passphrase.

[Filip Jirsák]

Tak ono to funguje OK, takže nepotřebuju chybový výstup.

To je jak takové ty poslední věty před smrtí… Chyby se nelogují proto, že by se lidé chtěli kochat tím, jak programy krásně nefungují. Logují se proto, že zkušenosti ukazují, že něco, co funguje, se může docela snadno rozbít. A pak je dobré se o tom z výpisu chyb dozvědět. Takže chybový výstup potřebuje, abyste se dozvěděl, až to fungovat OK přestane.

Nastavil jsem si ve skriptu /bin/date > /tmp/public.ipv4.log, prostým ověřením času tohoto souboru zjistím, že cron proběhl OK.

Vy na ten router každých pět minut polezete a budete kontrolovat čas toho souboru? Přece od toho máme počítače, aby rutinní úlohy dělaly za nás.

Nepotřebuji posílat e-mailem, musel bych do openwrt instalovat program pro posílání e-mailů a to mi připadá zbytečné.

Pokud vám je jedno, zda se ta cron úloha správně provádí nebo ne, mohl jste si ušetřit čas s jejím vytvářením.

No, právě že by mi pořád přibívaly chyby i v případě úspěšného průběhu, a to tyto:

Skutečné chyby a varování je dobré opravit, informační hlášky na standardní výstup je možné potlačit nebo přesměrovat jinam (třeba do /dev/null). Já jsem v komentáři psal o přesměrování chybového výstupu.

nepotřebuju to dělat složitější, když to funguje, jak má, chybový výstup cronu mohu posílat do souboru v /tmp/

Problém je v tom, že do /tmp/ ten chybový výstup budete posílat i tehdy, když to nebude fungovat, jak má. Jednoduché už jste to měl, a výsledkem bylo, že jste se musel na fóru ptát, co děláte špatně.

[beer]

Chyby se nelogují proto, že by se lidé chtěli kochat tím, jak programy krásně nefungují. Logují se proto, že zkušenosti ukazují, že něco, co funguje, se může docela snadno rozbít. A pak je dobré se o tom z výpisu chyb dozvědět. Takže chybový výstup potřebuje, abyste se dozvěděl, až to fungovat OK přestane.

Moc pěkně řečeno, s tím se dá jen souhlasit. Pokud přestane fungovat a já se díky tomu na router nepřipojím, tak je mi log k ničemu, že.
Jakmile se připojím, tak zjistím, proč neproběhlo - nepřidělená ip z wan, selhání rezervní konektivity, která tam je nastavená (wi-free), apod.




Nemám důvod tam lozit každých pět minut a kotrolovat, jestli skript pracuje ok. Pracuje OK, bude pracovat i dál. Při každé změně konfigurace je potřeba otestovat. Poslední ip adresu mám přidělenou od poskytovatele déle než rok, předpoklad že se změní není veliký.
Nicméně chybový výstup z cronu loguji nyní do /tmp/public.ipv4.cron.log

Pokud vám je jedno, zda se ta cron úloha správně provádí nebo ne, mohl jste si ušetřit čas s jejím vytvářením.

Něco takového bylo někde napsáno? To je dedukováno z toho, že zavrhuji bobtnající chybový výstup? Nebo spamování e-mailem v čase každého spuštění úlohy?
Myslím, že jste nepochopil, že to, že úloha skončí chybou když se nezmění ip adresa - neproběhne díky tomu commit. To není chyba, to je záměr! Tam žádné skutečné chyby, které mají vliv na funkčnost, v tuto chvíli nejsou.

Problém je v tom, že do /tmp/ ten chybový výstup budete posílat i tehdy, když to nebude fungovat, jak má.

To není problém, to je záměr. Tam to snadno najdu když nebude fungovat a jsou tam logy od všeho možného. Navíc opravdu nehodlám ničit router za 12 tisíc tím, že tam každých pár minut budu přepisovat pamět.

Jednoduché už jste to měl, a výsledkem bylo, že jste se musel na fóru ptát, co děláte špatně.

Ano, chyba byla nalezena, částečně s pomocí fóra, částečně díky googlování a metodám typu pokus omyl - chyběl mi uživatel v cronu, a taky jsem tam musel zněnit složku, odkud cron volá git, další věc byla, že i na fóru pro turris mi bylo řečeno, že to není windows a že není potřeba nic jiného dělat, aby se změny v cronu projevily. No, nebyla to pravda, pokud se neudělá alespoň /etc/init.d/cron reload, tak se změny neprojeví.

[Reklama]

[Filip Jirsák]

Jakmile se připojím, tak zjistím, proč neproběhlo

Jenže nejdřív musíte zjistit, že to neproběhlo.

Pracuje OK, bude pracovat i dál.

To je tak naivní… Obzvlášť pikantní je, že jste předevčírem neuměl cron ani základně nastavit, a dnes tvrdíte, že se to nemůže rozbít.

Při každé změně konfigurace je potřeba otestovat.

A také při každé změně verze, a to na obou stranách, při každé změně v síti (bude vám to hlásit ISP?). A dokonce i při každé změně času, protože to může přestat fungovat prostě plynutím času (skončí platnost certifikátu, registrace domény…).

Něco takového bylo někde napsáno? To je dedukováno z toho, že zavrhuji bobtnající chybový výstup? Nebo spamování e-mailem v čase každého spuštění úlohy?

Plyne to z toho, že chybový výstup přesměrováváte do souboru, který musíte ručně kontrolovat. Chybový výstup funkční aplikace nebobtná. Chybový výstup funkční aplikace je prázdný, a bobtnat začne teprve ve chvíli chyby – a to je přesně ten okamžik, který vás zajímá. Ke spamování e-mailem v čase každého spuštění úlohy nedochází, přece píšete, jak vám to správně funguje, tak nemůže být nic na chybovém výstupu.

Myslím, že jste nepochopil, že to, že úloha skončí chybou když se nezmění ip adresa - neproběhne díky tomu commit. To není chyba, to je záměr!

Myslím, že vy jste nepochopil, že tam může být milion jiných chyb.

Tam žádné skutečné chyby, které mají vliv na funkčnost, v tuto chvíli nejsou.

Což neříká vůbec nic o tom, jak to bude za deset minut.

Navíc opravdu nehodlám ničit router za 12 tisíc tím, že tam každých pár minut budu přepisovat pamět.

To po vás také nikdo nechce.

Ano, chyba byla nalezena, částečně s pomocí fóra, částečně díky googlování a metodám typu pokus omyl - chyběl mi uživatel v cronu, a taky jsem tam musel zněnit složku, odkud cron volá git, další věc byla, že i na fóru pro turris mi bylo řečeno, že to není windows a že není potřeba nic jiného dělat, aby se změny v cronu projevily. No, nebyla to pravda, pokud se neudělá alespoň /etc/init.d/cron reload, tak se změny neprojeví.

Tohle všechno jste nevěděl před dvěma dny, a za ty dva dny jste se toho naučil tolik, abyste mohl tvrdit, že když to funguje teď, bude to fungovat už navěky? Sebevědomí vám teda rozhodně nechybí.

Dělejte jak umíte. Rady od lidí, kteří cron používají už desítky let, jste dostal.

[beer]

Nikdo vám nebrání kód na githubu forknout a ukázat, že to umíte lépe. Pro mé účely to je takto OK, ale pokud vaše řešení bude lepší, rád se nechám inspirovat.

[beer]

odstranil jsem cesty v souboru, a funguje, dal jsem za gitové příkazy 2>/dev/null  a nyní je již chybový výstup bez záznamů. Nyní by to mělo logovat jen případné chyby, se kterými se nepočítá.

[nobody]

neber si to osobne... proste skript v cronu NEMA zobrazovat NIC, pokud nejde o chybu, jakmile zobrazi chybu NEMA se hodit do null, ale do mailu roota (pripadne do souboru co root bude kontrolovat rucne kdyz se 'boji' mailu), dela se to tak proto se pouze error na tebe bafne, pouze error bude 'plnit logy' a nedela se to pro pripady ze vse funguje, ale prave pro pripady ze neco nezafungovalo aby jsi se o tom snadno a v ramci moznosti hned dozvedelel...
btw: v pripade chteneho logovani i uspechu a/nebo vetsiho mnozstvi informaci: man logrotate

v pripade ze by jsi chtel pri rucnim pusteni zobrazovat i informace ale pri cron ne, neni to nic komplikovaneho, jednoduse napr.

Kód: [Vybrat]

#!/bin/sh
tty -s && runuser="yes" || runcron=">/dev/nul"
[ $runuser ] && echo "ted se bude delat nejakej_prikaz"
nejakej_prikaz ${runcron}

[beer]

Rozumím těmto argumentům, aktuálně mám nastaveno, že chybuvý výstup je v cronu prázdný, tak snad je to OK. Ručně spouštět nepotřebuji. No, je to script na hraní, jehož účelem je prostě poslat ip adresu, na kterou se můžu připojit. Jsou ale i osvědčené jiné metody (dynamické dns), které jsou standardizované, jen jsem chtěl to vyzkoušet jinak, třeba to bude hodit někomu, kdo nemá možnost použít dynamické dns. Zaregistroval jsem se na noip.com a vyzkouším, jestli je to lepší, nežli mé řešení, tak svůj skript smažu. Ve skriptu nemuseli být nakonec ty cesty k těm programům, je funkční i bez nich, proto jsem je odstranil.

Aktuální funkční (u mne) konfigurace

Kód: [Vybrat]

#!/bin/sh
# change directory to local turris git repository
cd /mnt/sdcard/public-ipv4-turris/
#current public ipv4 address
#/usr/bin/
ip addr show br-wan | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}" | head -n 1 1> /mnt/sdcard/public-ipv4-turris/ipv4.txt || wget http://ipinfo.io/ip -qO - 1> /mnt/sdcard/public-ipv4-turris/ipv4.txt || curl ifconfig.co 1> /mnt/sdcard/public-ipv4-turris/ipv4.txt || curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//' 1> /mnt/sdcard/public-ipv4-turris/ipv4.txt
#last run log
date > /tmp/public.ipv4.log
#remote upload ipv4 changes
git init 2>/dev/null
git add /mnt/sdcard/public-ipv4-turris/* 2>/dev/null
git commit -m "$(date)" 2>/dev/null
git ls-files --deleted | xargs git rm 2> /dev/null
git push -u origin master 2>/dev/null || /usr/bin/git pull --no-edit
exit 0

Cron jsem si nastavil logování chyb do souboru v /tmp a nastavil jsem si to na 2 minuty. Log je čistý, jenom když proběhne git pull, tak mi zapíše zprávu do souboru /tmp/public.ipv4.log.cron, což tak mám schválně.

Kód: [Vybrat]

*/02 * * * * root cd /mnt/sdcard/public-ipv4-turris && sh /mnt/sdcard/public-ipv4-turris/public_ipv4.sh 2>>/tmp/public.ipv4.log.cron

Nekamentujte mne, že to není přesně podle vašich představ. IP adresa se primárně zjišťuje interně z rozhraní, u ostatních by to takto nefungovalo, protože budou mít jiný název rozhraní, nebo tam mohou mít lokální adresu. V případě, když selže zjištění adesy, tak se zjišťuje z několika zdrojů přes internet. Rád se ale přiučím.