Old 5th April 2012, 18:13   #1
luis.alen
Junior Member
 
Join Date: Apr 2012
Posts: 4
Shoutcast 2 DNAS - log rotation and inconsistencies

Hello,

We currently use DNAS logs to create daily reports of the radio's audience.

Our report script expects the day logs to be on the _1.log file, which is created every night when shoutcast is restarted by a cron job at 2:30 AM.

That said, here's our problem: When the radio needs to be restarted for some reason (configuration change, server crash, whatever...) the logs are automatically rotated and that causes the report script to miss relevant data, since _1.log will be rotated and become _2.log.

Let me try to make things clearer with an example:

Suppose it's 2:30 PM now and the server crashes. When it comes back up, shoutcast will be started and the logs will be rotated by sc_serv. Now we have a _1.log which has all data from 2:30 AM to 2:30 PM. Then shoutcast starts logging on another file till 2:30 AM, when the scheduled restart will run and cause the logs to be rotated again. Our daily report script then runs and collects all data from _1.log, but will miss all data on _2.log, which recorded everything that happened from 2:30 PM to 2:30 AM.

So, is there a way to prevent sc_serv from rotating its own logs when it starts?

This way I can use the Linux logrotate tool and be sure that there'll be no inconsistencies on our reports.

(I believe logs are also rotated when shoutcast stops, but I know I can avoid this by sending a SIGKILL to the process)

Any other suggestions are very welcome.

Thank you.
luis.alen is offline   Reply With Quote
Old 5th April 2012, 23:25   #2
DrO
 
Join Date: Sep 2003
Posts: 27,873
there is no way to prevent the automatic log rotation and i'm not really seeing a benefit in changing the behaviour. also the logs are not rotated on stopping of the DNAS.

as for force killing the DNAS at 02:30, that seems somewhat excessive especially when most of the config options can be updated without needing to re-start it (with more options added for the next build).

also if you're seeing crashes, more specific details would be appropriate as it shouldn't be crashing (though there are a few possible cases where the current build can crash out at the moment, more so with the linux builds).

-daz
DrO is offline   Reply With Quote
Old 5th April 2012, 23:51   #3
luis.alen
Junior Member
 
Join Date: Apr 2012
Posts: 4
Thanks for your response, DrO.

Well, one of the benefits I see is to avoid inconsistencies on reports just as the one I described above.

Honestly, shit happens, unfortunately. Sometimes servers crash and services die unexpectedly, specially when you have lots of them or when you're running in the cloud and have no control of the physical hardware.

Moreover, that's the first time I see a linux service rotating its own logs. All the other services I've seen delegate this task to the linux logrotate tool (apache, bind, squid, postfix and so on).

One of the reasons they do so is to have a centralized log rotation tool which works for all daemons, no matter how they're developed. This way you don't have to implement and manage one rotation mechanism per service/daemon and you don't rely on them to get the job done. That's the second and most important benefit.
luis.alen is offline   Reply With Quote
Old 6th April 2012, 00:03   #4
DrO
 
Join Date: Sep 2003
Posts: 27,873
i'm really not sure what it is you're using the main log to work out in the first instance as any client connections should be logged in the w3c file. the only other thing i can think off would be for scaping out any title updates - if that is the case then i can see more general benefit in adding title updates to their own file as well as in the main log output.

i see where you're coming from but it feels like a very niche request and i cannot warrant the time needed to implement it especially when the logging is setup for how we use it internally (which is why it works in the manner it does).

-daz
DrO is offline   Reply With Quote
Old 9th April 2012, 13:38   #5
luis.alen
Junior Member
 
Join Date: Apr 2012
Posts: 4
Thanks for your response again, DrO.

Well, as I'm new to shoutcast, I might be missing something here. Looks like I'm looking at the wrong logfile...

Do you think I should be using the w3c log instead of the main one for this purpose?

Isn't it automatically rotated when shoutcast is started? In case it's not and it does provide the seconds the user spent listening as well as the bytes transferred, it'd fit perfectly for my needs.
luis.alen is offline   Reply With Quote
Old 9th April 2012, 15:03   #6
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by luis.alen View Post
Do you think I should be using the w3c log instead of the main one for this purpose?
the w3c log file is intended for keeping a proper track of the client connections to output something like
Quote:
#Software: SHOUTcast
#Version: 2.1.0.58
#Fields: c-ip c-dns date time cs-uri-stem c-status cs(User-Agent) sc-bytes x-duration avgbandwidth
192.168.2.3 192.168.2.3 2012-04-09 14:59:41 /stream?title=fc%2Auk%20-%20Inside%20Me%202 200 WinampMPEG%2F5.54 196608 8 196608
there should be enough tools / details available to parse that out as needed.

Quote:
Originally Posted by luis.alen View Post
Isn't it automatically rotated when shoutcast is started? In case it's not and it does provide the seconds the user spent listening as well as the bytes transferred, it'd fit perfectly for my needs.
all of the log files are auto-rotated only on loading of the DNAS and not on closing of it.

-daz
DrO is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > SHOUTcast > SHOUTcast Discussions

Tags
log, log rotation, logrotate, rotate, sc_serv

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump