Hi Davor, As I have said in a previous post this method has been devised for low traffic SMSC links ( limit 1 SMS/sec). Most possible you loose the messages between the end of first copy command and the end of the second command.
To minimise that risk, use a script rather than prompt commands and eventually you can try to synchronize somehow kannel to the script. For instance you can try and lock the file before copying it and then unlock it. Feel free to try and share the experience. Best regards, Mihai Zsigmond --- On Tue, 10/28/08, Davor Spasoski <[EMAIL PROTECTED]> wrote: > From: Davor Spasoski <[EMAIL PROTECTED]> > Subject: RE: Kannel startup script does not stop bearerbox completely > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Date: Tuesday, October 28, 2008, 4:10 PM > Hi Mihaizs, > > This works, but still there is a chance of loosing some > events if the log is eventful and it takes some time (though > short) to copy the files. A busy kannel can serve many > SMS/second and loose some log events in the meantime. > I deliberately waited a few seconds between the copy > commands and lost all the events meanwhile. I should try > this with a script and simulate many sms/sec and check if I > will loose something. > > BR, > > Davor > > > -----Original Message----- > From: Mihai Zsigmond [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 28, 2008 2:36 PM > To: [email protected]; Davor Spasoski > Subject: RE: Kannel startup script does not stop bearerbox > completely > > Hi Davor, > > Actually is the following sequence: > > cp access.log access.rotated > cp -f a1.txt access.log > chmod 644 access.log > gzip -f -9 access.rotated > > As you can see you must not move the access.log but replace > it with an empty file. The last step is optional. > > I must emphasize that I used this method only on Fedora and > CentOS systems. > a1.txt has to have broad rights, like 777 for instance. > > Hope it helps. > Best regards, > Mihai > > > --- On Tue, 10/28/08, Davor Spasoski > <[EMAIL PROTECTED]> wrote: > > > From: Davor Spasoski > <[EMAIL PROTECTED]> > > Subject: RE: Kannel startup script does not stop > bearerbox completely > > To: "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]>, "[email protected]" > <[email protected]> > > Date: Tuesday, October 28, 2008, 3:06 PM > > Can you please be more precise with your method? > > Tried mv access.log acess.rotated > > cp blank acess.log > > but kannel continues to write in the acess.rotated > > > > Davor > > > > > > -----Original Message----- > > From: Mihai Zsigmond [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 27, 2008 7:02 PM > > To: [email protected] > > Subject: RE: Kannel startup script does not stop > bearerbox > > completely > > > > > > > > > > --- On Mon, 10/27/08, Mihai Zsigmond > > <[EMAIL PROTECTED]> wrote: > > > > > From: Mihai Zsigmond <[EMAIL PROTECTED]> > > > Subject: RE: Kannel startup script does not stop > > bearerbox completely > > > To: [EMAIL PROTECTED] > > > Date: Monday, October 27, 2008, 7:55 PM > > > Hi guys, > > > > > > I'm adding my 5 cents' worth at this > > discussion. > > > > > > The bearerbox waits for all SMSC connections to > be > > properly > > > closed, before it can close itself. This can take > some > > time, > > > mostly when connections are UCP/EMI type. You can > skip > > this > > > wait issuing a second kill command, which closes > > immediately > > > the bearerbox and puts "Can not die at its > own > > > will" message in the log. > > > > > > However, there is a more elegant approach to log > > rotation, > > > which does NOT stop the bearerbox. > > > Instead, my log script renames the log file to > some > > other > > > name and then copies a blank file with the name > of the > > log. > > > This method has been working for the past four > years > > on > > > different Kannel versions on Fedora and CentOS > > systems. > > > > > > Yet, I have never tested this method in high > volume > > traffic > > > environment, we are limited by our SMS providers > to 1 > > > SMS/sec rate. > > > > > > Hope it helps. > > > > > > Best regards, > > > Mihai Zsigmond > > > > > > --- On Mon, 10/27/08, Mathieu Bruneau > > > <[EMAIL PROTECTED]> wrote: > > > > > > > From: Mathieu Bruneau > > > <[EMAIL PROTECTED]> > > > > Subject: RE: Kannel startup script does not > stop > > > bearerbox completely > > > > To: "Jason Mule" > > > <[EMAIL PROTECTED]>, [email protected] > > > > Date: Monday, October 27, 2008, 6:36 PM > > > > We have seen a similar thing, however ours > > _usually_ > > > > shutdown within > > > > 30s... The SMS server is still on Debian > Sarge > > > however. > > > > > > > > I usually do an strace on the process and > see > > it's > > > > actually does a futex > > > > (Don't have the exact line atm) > operation. I > > > always > > > > tought it was > > > > actually waiting for all connection to be > > cleanly > > > closed > > > > (?). I'm > > > > usually able to use the "status" > > command > > > till > > > > it's almost closed and see > > > > which connections are still active. > > > > > > > > However for log rotation, in sarge at least > > it's > > > doing > > > > an HUP and we > > > > never had issue I can recall... > > > > > > > > /var/log/kannel/*.log { > > > > daily > > > > missingok > > > > rotate 100 > > > > olddir /var/log/kannel/backup > > > > compress > > > > create 640 kannel adm > > > > sharedscripts > > > > postrotate > > > > killall -HUP bearerbox > smsbox > > wapbox > > > > > > > > /dev/null 2> > > > > /dev/null || true > > > > endscript > > > > } > > > > > > > > Regards, > > > > Mathieu Bruneau > > > > > > > > -----Original Message----- > > > > From: Jason Mule > [mailto:[EMAIL PROTECTED] > > > > Sent: Monday, October 27, 2008 11:02 AM > > > > To: [email protected] > > > > Subject: Kannel startup script does not > stop > > bearerbox > > > > completely > > > > > > > > Hi, > > > > Can anyone else on this list confirm this? > I > > have > > > noticed > > > > that the > > > > Kannel init script (Debian Etch, Kannel > 1.4.1) > > does > > > not > > > > stop bearerbox > > > > completely when called. After calling > > > > 'start-stop-daemon --stop --retry > > > > 5 --pidfile $PIDFILES/kannel_bearerbox.pid > > --exec > > > > $BOXPATH/run_kannel_box' , a bearerbox > > process > > > remains > > > > which must be > > > > killed manually or by adding a line similar > to > > the one > > > > below to the init > > > > script: > > > > > > > > # Wait for bearerbox to finish > > > > start-stop-daemon --stop --quiet --oknodo > > > > --retry=0/30/KILL/5 --exec > > > > $BOXPATH/bearerbox > > > > > > > > -- > > > > Kind regards > > > > Jason Mule > > > > > > > > > > > > COSMOFON - Mobile Telecommunications Services - A.D. > > Skopje > > > _______________________________________________________________ > > This e-mail (including any attachments) is > > confidential and may be protected by legal > privilege. > > If you are not the intended recipient, you should not > copy > > it, re-transmit it, use it or disclose its > contents, but > > should return it to the sender immediately and > delete > > your copy from your system. Any unauthorized use or > > dissemination of this message in whole or in part is > > strictly prohibited. Please note that e-mails are > > susceptible to change. COSMOFON A.D. Skopje shall not > be > > liable for the improper or incomplete transmission > of the > > information contained in this communication nor for > any > > delay in its receipt or damage to your system. > > > > > COSMOFON - Mobile Telecommunications Services - A.D. > Skopje > _______________________________________________________________ > This e-mail (including any attachments) is > confidential and may be protected by legal privilege. > If you are not the intended recipient, you should not copy > it, re-transmit it, use it or disclose its contents, but > should return it to the sender immediately and delete > your copy from your system. Any unauthorized use or > dissemination of this message in whole or in part is > strictly prohibited. Please note that e-mails are > susceptible to change. COSMOFON A.D. Skopje shall not be > liable for the improper or incomplete transmission of the > information contained in this communication nor for any > delay in its receipt or damage to your system.
