Centova Technologies Forum
Centova Cast v3 => Bugs and issues => Topic started by: javier on August 29, 2014, 08:43:26 am
-
Statics Reports Not working after last update Version number 3.1.0.20140826.321r2889
-
same problem
-
same problem for all my stations
-
Support told me that I have the latest version with the fix but I will need to run a script via SSH but for some reason does not work on centos.
"This was due to a bug we've just recently discovered and released an update to fix it. Your version already includes the fix but you need to do the following:
The following commands should restore the stats for the last 48 hours:
for f in /usr/local/centovacast/var/vhosts/*/sc_w3c*.log; do n=${f/sc_w3c_/var\/log\/access.log.}; n=${n%.log}; n=${n/sc_w3c/var\/log\/access.log}; mv $f $n; done
/usr/local/centovacast/bin/ccmanage cronjob --job=logrotate,logprocess
Furthermore you would need to update every station's configuration (you don't actually have to make any modification, just press the update button) and restart the station before things start working correctly again."
-
Hello guys has the issue been sorted with the non statistics report not showing yet or how can I fix the issue
-
HI,
no, looks like we have this problem after the last update and centova is on vacation on labor day weekend.
I guess they will come with a faster solution if they start to receive support tickets with the same problem so people start to open support tickets.
-
After have runned the script, the problem persists, for all my stations.
-
I was also instructed to update the settings and stop/start the server. The stats/logs will begin recording again but will stop within a couple hours. This is getting frustrating.
:'(
-
Have the same problem as well....
-
ok, support blame shoutcast BUT we didnt have this problem before. looks like shoutcast start reading from wrong log example error.log.1 instead of error.log and access.log.1 instead access.log the number can varies.
here is what you need to do. via ssh access the account folder.
cd /usr/local/centovacast/var/vhosts/USERNAME/var/log
then check the pid number of that account (pid number will be next to ccuser, THAT LINE WILL END WITH etc/server.conf USERNAME)
ps aux | grep USERNAME
check the process ruining
lsof -p PIDNUMBER
then check if is writing/reading from some file other that a clean error.log and access.log
if that is not the case, KILL it
kill -HUP PIDNUMBER
then verify again
lsof -p PIDNUMBER
If you still see a error.log.1 or access.log.1 (number can varies) try to kill it again and verify.
if does not work and you still see it then go to the account log folder
cd /usr/local/centovacast/var/vhosts/USERNAME/var/log
and delete the logs that ended in a .log.1 , .log.2 etc just leave clean .log files
from centova cast access the account stop / start and verify again if you still see a .log.1 when you check run:
lsof -p PIDNUMBER
REMEMBER: after you restart the account the PID number will change, you will need to check the new PID number again by using ps aux | grep USERNAME
IF ALL THIS THAT IS A PAIN DOESN'T WORK, OPEN A SUPPORT TICKET
all this start it after the last update and is a pain to do this per affected account.
I hope this help.
UPDATE: SHORT VERSION BUT STILL A PAIN.
stop the account from centova cast
GO TO account log folder
cd /usr/local/centovacast/var/vhosts/USERNAME/var/log
delete the logs that ended in a .log.1 , .log.2 etc just leave clean .log files
from centova cast start the account
then via ssh access check the account folder
cd /usr/local/centovacast/var/vhosts/USERNAME/var/log
then check the pid number of that account (pid number will be next to ccuser, THAT LINE WILL END WITH etc/server.conf USERNAME)
ps aux | grep USERNAME
check the process ruining
lsof -p PIDNUMBER
then check if is writing/reading from some file other that a clean error.log and access.log
if not and all you see is error.log and access.log then ig fine now.
again I hop this help
-
same problem. hope fix on next update
-
there was a newer build posted yesterday so it might be an idea to see if that helps.
though what the 'shoutcast' issue is i don't know unless it's related to the log rotation issue (which is noted as something in the Centova update from yesterday being fixed) as i have no idea if this is due to the known 2.2.x DNAS log issues or quite what (as i see no specific information in people's posts).
-
The procedure in Javier's post is actually the troubleshooting performed by us which lead to the assumption that this is a Shoutcast v1 bug (so it does not apply to Shoutcast v2 or Icecast) which causes it to (sometimes) fail to reopen its log files when it's sent a SIGHUP signal.
We have been making some changes to the log rotation code recently (although only for the benefit of DNAS2) and have been releasing nightly updates; So if anyone's still experiencing statistics issues we recommend updating to the latest version
-
rightio, had to ask as it wasn't clear from any of the threads i'd seen what DNAS or specific version was at fault. another reason to drop v1 support imho ;)
-
I just lost 1 of my 8 clients over this issue today :-[
The version of the radio station I created for them is ->
Centova Cast v3 Build Your Own Packages - Centova Cast v3 (SHOUTcast v2 Server + Auto DJ, Unlimited Bandwidth, Free cPanel Web Hosting, Instant Setup)
All of my other radio stations work fine but I am dealing with pressure from some of my other clients that they will also be pulling the plug on their radio station in the next week if this issue isn't corrected properly.
I have a question. Once this bug is corrected will we be able to go back to look at records before it went down? Is there any other solution to get the stats back up and running asap such as changing accounts to something other than the SHOUTcast v2 Server?
Joseph
-
The following commands should restore the stats for the last 48 hours (sorry, can't restore more than that):
for f in /usr/local/centovacast/var/vhosts/*/sc_w3c*.log; do n=${f/sc_w3c_/var\/log\/access.log.}; n=${n%.log}; n=${n/sc_w3c/var\/log\/access.log}; mv $f $n; done
/usr/local/centovacast/bin/ccmanage cronjob --job=logrotate,logprocess
Next, update to the latest Centova Cast version:
/usr/local/centovacast/sbin/update
And finally you need to update the configuration for every station that is having this issue (you don't actually have to make any modification, just click on Settings and press the Update button) and restart all the station's having this issue. Then things should start working correctly again. (statistics will start being generated every 12 hours)
-
I was also instructed to update the settings and stop/start the server. The stats/logs will begin recording again but will stop within a couple hours. This is getting frustrating.
:'(
the same problem for me..
-
it seems that this problem only occurs on servers that have been updated,
-
I have a question. Once this bug is corrected will we be able to go back to look at records before it went down? Is there any other solution to get the stats back up and running asap such as changing accounts to something other than the SHOUTcast v2 Server?
Joseph
Unfortunately we are yet to receive any reports of this issue happening to Shoutcast 1 via the helpdesk, which means either the issue is already fixed on the latest release, or nobody is using Shoutcast 1 anymore.
You should probably consider provisioning Shoutcast 2 stations to your clients so that they can make the switch at their convenience.
-
it seems that this problem only occurs on servers that have been updated,
This has been fixed for Shoutcast 2.4, please try updating to the latest build and if you continue having the same issue, make sure to report this via helpdesk ticket too.