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ýpoičné sluby pre jednotlivcov a partnerstvá, ponúkame pôičky s úrokovou sadzbou 3%. od 10 000 EUR na 25 000 , 000,00, a kadá mena, naa 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ť niie 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?"