The "proper" approach to log rotation is to rename the files, create new files and kill -HUP the boxes to force them to start logging on the new files.
Copying the files it's a very bad idea IMHO. If you happen to have a lot of traffic and the files are big it'll take a while to copy and you'll definitely lose entries. Regards, Alex On Tue, Oct 28, 2008 at 12:42 PM, Mihai Zsigmond <[EMAIL PROTECTED]> wrote: > 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. > > > > >
