we've released a new release (2.2.2) which may resolve this issue -> http://forums.winamp.com/showthread.php?t=373139 (though as none of the people i reached out to test this issue responded, it's unknown if we have actually fixed it or not).

Hi DrO,
Last night I replace the new sc_serv on all my centova cast systems (working on Debian squizee).
After upgrade and restarts of all the servers (about 200 istances on several different machines) I still have continuos crash of the server and so restarts from centova cast panel.
So it seems the problem still remain. If this continue for all the day, next night, I'll try to switch to the 32 bit version of the new one. And I will see.
There is something I can do for you to help to understand what happen?
Thanks.

i ideally need access to a machine which is experiencing the issue so i can debug / try out changes to try to track down the issue (is easier and quicker if am able to have remote access to some sort of test account on a setup showing the issue i.e. so can ssh into it or along those lines).

though i don't know how easy that is to do without possibly having to do it on a working setup which leads on to the next question... does it also happen for you if using the the log rotate actions via the server admin page in the DNAS itself ?

Hi Dro,
I answer you in the Winamp forum.

for those not following things on the SHOUTcast forum, please see http://forums.winamp.com/showpost.php?p=3003610&postcount=29 on what you can do to resolve the log rotate crash issues as best as possible before a new fully fixed v2 DNAS is released. that should allow you to at least update to the current DNAS build for the high client connection stability fixes.

so this now explains why it's been such an intermittent issue to track down and why some builds were more susceptible to the issue than others (and why the 32-bit build of 2.2.2 now showed the issue unlike the 32-bit 2.2.1 build due to code clean-up made for the 2.2.2 release).


so there's a temporary solution (clearing out 0-byte log files) and a permanent fix for the issue to follow (newer DNAS build).

I see there is a workaround in the new release of Centovacast out in these days.
One question for Centova Staff:
With NO_ROTATE_DNAS2 enabled, it means that that the log file continue to grow endlessy (and what happen if it become too big?).  Or there is another behavior to control the logfiles?
This is important to understand. Waiting DrO fix.

With NO_ROTATE_DNAS2 enabled, it means that that the log file continue to grow endlessy (and what happen if it become too big?).  Or there is another behavior to control the logfiles?

DNAS2 supports rotating its own log files when they get to a certain size.  The NO_ROTATE_DNAS2 option tells Centova Cast not to also try rotating them, which is basically just a duplication of effort.

It'd be more ideal if DNAS2 could be told not to rotate its own logs at all and just let CC do it, since it's most efficient for us to process the log file in a single pass and then rotate it out, rather than processing a bunch of separate files generate by DNAS2... but it probably doesn't amount to much difference in terms of real-world performance.

DNAS2 supports rotating its own log files when they get to a certain size.  The NO_ROTATE_DNAS2 option tells Centova Cast not to also try rotating them, which is basically just a duplication of effort.

it's actually based on how long since the last rotate (which is currently set at 24hrs). the size doesn't have any effect on things (though i can see cases where it would be helpful if it could be roughly controlled by filesize).

It'd be more ideal if DNAS2 could be told not to rotate its own logs at all and just let CC do it, since it's most efficient for us to process the log file in a single pass and then rotate it out, rather than processing a bunch of separate files generate by DNAS2... but it probably doesn't amount to much difference in terms of real-world performance.

noted

Ha! I keep forgetting you're on our forums, DrO... Despite how it may look, I swear my comments aren't meant as passive aggressive criticisms of DNAS2. We should probably just make NO_ROTATE_DNAS2 the default setting in Centova Cast... The only reason it isn't presently the default is because our DNAS2 module is derived from our old DNAS1 module, which required us to rotate the logs ourselves.

i know, just clarifying things though it's definitely valid for the DNAS to provide a bit more control over how the log rotates are handled anyway. so is valid to add probably 2 more config options to allow for the default behaviour to be overridden.

there'll be a 'rotateinterval' option (default is 86400 seconds i.e. 24 hours) and setting it to 0 will disable all log rotations. though like you note, it might be simpler to just leave the DNAS to do it but the option for you or the DNAS to maintain things will be there as of the new build.

either way, this stability issue should at last be resolved which is good for everyone involved.

we've just released v2.4.0 which has the log file handling fixes in. so that should be end of the crashes on log rotation (along with the work Centova have been doing from their side).

How to update? Or better to wait till Centova will build update?

Thx in advance

Thanks for the heads-up DrO. I'll contact Steve about this ASAP

TESTING... on Debian squeeze and centos...