Technologie inotify: události IN_MODIFY a IN_CLOSE

První článek na první pohled není až tak úplně "jaderný". Bude se totiž týkat dvou souborových událostí, které lze sledovat prostřednictvím linuxově specifické technologie inotify. Dostávám totiž poměrně dost dotazů na to, jak vlastně tyto události fungují a kdy kterou použít.

Jak se můžete dočíst v knize (nebo třeba na webu technologie inotify), jádro umožňuje snadno sledovat změny na souborech, a to buď zastaralou technologií dnotify mající řadu neduhů, anebo modernější technologií inotify, o které bude nyní řeč. Monitorovat lze celou řadu různých druhů událostí - nejčastěji se ale sledují změny v souborech, proto právě toto bývá předmětem nejasností a pochyb o správném použití.

Typický případ je takový, že má někdo nějaký soubor a po změně v něm chce provést nějakou operaci - například soubor zálohovat, informovat běžícího démona, odeslat notifikaci uživateli, něco někam zaznamenat apod. Jenže změn v souborech se týkají dvě různé události: IN_MODIFY a IN_CLOSE_WRITE. Každá sleduje něco úplně jiného a každá se proto hodí pro jiné případy.

IN_MODIFY

IN_MODIFY je událost, kterou jádro posílá odběrateli v okamžiku, kdy dojde ke změně v souboru. Není důležité, jakou formou (jakým voláním apod.) ke změně došlo. Prostě dojde k změně souboru (tak, jak je vidět v souborovém systému) a pošle se událost IN_MODIFY.

Co z toho vyplývá? Každá změna vyvolá jednu událost. Program například stokrát zavolá write(), čili se stokrát pošle IN_MODIFY. Ovšem pozor - pokud se používají knihovní funkce (fputs(), fprintf(), metody streamů C++ apod.), nemusí každé zavolání takové funkce vést na volání jádra, čili zápis reálně neproběhne (proběhne pouze do bufferu v programu, ne do souboru). Ke skutečnému zápisu by došlo až při zavření souboru, při naplnění bufferu nebo při zavolání fflush() a podobně.

Z tohoto důvodu je tedy událost IN_MODIFY u běžných aplikací těžko predikovatelná. Další problém spočívá v tom, že zapsaná data obecně nemusí být konzistentní. Zapíše se třeba jen část, zbývající data zůstanou v aplikačním bufferu. Proto je lepší se používání IN_MODIFY vyhnout, pokud není vážný důvod ji používat - ještě se o tom zmíním.

IN_CLOSE_WRITE

Tato událost se naopak posílá při zavírání souboru po změně (resp. obecně po zavření souboru otevřeného k zápisu). Pokud sledující program obdrží událost IN_CLOSE_WRITE, znamená to, že všechny změny, které mohl provést program, který měl soubor otevřen, už byly do souboru zapsány a ten je tedy konzistentní (v tuto chvíli neřeším případ, že někdo stihne soubor znovu otevřít a změnit ještě před zpracováním události zavření).

Ve většině případů je vhodné použít právě IN_CLOSE_WRITE, nikoli IN_MODIFY. Typicky se třeba změní konfigurační soubor a je potřeba uvědomit běžící aplikaci, že k této změně došlo a že si má konfiguraci znovu načíst. Pro tento případ se perfektně hodí právě IN_CLOSE_WRITE, podobně třeba pro notifikaci o uploadu souboru (důležitý je stejně okamžik dokončení transferu).

Existuje ale nejméně jedna třída situací, kdy se IN_CLOSE_WRITE použít nedá. Je to v případě souborů, které si program (démon) otevře soubory (typicky logy) při svém startu a až do ukončení je má stále otevřené, přičemž do nich podle potřeby zapisuje. Pak máme jedinou možnost, a to použít IN_MODIFY, protože IN_CLOSE_WRITE se pošle obvykle až někdy při ukončování běhu systému.

Důležité pak je, ohlídat si, aby program do souboru zapisoval tak, aby byl soubor konzistentní. Logovací démony, podobně jako různé programy s vlastní implementací logování, jsou v tomto ohledu obvykle bezpečné. Každopádně je dobré si to předem zkontrolovat.

Nefunguje to!

Může se stát, že se někdo bude snažit sledovat změny v souboru ať už pomocí IN_MODIFY nebo IN_CLOSE_WRITE, a ono to nebude fungovat. To se stává v případě, že program místo přímého zápisu do souboru vytváří dočasné pracovní soubory, zapisuje do nich (třeba průběžně) a po uzavření dočasného souboru ho přejmenuje na původní soubor. Například některé editory to tak dělají.

Takové řešení je sice bezpečnější (při pádu programu není poškozen původní soubor), ale komplikuje to sledování změn. Pak je potřeba pátrat, jak ten konkrétní program se soubory pracuje (buď sledováním všech událostí v adresáři nebo pomocí nástrojů jako je strace) a podle toho pak sledování nastavit. Většinou to dopadne tak, že se sleduje událost IN_MOVED_TO.

V každém případě to vždycky chce přemýšlet, co přesně se má sledovat, v jakém okamžiku se má na změnu reagovat a jak příslušné programy se soubory pracují. Dobré rozmyšlení může předejít pozdějším nervům, když to nedělá to, co člověk očekává.

Diskuse k tomuto článku

V knihe sa spomína, že technológia nefunguje na všetkých FS, zvlášť nie na sieťových. Je táto informácie stále pravdivá?

23.10.2008 17:48 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Technologie inotify: události IN_MODIFY a IN_CLOSE_WRITE

Pravdivá je a v některých případech asi zůstane věčně. Sice neznám do detailu vlastnosti protokolu SMB (takže nevím, co všechno tam jde nebo nejde), ale pravděpodobně i nadále na smbfs platí, že se generují notifikace pouze pro události mající původ na stejném stroji, kde se monitoruje.

Téměř jistě platí omezení pro procfs (jak ho popisuji v knize), ovšem nemohu ručit za nejnovější jádra, protože byť jsem v žádném changelogu na takovou informaci nenarazil, teoreticky mohlo dojít ke změně.

Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly