[C] Hoe te ontdekken of file gerenamed is

[zeroxcool]

Ik ben bezig om de log van de Boa webserver enigzins aan te passen, zodat enkel en alleen dingen die ik van toepassing vind, gelogd worden. Dit werkt prima. Nou is er alleen het volgende probleem:

Boa draait en alle requests worden gelogd. Als ik dan de bijbehorende access log wil gaan gebruiken ergens voor doe ik bij wijze van spreke iets als een move van de access_log naar temp_log en een touch voor de access_log. Het probleem is echter dat Boa nu niets meer logt in de access_log, maar in die temp_log. Iets wat ik absoluut niet wil hebben aangezien de logs files tussendoor nogal snel kunnen groeien.

Wat ik dus eigenlijk wil is dat als de file gerenamed is hij gewoon de access_log file blijft loggen en niet de renamede file (temp_log).

Nou is in de functie welke de access log regels schrijft wel een check of de file descriptor bestaat, maar deze bestaat uiteraard. De vraag is daarom, kun je zulke dingen afvangen danwel ontdekken, zoja, hoe?

[ Voor 4% gewijzigd door zeroxcool op 08-11-2004 12:51 ]

[Soultaker]

De webserver houdt het bestand open, en kan er dus nog in schrijven als jij 'm verplaatst (zelfs als je de permissies aanpast, denk ik). De oplossing is om na het verplaatsen van het bestand Boa een schop te geven zodat 'ie het logbestand opnieuw opent (via de originele bestandsnaam).

Bij de meeste daemons kun je dit voor elkaar krijgen door een HUP-signaal te versturen. Het kan zijn dat er dan wat meer gebeurt dan alleen het heropenen van de logfiles, zoals het opnieuw inlezen van de configuratie en het herstarten van child processes.

[igmar]

ZeRoXcOoL schreef op 08 november 2004 @ 12:50:
Wat ik dus eigenlijk wil is dat als de file gerenamed is hij gewoon de access_log file blijft loggen en niet de renamede file (temp_log).

Dat kan niet, je hebt al een descriptor, en de kernel zal het echt worst wezen dat je die file hernoemt. Ik zou SIGHUP afvangen, en dan alle logfiles sluiten en opnieuw openen.

Nou is in de functie welke de access log regels schrijft wel een check of de file descriptor bestaat, maar deze bestaat uiteraard. De vraag is daarom, kun je zulke dingen afvangen danwel ontdekken, zoja, hoe?

Met stat() moet dat te doen zijn, alleen ikzelf ben van mening dat dit het probleem is van degene die de file hernoemd, die moet de daemon ook meteen maar een schop geven

[zeroxcool]

Soultaker schreef op 08 november 2004 @ 13:32:
De webserver houdt het bestand open, en kan er dus nog in schrijven als jij 'm verplaatst (zelfs als je de permissies aanpast, denk ik). De oplossing is om na het verplaatsen van het bestand Boa een schop te geven zodat 'ie het logbestand opnieuw opent (via de originele bestandsnaam).

Bij de meeste daemons kun je dit voor elkaar krijgen door een HUP-signaal te versturen. Het kan zijn dat er dan wat meer gebeurt dan alleen het heropenen van de logfiles, zoals het opnieuw inlezen van de configuratie en het herstarten van child processes.

Natuurlijk, ontzettend stom van me om daar niet aan te denken. En het 'probleem' dat er wordt doorgelogd in de temp log file komt zo juist helemaal goed uit, zo gaat er namelijk nooit iets verloren in de kwart seconde dat je server uit zou moeten staan als je het met een normale restart zou doen.

Ik kwam er trouwens achter dat sinds enkele versies geleden de herstart van de log files eruit was gehaald:

C:

    /* Philosophy change for 0.92: don't close and attempt reopen of logfiles,
     * since usual permission structure prevents such reopening.
     */

Daar heb ik uiteraard verandering in gebracht .

igmar schreef op 08 november 2004 @ 13:35:
Dat kan niet, je hebt al een descriptor, en de kernel zal het echt worst wezen dat je die file hernoemt. Ik zou SIGHUP afvangen, en dan alle logfiles sluiten en opnieuw openen.

Dat had ik door .

Met stat() moet dat te doen zijn, alleen ikzelf ben van mening dat dit het probleem is van degene die de file hernoemd, die moet de daemon ook meteen maar een schop geven

Was inderdaad een manier geweest. Maar dat laatste zinsdeel was uiteraard nog beter.

Bedankt beide!