[OSM-Devserver] incron und aio

[Christoph Wagner]

Sven Geggus schrieb:

>> Ach ja - und gibt es eigentlich eine Logdatei, wo ich nachsehen könnte,
>> was mit incron schief gelaufen ist?
> 
> /var/log/syslog
> 

> Ich hab Dich mal in dei adm Gruppe getan, damit Du die logfiles in /var/log/
> lesen darfst.
> 


Das scheint schon mal nicht geklappt zu haben:
$ tail /var/log/syslog
tail: „/var/log/syslog“ kann nicht zum Lesen geöffnet werden: Permission denied


Jochen Topf schrieb:
>>> Hat ich eh vor. Mal schaun, ob das läuft. Ich glaub am Parameter liegts
>>> nicht. Wie genau wird denn das geofabrik zeugs erstellt? Wird das
>>> irgendwie dahin kopiert und wenn ja wie?
>> Fred macht das glaub ich mit rsync.
>
> rsync schreibt ein neues bzw. tmp File und macht ein rename, wenn er fertig
> ist. Keine Ahnung, wie man das dem incron beibringt.

Der Incronspaß hat wieder nicht geklappt. Womöglich ist der rename das Problem.
Da scheint der nicht so recht mit klar zu kommen.

Ist mir völlig unklar, warum das bei Sven mal funktioniert hat und bei mir nicht.

Lustigerweise funktioniert meine andere Zeile in der incrontab wunderbar und haiti wird gebaut.

/osm/garmin/aio/haiti/raw_data/haiti.osm.bz2 IN_CLOSE_WRITE baue_haiti

Allerdings wird die zu triggernde datei mit wget überschrieben:
wget -q -O/osm/garmin/aio/haiti/raw_data/haiti.osm.bz2 http://labs.geofabrik.de/haiti/latest.osm.bz2

Da wird nix umbenannt. Bei den geofabrik sachen muss noch irgendwas prinzipiell anders laufen.
Ich vermute der triggert dann gar kein IN_CLOSE_WRITE, wenn der das file umbenennt
/osm/geofabrik-extrakte/europe.osm.bz2 IN_CLOSE_WRITE /osm/garmin/aio/muppdeht.sh

Wird dann eigentlich das ganze Verzeichnis einfach umbenannt oder wie funktioniert das ganz genau?

Ich hab gerade mal in der inotify FAQ geschaut:
http://inotify.aiken.cz/?section=inotify&page=faq&lang=en

# Q: Is it better to use IN_MODIFY or IN_CLOSE_WRITE?
It varies from case to case. Usually it is more suitable to use IN_CLOSE_WRITE because if emitted the all changes on the appropriate file are safely written inside the file. The IN_MODIFY event needn't mean that a file change is finished (data may remain in memory buffers in the application). On the other hand, many logs and similar files must be monitored using IN_MODIFY - in such cases where
these files are permanently open and thus no IN_CLOSE_WRITE can be emitted.
# Q: Why doesn't work IN_MODIFY nor IN_CLOSE_WRITE on my file?
There is probably a program which doesn't save changes directly into the original file. It creates a temporary file instead, saves data into it and after closing it renames the file to the name of the original one. It is safer but complicates monitoring. The exact mechanism of working with files must be investigated (tools like strace can be useful) and the monitoring setup must be tailored to it.


Möglicherweise brauche ich zum triggern eines von diesen schönen Events:

IN_MOVE_SELF: Watched file/directory was itself moved
IN_MOVED_FROM: File moved out of watched directory
IN_MOVED_TO: File moved into watched directory

Am Wochenende bin ich leider nicht zum testen da.
Vielleicht findet es ja jemand anderes raus, wie das bei den geofabrik extrakten genau klappt.

Und ja - ich denke incron ist genau das, was man eigentlich braucht. Alle 30 min mit cron zu testen, finde ich irgendwie doof.
Muss doch gehen!

Grüße
Christoph

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.openstreetmap.de/pipermail/devserver/attachments/20100326/d2c59411/attachment.pgp>