Re: Debilni chovani logrotate v Centos 7
Pavel Kankovsky <[email protected]>
| Newsgroups | gmane.linux.region.czech |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 5 Apr 2018, Petr Simek wrote: > On Thu, 5 Apr 2018, Pavel Kankovsky wrote: > >> On Sun, 1 Apr 2018, Petr Simek wrote: >> >> > jsem trochu nestastny z chovani logrotate v novem Centosu 7. U logu >> > kde ma definovano 'rotate monthly' mi to vzdy na jare po zmene casu >> > Z->L zrotuje dvakrat. Jednou ve stredu nasledujici po nedeli kdy se >> > menil cas a pak jeste spravne 1.4. : [...] >> >> To je fakt zvláštní. Asi by bylo potřeba to zkusit nasimulovat a >> sledovat, co se tam děje. > > Kolega co provozuje RedHat7 mi potvrdil ze se to chova stejne. A na Debianu > ty mesicni logy rotuji taky blbe, jemu to navic zrotovalo > mesic jeste nekdy 3.ledna . Když psa říkal "nasimulovat a sledovat, co se tam děje", tak jsem měl na mysli přesně to, co jsem psal. Jistý pan Alex Hornby byl tak laskav, že už vynalezl příkaz "dateshift", a tak jsem nebyl nucel toto kolo vynalézat znovu a mohl jsem si to rychle vyzkoušet, jak by to dopadlo, kdyby logrotate nastavil na měsíční rotaci nějakého logu a pak simuloval jeho spouštění někdy od konce ledna až do dnešního dne. Připojím zkrácenou ukázku toho, co se tam stalo: ==== 2018-03-23 03:41:01 ==== log does not need rotating (log has been rotated at 2018-3-1 2:45, that is not month ago yet) ==== 2018-03-24 03:23:01 ==== log does not need rotating (log has been rotated at 2018-3-1 2:45, that is not month ago yet) ==== 2018-03-25 03:13:01 ==== log does not need rotating (log has been rotated at 2018-3-1 1:45, that is not month ago yet) ==== 2018-03-26 03:07:01 ==== log does not need rotating (log has been rotated at 2018-3-1 0:45, that is not month ago yet) ==== 2018-03-27 03:35:01 ==== log needs rotating Problémem je nějaká zmatená interpretace časových údajů v souboru logrotate.status: jakmile dojde ke změně na letní čas, tak to přečtený údaj interpretuje o hodinu posunutý do minulosti a s tímto posunem ho zapíše i do souboru. Každý den se to posune o hodinu zpět v čase, až se to dostane do jiného měsíce, a pak několik dní po přechodu na letní čas dojde k zmatečné rotaci! Problém je konkrétně ve funkci readState, která logrotate.status načítá. Ta se pokouší přečtené údaje interpretovat funkcí mktime, ale nenamáhá se řádně nastavit tm_isdst. Opět se zdá, že to už upstream logrotate opravil, ale distribuce to má pořád ve vadné verzi: <https://github.com/logrotate/logrotate/commit/9c68d75c729b926e2c70bc579a12e58e472abf57> (Druhým problémem je pak zmatená interpretace v zmíněném programu dateshift, který časové údaje před změnou na letní čas interpretuje posunuté o hodinu, a proto to začínalo na 2:45. To je, mimochodem, také problém s tím, že nenastavuje tm_isdst na -1, ale nechává tam hodnotu z aktuálního času.) Možná by se to mělo poslat Evropské komisi jako doklad toho, že letní čas by měl být zrušen jako zbytečný zdroj zmatků. :) > No ja bych weekly chapal podobne jako monthly , tedy v nejaky konkretni > den v tydnu. Tenhle komplikovany algoritmus ktery umoznuje nepravidelnou > rotaci je uchylny. Takto nějak je to předělané v tom commitu, který jsem zmiňoval. Nelze to udělat úplně jednoduše, protože je potřeba ošetřit případ, že logrotate ten den propásne. U monthly stačí porovnat měsíc a rok, u weekly by se muselo pracovat s něčím jako je číslo týdne a to by bylo komplikované. > Ale museli to zmenit protoze jeste v Centos6 se to nedeje a rotuje ze > vzdy v nedeli. Tu změnu má na svědomí zavedení časových údajů v logrotate.status. Předtím tam bylo jen datum a změna času spuštění logrotate o pár minut nehrála žádnou roli. -- Pavel Kankovsky aka Peak "Que sçay-je?" _______________________________________________ Linux mailing list [email protected] http://www.linux.cz/mailman/listinfo/linux