Striplog.pl en huidige datum

[Burat]

Een vraag over striplog.pl, een script wat meer mensen hier gebruiken om de log files wat te verkleinen en ip-ranges aan 1 naam te koppelen.

Volgens mij gaat er iets redelijk mis met dit script. Op een of andere manier gaat ie niet goed met de tijd om. Volgens m'n personal proxy is het hier nog 23:00, terwijl het op de pc al 1:00 is. Het lijkt erop dat de logfile van 5-oktober al bekeken wordt door striplog, terwijl de personal proxy nog naar 4 oktober schrijft.. Dit omdat alles wat tussen 0:00 en 2:00 geflusht wordt enorm bout. Ik heb nu even alle logs opnieuw gebouwd, en er komen blokjes bij .

Weet iemand wie het gemaakt heeft? Die zal namelijk wel weten of het alleen bij mij bout of dat dit een echte bug is..

Tnx iig.

[Verwijderd]

Wel eens gehoord van GMT of UTC?????
Betekent bijde het zelfde, en is bedoeld om de tijden over de hele wereld gelijk te houden.
Wij leven hier in zomertijd=GMT+2 de amerikanen leven in een andergebied GMT-7 of meer.

Dit is geen bug van het programma maar gewoon een standaard gegeven.

[Burat]

Ya schat, da snap ik. Maar ik vraag me af (omdat veel lui het gebruiken) of (en zo niet waarom niet) het script daar rekening mee houdt..

[0rbit]

Het maakt toch geen reet uit? De dag schuift gewoon 2 uurtjes op... Goh... erg hoor

[Burat]

Jou niet snap mij probleem.

De dag van de perproxy schuift 2 uurtjes op. Maar de dag van het striplog script schuift (volgens mij dan) NIET 2 uurtjes op. Dus het script kijkt al niet meer naar 4 oktober (omdat het daar al 5-10 is) terwijl de perproxy nog wel blokjes binnenkrijgt en die op die datum wegschrijft..

En die blokjes worden niet meer geindexeerd.

[0rbit]

Het script van de ppstats doet precies hetzelfde; dat werkt ook perfect...

[pinball]

D'r zit wel een kern van waarheid in, maar dat dat ligt ook voornamelijk aan de timing (scheduling) van ppstats en striplog.

Ik heb zelf zoiets:

23.00 .10 .20 .30 .40 .50 ---> ppstats
23.09 .19. 29 .39 .49 .59 ---> striplog

blokjes die na 23.59 (in de laatste minuut van de dag dus) binnenkomen worden dan idd niet geteld.

Daar moet idd wat aan gedaan worden, doe ik als ik tijd heb. (en zoals altijd geld: als iemand anders het beter/sneller kan: graag )

De quick en (erg) dirty oplossing is de volgende:

1.maak een kopie van striplog (striplog2.pl oid)
2.zoek in die kopie de regel:
( $sec, $min, $hour, $mday, $month, $year, $wday) = nice_time(time);
3. maak daarvan:
( $sec, $min, $hour, $mday, $month, $year, $wday) = nice_time((time-86400));

4. schedule striplog2 1 keer per dag om 02.01

Zo verwerkt ie het hele log van de vorige dag nog 1 keer.

Dit helpt ook meteen tegen het probleem wat ik hier beschreef, hoewel het niet dé oplossing is.

* pinball vraagt dit jaar aan sinterklaas 8 uur per dag extra om fatsoenlijk te leren proggen

[Burat]

Ik heb gewoon een .bat file gemaakt die eerst striplog draait en dan de stats. Dan glipt er heeeul weinig tussendoor (scheelt 0,5 seconde ofzo).

Dat probleem is dan redelijk opgelost. En de blokjes die je in die 0,5 seconde mist komen dan volgende 'ronde' wel.

Mijn probleem is nog steeds NIET duidelijk!

In jouw voorbeeld ga je ervan uit dat de klokken van de proxy en het script gelijk lopen. Dus om precies 0:00 begint de proxy aan het de script van de volgende dag en vanaf precies 0:00 gaat het script de logs van de volgende dag processen.

Dat LIJKT volgens mij NIET zo te zijn.

De proxy gaat nog tot 2:00 door (das 0:00 GMT) met het schrijven naar de log van VORIGE dag, terwijl het script al die van de dag erna leest (het is tenslotte op de pc al 0:00 geweest).

Met jouw voorbeeld:

23.00 .10 .20 .30 .40 .50 ---> ppstats
23.09 .19. 29 .39 .49 .59 ---> striplog

Mist ie dus niet alles van de laatste minuut, maar van de laatste 2 uur en 1 minuut. om 23:59 maakt striplog nog de log van 4 oktober, maar om 0:09 die van 5 oktober. PPstats maakt om 23:50 die van 4 oktober en om 0:00 die van 5 oktober. Leuk, maar om 1:00 komen er nog steeds blokjes binnen op 4 oktober! Omdat de perproxy 'het' nog 4 oktober heeft (GMT!).

Naja, misschien kan ik of niet uitleggen, of ik ben volslagen idioot, of ik programmeer 'm er zelf wel uit..

[NightBird]

Is het niet gewoon zo dat het striplog.pl script ook met UTC tijd werkt, net zoals ppstats?

K denk het haast wel gezien alle reacties.

[Verwijderd]

Kijk eens naar de tijden van de log files.
Ik krijg hier als laatste toevoegings datum en tijd vn de log van 4 oktober de datum/tijd: 5-10-2000 1:51
met andere woorden: pproxy schrijft de spullen die voor 4 okt. binnen gekomen wel degenlijk weg in de logfile van 4 okt. of dit nu gebeurt van 2.00 tot 24.00u op 4 okt. of van 0.00 tot 2.00 op 5 okt. maakt dat programma niets uit.
volgens GMT is dat allemaal 4 okt.

Ben alleen benieuwt wat hij gaat doen met de zomer/wintertijd verandering.
Zal wel weer wat in de ini file moeten veranderen.

[Burat]

Naja.. Ik draai nu gewoon altijd het script van vandaag en van gisteren.

[The Wizard]

Het klopt precies wat je zegt Burat, de tijden van striplog en de proxy lopen niet gelijk waardoor je een uur misloopt. (in de zomer 2 uur).

[Verwijderd]

onder het motto "oude koeien uit de sloot halen" :?:?

[pinball]

Wel terechte koeien overigens

ff korte uitleg:

Op mijn eigen proxy werd nooit 's nachts geflutst. In de eerste versie van striplog gebruikte ik dan ook zonder problemen de local-time functie van perl. (local is bij mij dus NL tijd).

Toen striplog ook door 24-uurs proxies gebruikt ging worden (en de mijne ook 24/7 ging draaien) kwam iemand erachter dat er rond 24.00 uur wat misging. Door
my @gmt = localtime(shift @_);
in
my @gmt = gmtime(shift @_);
te veranderen was dat probleem (tijdelijk) opgelost.

UTC heeft nl. de (in dit geval vervelende) eigenschap dat het geen zomer/wintertijd kent, dus sinds GMT naar de wintertijd is gegaan kloppen de tijden niet meer.

Door in striplog
( $sec, $min, $hour, $mday, $month, $year, $wday) = nice_time(time);
te vervangen door:
( $sec, $min, $hour, $mday, $month, $year, $wday) = nice_time(time - 3600);
klopt alles weer.

De oplettende lezer heeft intussen opgemerkt dat dit een tijdelijke fix is, als GMT weer naar zomertijd gaat (waneer is dat?) moet (time-3600) weer (time) worden.

[Verwijderd]

Op zondag 14 januari 2001 21:39 schreef Pinball het volgende:
Op mijn eigen proxy werd nooit 's nachts geflutst.

foei?

[NightBird]

Op zondag 14 januari 2001 21:39 schreef Pinball het volgende:
UTC heeft nl. de (in dit geval vervelende) eigenschap dat het geen zomer/wintertijd kent, dus sinds GMT naar de wintertijd is gegaan kloppen de tijden niet meer.

Door in striplog
( $sec, $min, $hour, $mday, $month, $year, $wday) = nice_time(time);
te vervangen door:
( $sec, $min, $hour, $mday, $month, $year, $wday) = nice_time(time - 3600);
klopt alles weer.

Als je er dit van maakt denk ik dat het een permanente oplossing zal zijn

code:

($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time);
if ($isdst) {
  ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time-3600);
}

[pinball]

Dat is em precies

Zenks!

[The Wizard]

Thanx!

[The Wizard]

hmm.. als ik het verander dan doet striplog het niet meer... Hij voegt dan niks meer toe aan de striplog file.