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