Debilni chovani logrotate v Centos 7
Pavel Kankovsky
peak na argo.troja.mff.cuni.cz
Čtvrtek Duben 5 21:17:55 CEST 2018
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?"
Další informace o konferenci Linux