From Pavel.Just na simac.cz Sat Oct 3 21:00:35 2015 From: Pavel.Just na simac.cz (Pavel Just) Date: Sat, 3 Oct 2015 21:00:35 +0200 Subject: CentOS cluster a DRBD Message-ID: <1443898835.4694.10.camel@simac.cz> Zdravím. Mám CentOS 6.7 s DRBD 8.4.5 a klastrovými službami (ricci/luci). Potřebuji zrcadlený diskový prostor mezi dvěma stroji(ne filesystém). Nakonfiguroval jsem si drbd resource. Chodí, překlápí se, po startu je v Secondary/Secondary, kde ho přepnu na primary, tam lze do /dev/drbd0 zapisovat. V /proc/drbd je přesně co očekávám. Prima. Myslel jsem si, že překlápění mezi uzly (a s tím i překlápění dalších služeb) mohu řídit pomocí clusteru. Webové rozhraní mi nabídne službu drbd a v /etc/cluster/cluster.conf pak mám: Bohužel po zadání clusvcadm -e drbddisk se služba nastaruje, clustat říká, že služba běží, ale na daném uzlu se nestane vůbec nic. Dokonce ani nepozná, že mu drbd vypnu. Nikde žádná hláška o chybě. Co dělám špatně ? Díky za nakopnutí. Pavel From kas na fi.muni.cz Wed Oct 7 13:57:13 2015 From: kas na fi.muni.cz (Jan Kasprzak) Date: Wed, 7 Oct 2015 13:57:13 +0200 Subject: Linuxove prednasky na tema dohled nad sitemi In-Reply-To: References: Message-ID: <20151007115713.GR9273@fi.muni.cz> Ahoj, Dan Ohnesorg wrote: : organizujeme na podzim (termin budeme ladit i podle prednasejicich) : linuxove odpoledne na FAV ZCU. Tematicky by to melo byt o Icinga, Zabbix, : OpenNMS, ale urcite i netflow/sflow collectorech, smokepingu a kousek : centralniho logovani. ELK, Graylog2... : : Ja bych si asi vzal prednasku o distribuovane instalaci Icingy 2, ale : hledame dalsi prednasejici, primarne bych tam rad videl Zabbix a OpenNMS, : ale mozna nekdo mate instalace Cacti nebo neceho uplne jineho. Proste : nevahejte mi napsat, pokud mate neco so si myslite, ze by mohlo ostatni : zaujmout. Ja bych uvital neco o masivnim shromazdovani provoznich dat nejen ze sitovych prvku - treba by to mohlo byt o collectd nebo necem takovem. Sam o tom (zatim?) nic moc rict neumim, tak pisu radeji sem, treba se nekdo najde. -Y. -- | Jan "Yenya" Kasprzak | | New GPG 4096R/A45477D5 -- see http://www.fi.muni.cz/~kas/pgp-rollover.txt | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | Smart data structures and dumb code works a lot better than the other way around. --Eric S. Raymond From kas na fi.muni.cz Wed Oct 7 17:41:59 2015 From: kas na fi.muni.cz (Jan Kasprzak) Date: Wed, 7 Oct 2015 17:41:59 +0200 Subject: [vyreseno] DNSSEC: A/wildcard versus NSEC3 In-Reply-To: <20150909151239.GM9273@fi.muni.cz> References: <20150903073110.GM9273@fi.muni.cz> <20150909151239.GM9273@fi.muni.cz> Message-ID: <20151007154159.GC28454@fi.muni.cz> : : On Thu, 3 Sep 2015, Jan Kasprzak wrote: : : : : >Podle tohoto existuje pro to jmeno jak korektne podepsany zaznam A : : >a dokonce AAAA (zrejme jako instance wildcard zaznamu : : >*.restaurant-pavillon.cz), ale zaroven existuji NSEC3 zaznamy, : : >ktere popiraji existenci "www" v te domene. : : > : : >Je tohle korektni? Tohle je zrejme chyba BINDu v Debianu 6. Upragdem BINDu problem zmizel, novejsi verze berou situaci wildcard + NSEC3 popirajici skutecne jmeno jako korektni. -Y. -- | Jan "Yenya" Kasprzak | | New GPG 4096R/A45477D5 -- see http://www.fi.muni.cz/~kas/pgp-rollover.txt | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | Smart data structures and dumb code works a lot better than the other way around. --Eric S. Raymond From vaclav.ovsik na seznam.cz Wed Oct 7 18:16:32 2015 From: vaclav.ovsik na seznam.cz (=?iso-8859-1?Q?V=E1clav_Ovs=EDk?=) Date: Wed, 7 Oct 2015 18:16:32 +0200 Subject: Linuxove prednasky na tema dohled nad sitemi In-Reply-To: <20151007115713.GR9273@fi.muni.cz> References: <20151007115713.GR9273@fi.muni.cz> Message-ID: <20151007161632.GA4021@bobek.localdomain> Zdravim, On Wed, Oct 07, 2015 at 01:57:13PM +0200, Jan Kasprzak wrote: > > Dan Ohnesorg wrote: > : organizujeme na podzim (termin budeme ladit i podle prednasejicich) > : linuxove odpoledne na FAV ZCU. Tematicky by to melo byt o Icinga, Zabbix, > : OpenNMS, ale urcite i netflow/sflow collectorech, smokepingu a kousek > : centralniho logovani. ELK, Graylog2... nejsem pravej na recneni pred publikem, ale neda mi to a podelim se tady o pozitivni zkusenost s CheckMK. > : > : Ja bych si asi vzal prednasku o distribuovane instalaci Icingy 2, ale > : hledame dalsi prednasejici, primarne bych tam rad videl Zabbix a OpenNMS, > : ale mozna nekdo mate instalace Cacti nebo neceho uplne jineho. Proste > : nevahejte mi napsat, pokud mate neco so si myslite, ze by mohlo ostatni > : zaujmout. > > Ja bych uvital neco o masivnim shromazdovani provoznich dat > nejen ze sitovych prvku - treba by to mohlo byt o collectd nebo necem takovem. > Sam o tom (zatim?) nic moc rict neumim, tak pisu radeji sem, treba se nekdo > najde. Pokud berete grafy RRD jako taky nejaka data, tak to lze chapat i jako monitoring i sber dat. Provozujeme CheckMK na Debianu vlastnorucne zkonfigurovany s dalsimi komponentami PNP4Nagios, RRDCached. Autor/i se to snazi pojmout take komercne jako Open Monitoring Distribution - OMD, ale to me osobne nebylo od zacatku sympaticke (i kdyz to bylo free), ja radeji zakladni balicky po svem. Jako backend to uziva Nagios / Icinga 1. Me se na tom libi automaticka invetorizace - nainstalujete do systemu agenta a ono si to samo zjisti co je zajimave k dohledovani. Sitove prvky to ojede pres SNMPwalk a taky to udela samo inventory. Checky to nedela jako jednotlive requesty pro kazdou sluzbu jak bylo zvykem s NRPE, ale sbira vsechno naraz z agenta systemu a vysledky doda jako pasivni checky do Nagios / Icingy, takze to ma slusny vykon. (rozebrano v doc) Dokumentovano pekne, viz http://mathias-kettner.com/checkmk.html. Jenom to chce se do toho trosku dostat. Rozsireni lze psat v Pythonu. Par veci jsem spachal (naposledy treba pro termocidlo od Papoucha), neni to nic sloziteho. CMK je backportech pro Debian Jessie ve verzi 1.2.6p12. -- Zito From d.petr na post.cz Fri Oct 9 12:35:20 2015 From: d.petr na post.cz (d.petr) Date: Fri, 09 Oct 2015 11:35:20 +0100 Subject: PERL, problem s hodnotou promenne Message-ID: <56179868.6000302@post.cz> Dobrý den, řeším tady takový pro mě nepochopitelný problém v PERLu. Mám takovýhle kousek programu v konstrukci given-when when ($_ < (nejaky_vyraz)) { $Nova = $Sdilene{CO} - 0.2 * $Sdilene{PV}; if ($Sdilene{SL} > $Nova) { $Sdilene{SL} = $Nova; $Stav = 2;}} a pokud program touto částí projde, vrátí se mi vždy $Sdilene{SL}==1 (má hodnotu 1). Přitom $Nova má hodnotu větší, než 1. Zajímavé je, že když jsem si dovnitř bloku when zařadil různé průběžné výpisy proměnných, abych sledoval, kde se to pokazí, všechny proměnné nabývaly hodnot správných, dokonce i ta $Sdilene{SL}. Teď jsem zjistil, že stačí změnit řádek uvnitř podmínky na $Sdilene{SL} = 1 * $Nova; a už je taky výsledek v $Sdilene{SL} správný. Zkrátka když jakkoliv použiju proměnnou $Nova před přiřazením její hodnoty do $Sdilene{SL}, vykoná se to celé dobře. Když přiřadím hned, vloží se 1. Přitom všechny použité proměnné jsou číselné. Máte pro toto chování někdo vysvětlení? PERL 5.14.2. Díky Petr From peak na argo.troja.mff.cuni.cz Fri Oct 9 13:35:57 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Fri, 9 Oct 2015 13:35:57 +0200 (CEST) Subject: PERL, problem s hodnotou promenne In-Reply-To: <56179868.6000302@post.cz> References: <56179868.6000302@post.cz> Message-ID: On Fri, 9 Oct 2015, d.petr wrote: > řeším tady takový pro mě nepochopitelný problém v PERLu. Mám > takovýhle kousek programu v konstrukci given-when > > when ($_ < (nejaky_vyraz)) { Takové konstrukce v Perlu za mých mladých časů nebývaly, tak s tím nemám zkušenosti, ale neměla by ve when být hodnota (vůči které je testován výraz v given) a ne podmínka? > Zkrátka když jakkoliv použiju proměnnou $Nova před přiřazením její > hodnoty do $Sdilene{SL}, vykoná se to celé dobře. Zajímavé je, že stejný efekt nemá použití v podmínce v příkazu if ($Sdilene{SL} > $Nova). To pozorované chování by mohlo svědčit o nějakých problémech s typem hodnoty v $Nova. Ale bylo by to divné, protože ta hodnota je o dva řádky nad tím vypočtena aritmetickým výrazem. Zkuste trochu prověřit hodnoty $Sdilene{CO} a $Sdilene{PV}, které vstupují do výpočtu $Nova, jestli nějaké magické chování nevykazují už ony. -- Pavel Kankovsky aka Peak "Que sais-je?" From d.petr na post.cz Fri Oct 9 14:37:07 2015 From: d.petr na post.cz (d.petr) Date: Fri, 09 Oct 2015 13:37:07 +0100 Subject: PERL, problem s hodnotou promenne In-Reply-To: References: <56179868.6000302@post.cz> Message-ID: <5617B4F3.1030708@post.cz> Pavel Kankovsky wrote: > On Fri, 9 Oct 2015, d.petr wrote: > >> řeším tady takový pro mě nepochopitelný problém v PERLu. Mám takovýhle >> kousek programu v konstrukci given-when >> >> when ($_ < (nejaky_vyraz)) { > > Takové konstrukce v Perlu za mých mladých časů nebývaly, tak s tím nemám > zkušenosti, ale neměla by ve when být hodnota (vůči které je testován > výraz v given) a ne podmínka? Pevná hodnota je asi nejpoužívanější případ, ale jak jsem to pochopil já, může tam být i porovnání a dokonce podmínka, která s výrazem v given vůbec nesouvisí. Myslím, že jsem už použil given(1) a ve when zcela různé podmínky a fungovalo to; napsal jsem to tak proto, že se použije první vyhovující podmínka a příslušný blok se vykoná, následující podmínky už se netestují, takže se tak lze vyhnout řetězům if-elsif-elsif-... >> Zkrátka když jakkoliv použiju proměnnou $Nova před přiřazením její >> hodnoty do $Sdilene{SL}, vykoná se to celé dobře. > > Zajímavé je, že stejný efekt nemá použití v podmínce v příkazu > if ($Sdilene{SL} > $Nova). > > To pozorované chování by mohlo svědčit o nějakých problémech s typem > hodnoty v $Nova. Ale bylo by to divné, protože ta hodnota je o dva řádky > nad tím vypočtena aritmetickým výrazem. > > Zkuste trochu prověřit hodnoty $Sdilene{CO} a $Sdilene{PV}, které > vstupují do výpočtu $Nova, jestli nějaké magické chování nevykazují už ony. Typ v $Nova jsem také podezíral, ale jak už jsem psal, stačilo před přiřazení vložit print "$Sdilene{SL} $Nova \n"; a vše se tvářilo správně a i výsledek pak už byl správně. $Sdilene{CO} a $Sdilene{PV} jsou snad v pořádku, používají se i jinde v programu a nezdá se, že by s nimi byly potíže. Dá se nějak zjistit, jestli je v proměnné číslo, nebo znakový zápis čísla (tzn. jestli je tam třeba 5 jako $Prom=5, nebo 5 jako $Prom='5')? V PERLu moc neprogramuji, tak nevím. Myslel jsem, že jedině jako výsledek porovnání == a eq, ale ukázalo se, že porovnání to nerozliší. A rozlišuje to vůbec PERL alespoň nějak vnitřně? Petr From peak na argo.troja.mff.cuni.cz Fri Oct 9 15:06:25 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Fri, 9 Oct 2015 15:06:25 +0200 (CEST) Subject: PERL, problem s hodnotou promenne In-Reply-To: <5617B4F3.1030708@post.cz> References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> Message-ID: On Fri, 9 Oct 2015, d.petr wrote: > Myslím, že jsem už použil given(1) a ve when zcela různé podmínky a > fungovalo to; [...] Když na začátek dáte given(1), tak se pak vlastně ptáte, zda má podmínka jako výraz jedničkovou hodnotu, což je totéž, jako byste se ptal, zda je splněna. > Typ v $Nova jsem také podezíral, ale jak už jsem psal, stačilo před > přiřazení vložit > print "$Sdilene{SL} $Nova \n"; > a vše se tvářilo správně a i výsledek pak už byl správně. Matně si vzpomínám, že použití hodnoty v Perlu může mít za jistých okolností nějaké vedlejší efekty. Ale bohužel si nevzpomínám na detaily a nechce se mi je hledat, protože má denní dávka hororových zážitků už byla vyčerpána. :) > Dá se nějak zjistit, jestli je v proměnné číslo, nebo znakový zápis > čísla (tzn. jestli je tam třeba 5 jako $Prom=5, nebo 5 jako $Prom='5')? Ono tam dokonce může být obojí. A dokonce to mohou být úplně jiné hodnoty. Něco málo se dá zjistit pomocí Scalar::Util. A propos, zkusil jste pro to dočasné úložiště použít jiné jméno a/nebo tam dát my $Nova? Třeba si to jméno přineslo nějaké magické vlastnosti odjinud. -- Pavel Kankovsky aka Peak "Que sais-je?" From jaivast na gmail.com Fri Oct 9 15:10:01 2015 From: jaivast na gmail.com (Ivan Stenda) Date: Fri, 9 Oct 2015 15:10:01 +0200 Subject: PERL, problem s hodnotou promenne In-Reply-To: <5617B4F3.1030708@post.cz> References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> Message-ID: > > Dobry den, skuste pouzit Data::Dumper, moj pocit je tiez ze ide o > neocakavane automaticke pretypovanie. BTW ta konstrukcia s when nie je > prave standardna, mne to na 5.20.2 skonci s chybou ... > ?i? > > > > Dá se nějak zjistit, jestli je v proměnné číslo, nebo znakový > zápis čísla (tzn. jestli je tam třeba 5 jako $Prom=5, nebo 5 jako > $Prom='5')? V PERLu moc neprogramuji, tak nevím. Myslel jsem, že jedině > jako výsledek porovnání == a eq, ale ukázalo se, že porovnání to nerozliší. > A rozlišuje to vůbec PERL alespoň nějak vnitřně? > > > Petr > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > From jaivast na gmail.com Fri Oct 9 15:17:57 2015 From: jaivast na gmail.com (Ivan Stenda) Date: Fri, 9 Oct 2015 15:17:57 +0200 Subject: PERL, problem s hodnotou promenne In-Reply-To: References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> Message-ID: A este som si dodatocne spomenul ze use warnings; mi v podobnej situacii uz tiez pomohlo ... i 2015-10-09 15:10 GMT+02:00 Ivan Stenda : > Dobry den, skuste pouzit Data::Dumper, moj pocit je tiez ze ide o >> neocakavane automaticke pretypovanie. BTW ta konstrukcia s when nie je >> prave standardna, mne to na 5.20.2 skonci s chybou ... >> > > ?i? > > >> >> From d.petr na post.cz Fri Oct 9 16:19:53 2015 From: d.petr na post.cz (d.petr) Date: Fri, 09 Oct 2015 15:19:53 +0100 Subject: PERL, problem s hodnotou promenne In-Reply-To: References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> Message-ID: <5617CD09.1050203@post.cz> Pavel Kankovsky wrote: > On Fri, 9 Oct 2015, d.petr wrote: > >> Myslím, že jsem už použil given(1) a ve when zcela různé podmínky a >> fungovalo to; [...] > > Když na začátek dáte given(1), tak se pak vlastně ptáte, zda má podmínka > jako výraz jedničkovou hodnotu, což je totéž, jako byste se ptal, zda je > splněna. No jo, to máte vlastně možná pravdu! :) > A propos, zkusil jste pro to dočasné úložiště použít jiné jméno a/nebo > tam dát my $Nova? Třeba si to jméno přineslo nějaké magické vlastnosti > odjinud. "my" tam bylo původně, pak jsem ho přesunul mimo given, jestli to nepomůže. Nepomohlo. Jiné jméno taky nepomůže. A samozřejmě to dělá jen v tomhle programu, testovací samostatný prográmek s touhle konstrukcí se chová správně tak, jak bych čekal. No, už to zkoumám druhý den, tak se asi prozatím smířím s tím, že tam bude 1*$Nova. Už mám jednu podmínku, kde musí být if($Hodnota==0), nestačí if(!Hodnota), tak toto bude podobné. PERL je zkrátka jazyk s překvapivými schopnostmi. :) Díky za snahu Petr From d.petr na post.cz Fri Oct 9 17:06:32 2015 From: d.petr na post.cz (d.petr) Date: Fri, 09 Oct 2015 16:06:32 +0100 Subject: PERL, problem s hodnotou promenne In-Reply-To: References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> Message-ID: <5617D7F8.7070008@post.cz> Ivan Stenda wrote: > A este som si dodatocne spomenul ze use warnings; mi v podobnej situacii uz > tiez pomohlo ... > > i > > 2015-10-09 15:10 GMT+02:00 Ivan Stenda: > >> Dobry den, skuste pouzit Data::Dumper, moj pocit je tiez ze ide o >>> neocakavane automaticke pretypovanie. BTW ta konstrukcia s when nie je >>> prave standardna, mne to na 5.20.2 skonci s chybou ... Váš mail byl ve spamu, proto až teď ... print Dumper tu proměnnou $Nova vypisuje jako '1.1255...', tzn. jako řetězec. Ale PROČ? No to teda ... Program spouštím s parametrem -w, to by snad mělo být to samé, jako use warnings. Žádné varování nehlásí. Díky za Dumper, ten mě teda dostal. Petr From d.petr na post.cz Fri Oct 9 17:18:27 2015 From: d.petr na post.cz (d.petr) Date: Fri, 09 Oct 2015 16:18:27 +0100 Subject: PERL, problem s hodnotou promenne In-Reply-To: <5617D7F8.7070008@post.cz> References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> <5617D7F8.7070008@post.cz> Message-ID: <5617DAC3.5090702@post.cz> d.petr wrote: > Ivan Stenda wrote: >> A este som si dodatocne spomenul ze use warnings; mi v podobnej >> situacii uz >> tiez pomohlo ... >> >> i >> >> 2015-10-09 15:10 GMT+02:00 Ivan Stenda: >> >>> Dobry den, skuste pouzit Data::Dumper, moj pocit je tiez ze ide o >>>> neocakavane automaticke pretypovanie. BTW ta konstrukcia s when nie je >>>> prave standardna, mne to na 5.20.2 skonci s chybou ... > > Váš mail byl ve spamu, proto až teď ... > print Dumper tu proměnnou $Nova vypisuje jako '1.1255...', tzn. jako > řetězec. Ale PROČ? No to teda ... > Program spouštím s parametrem -w, to by snad mělo být to samé, jako use > warnings. Žádné varování nehlásí. > > Díky za Dumper, ten mě teda dostal. > Petr Jinak i výpis dumperem stačí k tomu, aby výsledek byl použitelný a ne ==1. Petr From d.petr na post.cz Fri Oct 9 19:26:23 2015 From: d.petr na post.cz (d.petr) Date: Fri, 09 Oct 2015 19:26:23 +0200 (CEST) Subject: PERL, problem s hodnotou promenne References: <56179868.6000302@post.cz> Message-ID: ---------- Původní zpráva ---------- Od: d.petr Komu: Diskuse o Linuxu v cestine Datum: 9. 10. 2015 12:04:22 Předmět: PERL, problem s hodnotou promenne "Dobrý den, řeším tady takový pro mě nepochopitelný problém v PERLu. Mám takovýhle kousek programu v konstrukci given-when when ($_ < (nejaky_vyraz)) { $Nova = $Sdilene{CO} - 0.2 * $Sdilene{PV}; if ($Sdilene{SL} > $Nova) { $Sdilene{SL} = $Nova; $Stav = 2;}} a pokud program touto částí projde, vrátí se mi vždy $Sdilene{SL}==1 (má hodnotu 1). Přitom $Nova má hodnotu větší, než 1. Zajímavé je, že když jsem si dovnitř bloku when zařadil různé průběžné výpisy proměnných, abych sledoval, kde se to pokazí, všechny proměnné nabývaly hodnot správných, dokonce i ta $Sdilene{SL}. Teď jsem zjistil, že stačí změnit řádek uvnitř podmínky na $Sdilene{SL} = 1 * $Nova; a už je taky výsledek v $Sdilene{SL} správný. Zkrátka když jakkoliv použiju proměnnou $Nova před přiřazením její hodnoty do $Sdilene{SL}, vykoná se to celé dobře. Když přiřadím hned, vloží se 1. Přitom všechny použité proměnné jsou číselné. Máte pro toto chování někdo vysvětlení? PERL 5.14.2. "   Tak jsem se posunul trošku dál. Teď mám už za blokem given-when (takže ten už za to nemůže) proměnnou $Sdilene{SL} se správnou hodnotou, ale uloženou jako řetězec, tedy aspoň tak ji zobrazuje dumper. Je zvláštní, že print "$Sdilene{SL} \n"; vypíše 1 (jedničku). Když ale před printem přiřadím $Sdilene{SL} = $Sdilene{SL} * 1; už print vypíše správnou hodnotu. Fakt zvláštní. Ani nečekám, že by ještě někoho něco napadlo, píšu to spíš už jen jako zajímavost. Petr From mj na ucw.cz Fri Oct 9 21:35:24 2015 From: mj na ucw.cz (Martin `MJ' Mares) Date: Fri, 9 Oct 2015 21:35:24 +0200 Subject: PERL, problem s hodnotou promenne In-Reply-To: <5617D7F8.7070008@post.cz> References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> <5617D7F8.7070008@post.cz> Message-ID: Hello, world!\n > print Dumper tu proměnnou $Nova vypisuje jako '1.1255...', tzn. > jako řetězec. Ale PROČ? No to teda ... O tomhle by daleko víc než Data::Dumper mohl prozradit Devel::Peek. Have a nice fortnight -- Martin `MJ' Mares http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth MIPS: Meaningless Indicator of Processor Speed. From d.petr na post.cz Sat Oct 10 22:38:10 2015 From: d.petr na post.cz (d.petr) Date: Sat, 10 Oct 2015 21:38:10 +0100 Subject: PERL, problem s hodnotou promenne In-Reply-To: References: <56179868.6000302@post.cz> <5617B4F3.1030708@post.cz> <5617D7F8.7070008@post.cz> Message-ID: <56197732.5090304@post.cz> Martin `MJ' Mares, 9.10.2015 20:35: > Hello, world!\n > >> print Dumper tu proměnnou $Nova vypisuje jako '1.1255...', tzn. >> jako řetězec. Ale PROČ? No to teda ... > > O tomhle by daleko víc než Data::Dumper mohl prozradit Devel::Peek. > > Have a nice fortnight Ježkovyvoči! Devel Peek - tomu tedy říkám šifra. Problém asi zatím obejdu a nejdřív dodělám to, co potřebuji udělat, ale pak se k té záhadě určitě vrátím a zkusím ji, i pomocí Devel Peeku, ještě prozkoumat. Každopádně díky za tip, je vidět, že je v PERLu mnohokrát víc tajů, než jsem si vůbec myslel. Petr From info na zsk.name Mon Oct 19 02:24:42 2015 From: info na zsk.name (FAST ONLINE LOANS LTD) Date: Mon, 19 Oct 2015 02:24:42 +0200 Subject: naliehavé v loan@3% Message-ID: Pozdravy "Rýchle Online pôžičky Limited" poskytuje širokú škálu finančných transakcií, výpožičné služby pre jednotlivcov a partnerstvá, ponúkame pôžičky s úrokovou sadzbou 3%. od 10 000 EUR na 25 000 €, 000,00, a každá mena, naša doba počnúc od 1 roka do 20 rokov ak ste potrebujú finančnú pomoc, alebo potrebujete úver uhradiť svoj dlh zlé ste vyzvaní vyplniť nižšie spracovanie úveru. Celé meno: Krajina: Výška úveru: Doba trvania úveru: Čakám na odpovede, že Pokračujeme s úverové dokumentácia vďaka Pán Glatz Williams ___________________________________ Greetings "Fast Online Loans Limited" provides a wide Range of financial trading, lending services to individuals and partnerships we offer loans at an interest rate of 3%. from € 10,000 to €25,000, 000.00, and to any currency, our duration starting from 1 year to 20 years if you are in need of financial help or you need loan to settle your bad debt you are being asked to fill below your loan processing. Full name: country: Loan Amount: Loan duration: I'm waiting for answers that we continue with the loan documentation Thanks Mr. Glatz Williams urgent loan na 3% From zettacamdarwinso na gmail.com Sat Oct 24 22:35:03 2015 From: zettacamdarwinso na gmail.com (zettacamdarwinso na gmail.com) Date: Sat, 24 Oct 2015 20:35:03 +0000 Subject: [ZETTA] 24hr battery matchbox size intelligent security camcorder Message-ID: <20151024203503.275641C4952@mail.attez.com.hk> Dear linux, This is Darwin So from Zetta Systems Limited. We are a manufacturer specializing in mini monitoring camcorder: www.zetta.com.hk Our best sellers (8000 per month to EU / US) currently are: ZIR32 / Z16 / Z15 / Z12 - IR night vision, PIR trigger with 6month standby, 160deg viewing angle, rotatable camera, HD 720, 24hr battery, scheduled recording, motion detection, vibration triggering recording with 90day standby intelligent security camcorder for home / shop / car security, car driving recording, meeting minutes and spy use. Very small size like a matchbox: 7.6cm x 4.3cm x 1.9cm and as light as 52 gram. FCC / CE compliant. Please buy it from eBay http://www.ebay.com/usr/zettasys?_trksid=p2047675.l2559 Thank you very much! Regards, Darwin So Zetta Systems Limited Email: darwinso na zetta.com.hk Mobile: (852) 9773 3529 / (1) 415 373 6020 / (86) 147 149 33529 Tel: (852) 3188 4492 Fax: (852) 3755 4181 Address: Unit 513, Lakeside 1, No. 8 Science Park West Avenue, HKSTP, Shatin, N.T., HK Website: www.zetta.com.hk From megacsk na gmail.com Thu Oct 29 07:30:16 2015 From: megacsk na gmail.com (Martin Mokry) Date: Thu, 29 Oct 2015 07:30:16 +0100 Subject: Cas Message-ID: Ahojte. Mam problem s casom na Fedore (22). Ked dam na noc uspat system do RAM alebo hibernovat, po prebudeni je cas o nejake 3 dni dopredu. Mam nastavenu automaticku synchronizaciu, musim vsak nastavit cas manualne na blizsie aby to opravila. Mali ste uz takuto skusenost? Co robit v takomto pripade? Za odpovede vopred dakujem -- Martin "Megac" Mokry From peak na argo.troja.mff.cuni.cz Thu Oct 29 15:07:51 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Thu, 29 Oct 2015 15:07:51 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Thu, 29 Oct 2015, Martin Mokry wrote: > Mam problem s casom na Fedore (22). Ked dam na noc uspat system do RAM > alebo hibernovat, po prebudeni je cas o nejake 3 dni dopredu. To je opravdu zajímavé chování. Co říká "hwclock --show" před uspáním a po probuzení? -- Pavel Kankovsky aka Peak "Que sais-je?" From pribyl na lowlevel.cz Thu Oct 29 14:52:28 2015 From: pribyl na lowlevel.cz (Adam Pribyl) Date: Thu, 29 Oct 2015 14:52:28 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Thu, 29 Oct 2015, Martin Mokry wrote: > Ahojte. > > Mam problem s casom na Fedore (22). Ked dam na noc uspat system do RAM > alebo hibernovat, po prebudeni je cas o nejake 3 dni dopredu. Mam nastavenu > automaticku synchronizaciu, musim vsak nastavit cas manualne na blizsie aby > to opravila. Mali ste uz takuto skusenost? Co robit v takomto pripade? > > Za odpovede vopred dakujem Proc se cas posouva takto to netusim, nicmene ntpd mel urcitou hranici rozdilu casu za kterou cas jiz nekoriguje. chronyd by to mel zvladnout. Co pouzivate? Jinak castecnym resenim je asi pridat si do resume ntpdate ci tak neco, ale pokud bezi ntp/chrony tak to bude rvat, ze socket uz je obsazeny.. > -- > Martin "Megac" Mokry Adam Pribyl From lists.subscriber na pragl.cz Thu Oct 29 15:41:52 2015 From: lists.subscriber na pragl.cz (Miroslav Pragl) Date: Thu, 29 Oct 2015 15:41:52 +0100 Subject: Cas In-Reply-To: References: Message-ID: hwclock je po resume take posunuty? MP From megacsk na gmail.com Thu Oct 29 17:21:36 2015 From: megacsk na gmail.com (Martin Mokry) Date: Thu, 29 Oct 2015 17:21:36 +0100 Subject: Cas In-Reply-To: References: Message-ID: hwclock pise toto: [root na localhost ~]# hwclock --show hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Neprípustný argument Pouzivam chrony a tu je cast logu kde je vidno skok po prebudeni z uspania do ram: Oct 29 07:09:57 localhost chronyd[30894]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) Oct 29 07:09:57 localhost chronyd[30894]: Frequency -4.105 +/- 1.947 ppm read from /var/lib/chrony/drift Oct 29 07:09:57 localhost audit: pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 29 07:10:19 localhost chronyd[30894]: Selected source 213.160.185.89 Oct 29 07:10:19 localhost chronyd[30894]: System clock wrong by 7.515107 seconds, adjustment started Oct 29 07:10:19 localhost chronyd[30894]: Selected source 95.105.193.228 Oct 29 07:12:30 localhost chronyd[30894]: Selected source 213.160.185.89 Oct 29 07:40:26 localhost chronyd[30894]: Source 2a01:390:b:0:d6ca:6dff:fe31:9d60 replaced with 92.245.0.16 Oct 29 08:10:19 localhost chronyd[30894]: Source 2a00:1298:8001::6536 replaced with 92.240.244.202 Oct 29 08:12:16 localhost chronyd[30894]: Source 87.244.233.3 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 95.105.193.228 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 91.212.112.71 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 92.240.244.202 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 2a00:10d8:10:3::202 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 92.245.0.16 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 81.89.61.115 offline Oct 29 08:12:16 localhost chronyd[30894]: Source 213.160.185.89 offline Oct 29 08:12:16 localhost chronyd[30894]: Can't synchronise: no selectable sources Nov 1 12:57:58 localhost chronyd[30894]: Forward time jump detected! Nov 1 12:58:01 localhost chronyd[30894]: Source 87.244.233.3 online Nov 1 12:58:01 localhost chronyd[30894]: Source 95.105.193.228 online Nov 1 12:58:01 localhost chronyd[30894]: Source 91.212.112.71 online Nov 1 12:58:01 localhost chronyd[30894]: Source 92.240.244.202 online Nov 1 12:58:01 localhost chronyd[30894]: Source 2a00:10d8:10:3::202 online Nov 1 12:58:01 localhost chronyd[30894]: Source 92.245.0.16 online Nov 1 12:58:01 localhost chronyd[30894]: Source 81.89.61.115 online Nov 1 12:58:01 localhost chronyd[30894]: Source 213.160.185.89 online Nov 1 13:00:12 localhost chronyd[30894]: Selected source 213.160.185.89 Nov 1 13:00:12 localhost chronyd[30894]: System clock wrong by -244800.492492 seconds, adjustment started Nov 1 13:01:15 localhost chronyd[30894]: Selected source 95.105.193.228 Nov 1 13:02:05 localhost chronyd[30894]: chronyd exiting Nov 1 13:02:05 localhost audit: pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Nov 1 13:02:05 localhost audit: pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 29 17:02:56 localhost chronyd[858]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) Oct 29 17:02:56 localhost chronyd[858]: Frequency -3.494 +/- 1.080 ppm read from /var/lib/chrony/drift Oct 29 17:02:56 localhost audit: pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Oct 29 17:03:42 localhost chronyd[858]: Selected source 92.245.0.16 Oct 29 17:03:42 localhost chronyd[858]: System clock wrong by 17.677506 seconds, adjustment started Oct 29 17:03:42 localhost chronyd[858]: System clock was stepped by 17.677506 seconds Pocas hore uvedeneho vypisu som po prebudeni manualne vypol synchronizaciu, nastavil spravny datum a priblizny cas a potom znovu zapol synchronizaciu. 2015-10-29 15:41 GMT+01:00 Miroslav Pragl : > hwclock je po resume take posunuty? > > MP > > > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > -- Martin "Megac" Mokry From peak na argo.troja.mff.cuni.cz Thu Oct 29 17:30:00 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Thu, 29 Oct 2015 17:30:00 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Thu, 29 Oct 2015, Martin Mokry wrote: > hwclock pise toto: > > [root na localhost ~]# hwclock --show > hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: > Neprípustný argument Moc pěkné... tak jinak: zkuste příkaz cat /sys/class/rtc/rtc0/{date,time,since_epoch} -- Pavel Kankovsky aka Peak "Que sais-je?" From peak na argo.troja.mff.cuni.cz Thu Oct 29 17:31:09 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Thu, 29 Oct 2015 17:31:09 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Thu, 29 Oct 2015, Pavel Kankovsky wrote: > cat /sys/class/rtc/rtc0/{date,time,since_epoch} a ještě cat /proc/driver/rtc -- Pavel Kankovsky aka Peak "Que sais-je?" From megacsk na gmail.com Thu Oct 29 17:33:13 2015 From: megacsk na gmail.com (Martin Mokry) Date: Thu, 29 Oct 2015 17:33:13 +0100 Subject: Cas In-Reply-To: References: Message-ID: podobne chovanie: [root na localhost ~]# cat /sys/class/rtc/rtc0/{date,time,since_epoch} cat: /sys/class/rtc/rtc0/date: Neprípustný argument cat: /sys/class/rtc/rtc0/time: Neprípustný argument cat: /sys/class/rtc/rtc0/since_epoch: Neprípustný argument [root na localhost ~]# 2015-10-29 17:30 GMT+01:00 Pavel Kankovsky : > On Thu, 29 Oct 2015, Martin Mokry wrote: > > hwclock pise toto: >> >> [root na localhost ~]# hwclock --show >> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: >> Neprípustný argument >> > > Moc pěkné... tak jinak: zkuste příkaz > > cat /sys/class/rtc/rtc0/{date,time,since_epoch} > > > -- > Pavel Kankovsky aka Peak "Que sais-je?" > > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > -- Martin "Megac" Mokry From megacsk na gmail.com Thu Oct 29 17:36:33 2015 From: megacsk na gmail.com (Martin Mokry) Date: Thu, 29 Oct 2015 17:36:33 +0100 Subject: Cas In-Reply-To: References: Message-ID: [root na localhost ~]# cat /proc/driver/rtc alrm_time : 08:26:17 alrm_date : 2015-10-24 alarm_IRQ : no alrm_pending : no update IRQ enabled : no periodic IRQ enabled : no periodic IRQ frequency : 1024 max user IRQ frequency : 64 24hr : yes periodic_IRQ : yes update_IRQ : yes HPET_emulated : yes BCD : yes DST_enable : no periodic_freq : 1024 batt_status : okay [root na localhost ~]# 2015-10-29 17:31 GMT+01:00 Pavel Kankovsky : > On Thu, 29 Oct 2015, Pavel Kankovsky wrote: > > cat /sys/class/rtc/rtc0/{date,time,since_epoch} >> > > a ještě cat /proc/driver/rtc > > > -- > Pavel Kankovsky aka Peak "Que sais-je?" > > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > -- Martin "Megac" Mokry From pribyl na lowlevel.cz Thu Oct 29 20:36:19 2015 From: pribyl na lowlevel.cz (Adam Pribyl) Date: Thu, 29 Oct 2015 20:36:19 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: > Oct 29 08:12:16 localhost chronyd[30894]: Can't synchronise: no selectable > sources > Nov 1 12:57:58 localhost chronyd[30894]: Forward time jump detected! System nastartoval s hodinami 29.10. 8:12 zrejme pred uspanim a pak najednou z niceho nic doslo ke skoku dopredu na 1.11. 12:57 (tedy o 76h45m42s)? To chovani hw hodin je samozrejme take podezrele. Vypada to jako kdyz tam bud zadne nejsou, nebo je linux nezna. Jeste bych pro jistotu zkontroloval jestli vam do toho nekeca systemd-timesyncd... On Thu, 29 Oct 2015, Martin Mokry wrote: > hwclock pise toto: > > [root na localhost ~]# hwclock --show > hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: > Neprípustný argument > > Pouzivam chrony a tu je cast logu kde je vidno skok po prebudeni z uspania > do ram: > > Oct 29 07:09:57 localhost chronyd[30894]: chronyd version 2.1.1 starting > (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) > Oct 29 07:09:57 localhost chronyd[30894]: Frequency -4.105 +/- 1.947 ppm > read from /var/lib/chrony/drift > Oct 29 07:09:57 localhost audit: pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? > addr=? terminal=? res=success' > Oct 29 07:10:19 localhost chronyd[30894]: Selected source 213.160.185.89 > Oct 29 07:10:19 localhost chronyd[30894]: System clock wrong by 7.515107 > seconds, adjustment started > Oct 29 07:10:19 localhost chronyd[30894]: Selected source 95.105.193.228 > Oct 29 07:12:30 localhost chronyd[30894]: Selected source 213.160.185.89 > Oct 29 07:40:26 localhost chronyd[30894]: Source > 2a01:390:b:0:d6ca:6dff:fe31:9d60 replaced with 92.245.0.16 > Oct 29 08:10:19 localhost chronyd[30894]: Source 2a00:1298:8001::6536 > replaced with 92.240.244.202 > Oct 29 08:12:16 localhost chronyd[30894]: Source 87.244.233.3 offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 95.105.193.228 offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 91.212.112.71 offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 92.240.244.202 offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 2a00:10d8:10:3::202 > offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 92.245.0.16 offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 81.89.61.115 offline > Oct 29 08:12:16 localhost chronyd[30894]: Source 213.160.185.89 offline > Oct 29 08:12:16 localhost chronyd[30894]: Can't synchronise: no selectable > sources > Nov 1 12:57:58 localhost chronyd[30894]: Forward time jump detected! > Nov 1 12:58:01 localhost chronyd[30894]: Source 87.244.233.3 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 95.105.193.228 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 91.212.112.71 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 92.240.244.202 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 2a00:10d8:10:3::202 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 92.245.0.16 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 81.89.61.115 online > Nov 1 12:58:01 localhost chronyd[30894]: Source 213.160.185.89 online > Nov 1 13:00:12 localhost chronyd[30894]: Selected source 213.160.185.89 > Nov 1 13:00:12 localhost chronyd[30894]: System clock wrong by > -244800.492492 seconds, adjustment started > Nov 1 13:01:15 localhost chronyd[30894]: Selected source 95.105.193.228 > Nov 1 13:02:05 localhost chronyd[30894]: chronyd exiting > Nov 1 13:02:05 localhost audit: pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? > addr=? terminal=? res=success' > Nov 1 13:02:05 localhost audit: pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? > addr=? terminal=? res=success' > Oct 29 17:02:56 localhost chronyd[858]: chronyd version 2.1.1 starting > (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) > Oct 29 17:02:56 localhost chronyd[858]: Frequency -3.494 +/- 1.080 ppm read > from /var/lib/chrony/drift > Oct 29 17:02:56 localhost audit: pid=1 uid=0 auid=4294967295 > ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd > comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? > addr=? terminal=? res=success' > Oct 29 17:03:42 localhost chronyd[858]: Selected source 92.245.0.16 > Oct 29 17:03:42 localhost chronyd[858]: System clock wrong by 17.677506 > seconds, adjustment started > Oct 29 17:03:42 localhost chronyd[858]: System clock was stepped by > 17.677506 seconds > > > Pocas hore uvedeneho vypisu som po prebudeni manualne vypol synchronizaciu, > nastavil spravny datum a priblizny cas a potom znovu zapol synchronizaciu. > > 2015-10-29 15:41 GMT+01:00 Miroslav Pragl : > >> hwclock je po resume take posunuty? >> >> MP >> >> >> _______________________________________________ >> Linux mailing list >> Linux na linux.cz >> http://www.linux.cz/mailman/listinfo/linux >> > > > > -- > Martin "Megac" Mokry > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > Odchozi zprava neobsahuje viry, protoze nebyla odeslana z Windows. Otestovano zdarma a legalne na OS Linux. (Proc pouzivat Linux - http://proc.linux.cz/). From peak na argo.troja.mff.cuni.cz Fri Oct 30 00:13:53 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Fri, 30 Oct 2015 00:13:53 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Thu, 29 Oct 2015, Martin Mokry wrote: > podobne chovanie: > > [root na localhost ~]# cat /sys/class/rtc/rtc0/{date,time,since_epoch} > cat: /sys/class/rtc/rtc0/date: Neprípustný argument > cat: /sys/class/rtc/rtc0/time: Neprípustný argument > cat: /sys/class/rtc/rtc0/since_epoch: Neprípustný argument > [root na localhost ~]# To je fakt zvláštní... On Thu, 29 Oct 2015, Martin Mokry wrote: > [root na localhost ~]# cat /proc/driver/rtc > alrm_time : 08:26:17 > alrm_date : 2015-10-24 > alarm_IRQ : no > alrm_pending : no > update IRQ enabled : no > periodic IRQ enabled : no > periodic IRQ frequency : 1024 > max user IRQ frequency : 64 > 24hr : yes > periodic_IRQ : yes > update_IRQ : yes > HPET_emulated : yes > BCD : yes > DST_enable : no > periodic_freq : 1024 > batt_status : okay > [root na localhost ~]# A tady to je také hodně podivné, protože tam úplně chybí položky "rtc_time" a "rtc_date". Což tedy souhlasí s tím, že všechny jiné cesty, které měly vést k jejich přečtení skončily na EINVAL. Pokud jádro nedokáže přečíst stav RTC, tak by to mohlo celkem vysvětlovat ty přeskoky hodin, když je systém uspaný. Co tam máte za driver? Podle položek v /proc/driver/rtc to vypadá na rtc-cmos, ale to by bylo až moc divné. protože tam by to čtení nemělo selhat nikdy. Co vypíše následující příkaz? ls -l /sys/class/rtc/rtc0/device/driver -- Pavel Kankovsky aka Peak "Que sais-je?" From megacsk na gmail.com Fri Oct 30 07:51:06 2015 From: megacsk na gmail.com (Martin Mokry) Date: Fri, 30 Oct 2015 07:51:06 +0100 Subject: Cas In-Reply-To: References: Message-ID: Je tam to co ste predpokladali: [root na localhost ~]# ls -l /sys/class/rtc/rtc0/device/driver lrwxrwxrwx. 1 root root 0 okt 30 2015 /sys/class/rtc/rtc0/device/driver -> ../../../bus/pnp/drivers/rtc_cmos 2015-10-30 0:13 GMT+01:00 Pavel Kankovsky : > On Thu, 29 Oct 2015, Martin Mokry wrote: > > podobne chovanie: >> >> [root na localhost ~]# cat /sys/class/rtc/rtc0/{date,time,since_epoch} >> cat: /sys/class/rtc/rtc0/date: Neprípustný argument >> cat: /sys/class/rtc/rtc0/time: Neprípustný argument >> cat: /sys/class/rtc/rtc0/since_epoch: Neprípustný argument >> [root na localhost ~]# >> > > To je fakt zvláštní... > > On Thu, 29 Oct 2015, Martin Mokry wrote: > > [root na localhost ~]# cat /proc/driver/rtc >> alrm_time : 08:26:17 >> alrm_date : 2015-10-24 >> alarm_IRQ : no >> alrm_pending : no >> update IRQ enabled : no >> periodic IRQ enabled : no >> periodic IRQ frequency : 1024 >> max user IRQ frequency : 64 >> 24hr : yes >> periodic_IRQ : yes >> update_IRQ : yes >> HPET_emulated : yes >> BCD : yes >> DST_enable : no >> periodic_freq : 1024 >> batt_status : okay >> [root na localhost ~]# >> > > A tady to je také hodně podivné, protože tam úplně chybí položky > "rtc_time" a "rtc_date". Což tedy souhlasí s tím, že všechny jiné cesty, > které měly vést k jejich přečtení skončily na EINVAL. > > Pokud jádro nedokáže přečíst stav RTC, tak by to mohlo celkem vysvětlovat > ty přeskoky hodin, když je systém uspaný. > > Co tam máte za driver? Podle položek v /proc/driver/rtc to vypadá na > rtc-cmos, ale to by bylo až moc divné. protože tam by to čtení nemělo > selhat nikdy. Co vypíše následující příkaz? > > ls -l /sys/class/rtc/rtc0/device/driver > > > > -- > Pavel Kankovsky aka Peak "Que sais-je?" > > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > -- Martin "Megac" Mokry From megacsk na gmail.com Fri Oct 30 08:24:16 2015 From: megacsk na gmail.com (Martin Mokry) Date: Fri, 30 Oct 2015 08:24:16 +0100 Subject: Cas In-Reply-To: References: Message-ID: Podla stavu sluzby je timesyncd neaktivny a zakazany: [root na localhost ~]# systemctl status systemd-timesyncd.service ? systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: disabled) Active: inactive (dead) Docs: man:systemd-timesyncd.service(8) [root na localhost ~]# 2015-10-29 20:36 GMT+01:00 Adam Pribyl : > Oct 29 08:12:16 localhost chronyd[30894]: Can't synchronise: no >> > selectable > >> sources >> Nov 1 12:57:58 localhost chronyd[30894]: Forward time jump detected! >> > > System nastartoval s hodinami 29.10. 8:12 zrejme pred uspanim a pak > najednou z niceho nic doslo ke skoku dopredu na 1.11. 12:57 (tedy o > 76h45m42s)? > > To chovani hw hodin je samozrejme take podezrele. Vypada to jako kdyz tam > bud zadne nejsou, nebo je linux nezna. > > Jeste bych pro jistotu zkontroloval jestli vam do toho nekeca > systemd-timesyncd... > > > > > On Thu, 29 Oct 2015, Martin Mokry wrote: > > hwclock pise toto: >> >> [root na localhost ~]# hwclock --show >> hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: >> Neprípustný argument >> >> Pouzivam chrony a tu je cast logu kde je vidno skok po prebudeni z uspania >> do ram: >> >> Oct 29 07:09:57 localhost chronyd[30894]: chronyd version 2.1.1 starting >> (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) >> Oct 29 07:09:57 localhost chronyd[30894]: Frequency -4.105 +/- 1.947 ppm >> read from /var/lib/chrony/drift >> Oct 29 07:09:57 localhost audit: pid=1 uid=0 auid=4294967295 >> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd >> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? >> addr=? terminal=? res=success' >> Oct 29 07:10:19 localhost chronyd[30894]: Selected source 213.160.185.89 >> Oct 29 07:10:19 localhost chronyd[30894]: System clock wrong by 7.515107 >> seconds, adjustment started >> Oct 29 07:10:19 localhost chronyd[30894]: Selected source 95.105.193.228 >> Oct 29 07:12:30 localhost chronyd[30894]: Selected source 213.160.185.89 >> Oct 29 07:40:26 localhost chronyd[30894]: Source >> 2a01:390:b:0:d6ca:6dff:fe31:9d60 replaced with 92.245.0.16 >> Oct 29 08:10:19 localhost chronyd[30894]: Source 2a00:1298:8001::6536 >> replaced with 92.240.244.202 >> Oct 29 08:12:16 localhost chronyd[30894]: Source 87.244.233.3 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 95.105.193.228 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 91.212.112.71 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 92.240.244.202 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 2a00:10d8:10:3::202 >> offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 92.245.0.16 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 81.89.61.115 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Source 213.160.185.89 offline >> Oct 29 08:12:16 localhost chronyd[30894]: Can't synchronise: no selectable >> sources >> Nov 1 12:57:58 localhost chronyd[30894]: Forward time jump detected! >> Nov 1 12:58:01 localhost chronyd[30894]: Source 87.244.233.3 online >> Nov 1 12:58:01 localhost chronyd[30894]: Source 95.105.193.228 online >> Nov 1 12:58:01 localhost chronyd[30894]: Source 91.212.112.71 online >> Nov 1 12:58:01 localhost chronyd[30894]: Source 92.240.244.202 online >> Nov 1 12:58:01 localhost chronyd[30894]: Source 2a00:10d8:10:3::202 >> online >> Nov 1 12:58:01 localhost chronyd[30894]: Source 92.245.0.16 online >> > > Nov 1 12:58:01 localhost chronyd[30894]: Source 81.89.61.115 online >> Nov 1 12:58:01 localhost chronyd[30894]: Source 213.160.185.89 online >> Nov 1 13:00:12 localhost chronyd[30894]: Selected source 213.160.185.89 >> Nov 1 13:00:12 localhost chronyd[30894]: System clock wrong by >> -244800.492492 seconds, adjustment started >> Nov 1 13:01:15 localhost chronyd[30894]: Selected source 95.105.193.228 >> Nov 1 13:02:05 localhost chronyd[30894]: chronyd exiting >> Nov 1 13:02:05 localhost audit: pid=1 uid=0 auid=4294967295 >> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd >> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? >> addr=? terminal=? res=success' >> Nov 1 13:02:05 localhost audit: pid=1 uid=0 auid=4294967295 >> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd >> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? >> addr=? terminal=? res=success' >> Oct 29 17:02:56 localhost chronyd[858]: chronyd version 2.1.1 starting >> (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) >> Oct 29 17:02:56 localhost chronyd[858]: Frequency -3.494 +/- 1.080 ppm >> read >> from /var/lib/chrony/drift >> Oct 29 17:02:56 localhost audit: pid=1 uid=0 auid=4294967295 >> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=chronyd >> comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? >> addr=? terminal=? res=success' >> Oct 29 17:03:42 localhost chronyd[858]: Selected source 92.245.0.16 >> Oct 29 17:03:42 localhost chronyd[858]: System clock wrong by 17.677506 >> seconds, adjustment started >> Oct 29 17:03:42 localhost chronyd[858]: System clock was stepped by >> 17.677506 seconds >> >> >> Pocas hore uvedeneho vypisu som po prebudeni manualne vypol >> synchronizaciu, >> nastavil spravny datum a priblizny cas a potom znovu zapol synchronizaciu. >> >> 2015-10-29 15:41 GMT+01:00 Miroslav Pragl : >> >> hwclock je po resume take posunuty? >>> >>> MP >>> >>> >>> _______________________________________________ >>> Linux mailing list >>> Linux na linux.cz >>> http://www.linux.cz/mailman/listinfo/linux >>> >>> >> >> >> -- >> Martin "Megac" Mokry >> _______________________________________________ >> Linux mailing list >> Linux na linux.cz >> http://www.linux.cz/mailman/listinfo/linux >> >> > Odchozi zprava neobsahuje viry, protoze nebyla odeslana z Windows. > Otestovano zdarma a legalne na OS Linux. > (Proc pouzivat Linux - http://proc.linux.cz/). > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > -- Martin "Megac" Mokry From peak na argo.troja.mff.cuni.cz Fri Oct 30 10:34:53 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Fri, 30 Oct 2015 10:34:53 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Fri, 30 Oct 2015, Martin Mokry wrote: > [root na localhost ~]# ls -l /sys/class/rtc/rtc0/device/driver > lrwxrwxrwx. 1 root root 0 okt 30 2015 /sys/class/rtc/rtc0/device/driver -> > ../../../bus/pnp/drivers/rtc_cmos To je fakt hodně divné. Čtení hodin dělá funkce cmos_read_time, která z principu nemůže chybu vrátit (končí příkazem "return 0"). Ještě připadá v úvahu možnost, že chyba nastane jinde. __rtc_read_time může tuto chybu chybu vrátit, pokud by driver nenabízel funkci na čtení času, ale to by v případě rtc_cmos bylo možné jen tehdy, pokud by něco vynulovalo položku v jeho tabulce. To je nepravděpodobné (i když ne zcela nemožné). Pokud máte dostatečně čerstvé jádro (cca >= 3.19), tak by to ještě mohlo selhat, když __rtc_read_time zavolá rtc_valid_tm, aby se zkontrolovalo, zda jsou údaje získané z driveru smysluplné. Pokud máte nějaký divný hardware, tak je možné, že vrací údaje, které to považuje za nesmysly. V logu by se měla objevit hláška "read_time: rtc_time isn't valid", ovšem máte-li opravdu čerstvé jádro (cca >= 4.1), tak tam je ta hláška degradována z dev_err na dev_dbg, a tudíž její viditelnost záleží na nastavení jádra i systémových logů. Takže otázka zní, jaké máte přesně jádro, jak je nastavené logování a zda se v logu neobjevují nějaké protesty ohledně "read_time. (Ano, psal jste, že je to Fedora 22, ale nechce se mi teď zjišťovat, jak to tam přesně je.) Také je otázka, jaký máte hardware a zda to na něm dřív fungovalo lépe. Také zkuste "hwclock --show --directisa". Nevím, jestli to ještě funguje, ale pokud ano, tak by to mělo přimět hwclock, aby zkusil hodiny přečíst přímo z hardwaru. -- Pavel Kankovsky aka Peak "Que sais-je?" From megacsk na gmail.com Fri Oct 30 11:28:55 2015 From: megacsk na gmail.com (Martin Mokry) Date: Fri, 30 Oct 2015 11:28:55 +0100 Subject: Cas In-Reply-To: References: Message-ID: Priame nacitanie casu zafungovalo: [root na localhost ~]# hwclock --show --directisa Pi 30. október 2015, 12:16:03 CET .719576 seconds Verzia jadra je: Linux version 4.2.3-200.fc22.x86_64 ( mockbuild na bkernel01.phx2.fedoraproject.org) (gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) ) #1 SMP Thu Oct 8 03:23:55 UTC 2015 Hardware je notebook ASUS. Uz mi to robi problem dlhsiu dobu, ale davnejsie (bohuzial nepametam si kedy) to fungovalo normalne. 2015-10-30 10:34 GMT+01:00 Pavel Kankovsky : > On Fri, 30 Oct 2015, Martin Mokry wrote: > > [root na localhost ~]# ls -l /sys/class/rtc/rtc0/device/driver >> lrwxrwxrwx. 1 root root 0 okt 30 2015 /sys/class/rtc/rtc0/device/driver >> -> >> ../../../bus/pnp/drivers/rtc_cmos >> > > To je fakt hodně divné. > > Čtení hodin dělá funkce cmos_read_time, která z principu nemůže chybu > vrátit (končí příkazem "return 0"). > > Ještě připadá v úvahu možnost, že chyba nastane jinde. > > __rtc_read_time může tuto chybu chybu vrátit, pokud by driver nenabízel > funkci na čtení času, ale to by v případě rtc_cmos bylo možné jen tehdy, > pokud by něco vynulovalo položku v jeho tabulce. To je nepravděpodobné (i > když ne zcela nemožné). > > Pokud máte dostatečně čerstvé jádro (cca >= 3.19), tak by to ještě mohlo > selhat, když __rtc_read_time zavolá rtc_valid_tm, aby se zkontrolovalo, zda > jsou údaje získané z driveru smysluplné. Pokud máte nějaký divný hardware, > tak je možné, že vrací údaje, které to považuje za nesmysly. > V logu by se měla objevit hláška "read_time: rtc_time isn't valid", ovšem > máte-li opravdu čerstvé jádro (cca >= 4.1), tak tam je ta hláška > degradována z dev_err na dev_dbg, a tudíž její viditelnost záleží na > nastavení jádra i systémových logů. > > Takže otázka zní, jaké máte přesně jádro, jak je nastavené logování a zda > se v logu neobjevují nějaké protesty ohledně "read_time. (Ano, psal jste, > že je to Fedora 22, ale nechce se mi teď zjišťovat, jak to tam přesně je.) > > Také je otázka, jaký máte hardware a zda to na něm dřív fungovalo lépe. > > Také zkuste "hwclock --show --directisa". Nevím, jestli to ještě funguje, > ale pokud ano, tak by to mělo přimět hwclock, aby zkusil hodiny přečíst > přímo z hardwaru. > > > > -- > Pavel Kankovsky aka Peak "Que sais-je?" > > _______________________________________________ > Linux mailing list > Linux na linux.cz > http://www.linux.cz/mailman/listinfo/linux > -- Martin "Megac" Mokry From megacsk na gmail.com Sat Oct 31 07:38:37 2015 From: megacsk na gmail.com (Martin Mokry) Date: Sat, 31 Oct 2015 07:38:37 +0100 Subject: Cas In-Reply-To: References: Message-ID: Neviem preco, ale dnes sa mi cas po nocnom spanku v ram posunul len o 2 hodiny dopredu, nie o 3 dni a niekolko hodin, teda namiesto nejakych 7:33 na 9:33. Zauimave. -- Martin "Megac" Mokry From peak na argo.troja.mff.cuni.cz Sat Oct 31 23:41:22 2015 From: peak na argo.troja.mff.cuni.cz (Pavel Kankovsky) Date: Sat, 31 Oct 2015 23:41:22 +0100 (CET) Subject: Cas In-Reply-To: References: Message-ID: On Fri, 30 Oct 2015, Martin Mokry wrote: > Priame nacitanie casu zafungovalo: > > [root na localhost ~]# hwclock --show --directisa > Pi 30. október 2015, 12:16:03 CET .719576 seconds Takže to nějak funguje... Ale jádro ty údaje kdovíproč nepřežvýká... Zkuste nainstalovat SystemTap a uložit níže přiložený skript do souboru, řekněme rtc.stp, a pak provést "stap rtc.stp", jinde spustit něco, co sáhne na RTC (např. již zmíněný příkaz "cat /proc/driver/rtc"), a pak se podívat na to, co vypsal ten stap? Mělo by to správně vyprodukovat něco jako: cmos_read_time --> 0 rtc_valid_tm: *tm = { sec:7, min:31, hour:22, mday:31, mon:9, year:115, wday:0, yday:0, isdst:0 } --> 0 __rtc_read_time --> 0 rtc_read_time --> 0 A tady je ten slíbený rtc.stp: ---snip--- probe kernel.function ("cmos_read_time").return { printf("cmos_read_time --> %d\n", $return); } probe kernel.function ("rtc_valid_tm").return { printf("rtc_valid_tm: *tm = { sec:%d, min:%d, hour:%d, mday:%d, mon:%d, year:%d, wday:%d, yday:%d, isdst:%d } --> %d\n", $tm->tm_sec, $tm->tm_min, $tm->tm_hour, $tm->tm_mday, $tm->tm_mon, $tm->tm_year, $tm->tm_wday, $tm->tm_yday, $tm->tm_isdst, $return); } probe kernel.function ("__rtc_read_time").return { printf("__rtc_read_time --> %d\n", $return); } probe kernel.function ("rtc_read_time").return { printf("rtc_read_time --> %d\n", $return); } ---snip--- -- Pavel Kankovsky aka Peak "Que sais-je?"