AG>>> Currently there is no such functionality -- well, I believe you
AG>>> could do some of it using integrated Perl though.
ml>> IF perl is (still) in one's binkd, how would this be done?
AG>> I'd take a look at implementing an on_handshake trigger which drops
AG>> the connection.
ml> i don't know anything about that...
AG> I guess, you'll have to figure out the rest then. :/
sorry, but not... i'll be using a binkd that doesn't have perl stuffings in it
so they won't do me any good anyway ;)
AG>>> What about ongoing connections?
ml>> they continue until they finish and then binkd would block... it
ml>> would be good for it to also create a semaphore signalling that it
ml>> has blocked all inbound connections...
AG>> And what about outgoing connections?
ml> if they are ongoing, let them finish... new ones are stopped until
ml> the semaphore is removed...
AG> But you're aware that this state doesn't mean that the logfile is
AG> not being used anymore?
i noted in my previous post that binkd could indicate that it has closed all
files by creating a semaphore file in response to the one created to tell it to
freeze... having a semaphore to exit is one thing but i don't know that i want
binkd to just dive to the floor without finishing the current transfers...
perhaps binkd could create a BDALIVE semaphore and remove it when it exits...
this is another way that external scripts and programs could tell if binkd was
running... there might need to be two others indicating that the client is
active and one for the server being active... i'm thinking these would be
created and maintained by the main thread...
AG> So far my understanding of your objective is to rotate log files
AG> ...
in /my/ case, that is the _current_ objective but others have their reasons...
i can think of other possibilities but they are not worth discussing if these
simple items cannot be acquired :/
AG>> Under Unix that's not much of an issue, but IIRC it will require a
AG>> restart after rotating.
ml> i don't run binkd under linux but instead on OS/2... it was Warp 3
ml> Connect but i've recently been yanked kicking and screaming into
ml> the more modern world and the system is now running on eCS 2.1...
AG> ... and you're using OS/2 which basically means you'll need to
AG> shutdown binkd completely to be able to replace the logfile.
AG> Otherwise you might end up in a locking violation. Some process
AG> might be writing to it.
i've already explained that i can easily rename the log file out from under
binkd... the problem is not that... the problem is if binkd has connections
while the logfile is away and it creates a new one... now how to blend them
back together and in place for binkd to continue using?
ml> 2. grep out the data for the specified month.
ml> 3. grep out the data for the current month using the above.
AG> ... and why do you need exact month boundaries? If you really want
because i want monthly logs for one simple thing... that and monthly stats on
those logs (which is what started all of this mess for me years ago)...
AG> that, you'll need to kill all binkd processes just before midnight
AG> of the month end ... in order to make sure no process is still
AG> writing to the old file.
again... HOW! there is only the MANUAL method of hitting CTRL-C that i know of
and i do not plan on being up at the end of the month to do this manually...
nor do i plan on being up every night if i decide to do this nightly (which is
another aspect that i'm looking at for statistics)...
ml> log x:\\binkd\\bd%YYYY%mm.log
AG> That indeed sounds like a feature request. I wonder if all target
AG> platforms support strftime() ... at least C89 mandates it.
i know i've specifically mentioned if before but i'd have to go digging back in
my message base to see if i still have it... if it was over 2 years ago, i'm
sure i do not have it...
ml> and let binkd handle closing the old one and opening the new one
ml> when the time/dat rolls over... IIRC, Apache has this ability but
ml> Apache keeps the logs open and that's not a good thing at times...
AG> To be honest, the way binkd handles logfiles is not optimal ... in
AG> a multi-processing environment. If two processes open the logfile
AG> at the same time, they might overwrite each others log line ... or
AG> some other race conditions.
exactly... this is why i previously mentioned a logging routine that all
threads talked to to let /it/ do the logging and they just keep doing their
thing ;)
AG>> As you're not indicating the OS: /etc/init.d/binkd stop;
AG>> /etc/init.d/binkd start. :-> Under Windows you're most likely
AG>> running binkd as a service ... net stop and start should do the
AG>> trick.
ml> aren't those simply scripts that send some special code to binkd?
AG> Not necessarily. But usually they are sending a SIGTERM to the
AG> process ... one could also kill the process the hard way ...
the point of the question was that on *NIX those are scripts that do the heavy
lifting of sending the signal or whatever... i don't use windows for mission
critical operations so how to run binkd as a service is beyond me... but IF i
were to do such, i would NOT run it as a service because i want to _see_ it and
what it is doing ;)
ml> IME with *nix, /etc/init.d or /etc/rc.d stuff is scripts that might
ml> send a signal to the process or they might have some other way of
ml> terminating the process... again, i know of no such method that is
ml> documented in the binkd docs...
AG> What do OS functionalities have to do with binkd?
the OS provides the signaling capabilities, does it not? it seems to me that it
does in some cases...
ml> another example is that i do have EMX here and can send *nix
ml> signals to processes BUT they must be compiled with EMX for the
ml> signals to work... the watcom compiles won't respond to EMX
ml> signals...
AG> But on OS/2 DosKillProcess() will do what you want ... all you need
AG> is some command line tool which finds the relevant processes and
AG> kills those. At least I find several such tools on
AG> <http://www.os2site.com/sw/util/process/index.html>.
thanks for the link... i may take a look but this would be SOOOOOO much easier
if we could just create a simple disk-based semaphore file and the watch for
one to appear (BDFROZEN) or disappear (BDALIVE)...
IF binkd reacted to disk-based sepamhores, and if it knew called bdexit.15 was
for exiting with errorlevel 15, then we might have something like this in the
binkd controller script...
@echo off
rem set the screen to 120 columns and 50 lines
mode 120 50
cdd x:\binkd
:loop1
binkd2e -C binkd.cfg
if errorlevel EQ 15 goto logmaint
if errorlevel EQ 3 goto loop1
goto end
:logmaint
sleep 5
if not exist x:\path\to\semaphores\foo.bar goto loop1
goto loop2
:end
echo binkd controller script terminating...
then in our processing script, we might have something like this...
@echo off
rem let's set our we're alive semaphore before continuing
if exist x:\path\to\semaphores\foo.bar goto running
echo.>x:\path\to\semaphores\foo.bar
rem let's kill binkd before tearing the logs to shreds
echo.>x:\path\to\semaphores\bdexit.15
:loop
sleep 5
if not exist x:\path\to\semaphores\bdalive.* goto good
echo waiting on binkd to quit...
goto loop
:good
rem now that binkd is not running, let's get those logs analyzed
[analysis code here]
rem now let's start binkd back up by removing our semaphore
del x:\path\to\semaphore\foo.bar
goto end
:running
echo we're already running... good bye!
:end
echo %0 terminating...
or something like that... i don't recall the errorlevels that binkd exits
with... i can't remember what that errorlevel 3 is for nor what a normal CTRL-C
exit uses... the real controller script would be more detailed and check
numerous errorlevels on exit... the above is for example but it is very similar
to how i control many aspects of my bbs system's software... i can tell FD to
do almost anything simply by having it exit with a certain errorlevel and
catching that in my controller script... if binkd had this capability, it would
be extremely nice and much easier to control in an automated fashion ;)
ml> i just don't know why it has to be so hard to code for the use of
ml> disk-based semaphore files no matter what OS is being used...
AG> Because disk based semaphore files is a concept mostly known in
AG> DOS-like OSs. Binkd originally rather resembles the Unix tradition
AG> of daemons ... i.e. having multiple processes handling connections
AG> independent from each other, w/o static configuration of the number
AG> of parallel processes.
guess what? all of my servers on my *nix boxes also work with disk-based
semaphores ;) some of them are done with scripts that send signals and others
use other means BUT the thing is that those signals and semahores are know and
documented... i've not found and good documentation for binkd on OS/2, windows
or *nix that explains these things...
ml> for others, the freeze ones might be beneficial... FrontDoor has
ml> numerous semaphore files
AG> ... because it's targeted to a DOS environment with each process
AG> running in a dedicated (virtual) machine ... all the time.
no... frontdoor has numerous semaphores for external and automated control...
NOT because it is DOS based... whoever told you that was quite incorrect...
AG> If you need DOS behaviour, you'll need to wrap binkd into it ...
i don't need *DOS* behavoir... others and myself want external control
capabilities so we can control binkd easier and without manual intervention...
AG> alternatively you may contribute code.
i've already stated that i do not code C or C++... thanks but no thanks... i'll
pull the trigger of the gun pointed at my foot when /i/ want to :)
AG> I might have a look into logfile name expansion using strftime()
AG> ...
thanks... that would be one big help... at least for me in my goal of
processing the log files anyway... i really hated having to process the one i
had that was some 40 or 50 megs in size and covered several years... that's why
i came up with the grep thing i showed earlier... at least i was able to slice
and dice the logs into months and then analyze them... i don't want to do that
again and for now i try to remember to come in every few weeks and run the
process but this may not always be possible... having binkd do the filenaming
would be great! :)
)\/(ark