| View previous topic :: View next topic |
| Author |
Message |
esheldon76
Joined: 10 Nov 2009 Posts: 16
|
Posted: Tue Dec 01, 2009 7:18 pm Post subject: Access.log file size won't stop increasing |
|
|
| The limit is specified in the .xml file, and was working for months. It's set to be a 2mb max, but now it won't create a new file, only growing the main access.log file. I've restarted the application, and even restarted the server to no avail. Nothing in the server log files stating any reasoning, and can't find any documentation from IceCast to help. Please, can anyone help me get these log files to stop growing at 2mb, and create a new one once that file size is reached??? |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Dec 01, 2009 7:45 pm Post subject: |
|
|
not much to go on, works fine for a while then stops working completely. That would tend to indicate that the settings you have (whatever they are) are correct. Maybe icecast is not allowed to rename the file and open a new one? Does HUP re-open the logs? does the user running icecast have write access to the log directory?
karl. |
|
| Back to top |
|
 |
esheldon76
Joined: 10 Nov 2009 Posts: 16
|
Posted: Tue Dec 01, 2009 7:48 pm Post subject: |
|
|
| I'll look on the rest, but what does HUP stand for? |
|
| Back to top |
|
 |
esheldon76
Joined: 10 Nov 2009 Posts: 16
|
Posted: Tue Dec 01, 2009 7:57 pm Post subject: |
|
|
Okay, checked and the user has all writes to that directory.
Here's what I have for my Logging section of the icecast.xml:
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>3</loglevel>
<!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
<logsize>2000</logsize>
<logarchive>1</logarchive>
</logging> |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Dec 01, 2009 8:25 pm Post subject: |
|
|
Hangup, it's a signal that you can pass to the kill command, ie kill -HUP <pid> or killall -HUP icecast
karl. |
|
| Back to top |
|
 |
esheldon76
Joined: 10 Nov 2009 Posts: 16
|
Posted: Tue Dec 01, 2009 8:32 pm Post subject: |
|
|
| Not sure how to make that HUP help me? |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Dec 01, 2009 10:18 pm Post subject: |
|
|
stop the server, move or remove those files out of the log directory and start up icecast again (if you haven't tried this already). make sure those log files are recreated from new. This will verify whether the log directory will allow icecast to create files in there. Not sure what else could make it stop and not work again. I'm assuming that the logs were around 2Meg before this started to happen and that the log directory is on a reliable filesystem.
karl. |
|
| Back to top |
|
 |
esheldon76
Joined: 10 Nov 2009 Posts: 16
|
Posted: Tue May 11, 2010 7:20 pm Post subject: Sorry this has taken so long... |
|
|
| I've stopped/restarted the server and that didn't work. If I move the file out of the directory, a new access.log file is corrected, but I don't want to have to do this manually every time I want a new access.log file created. Yes, they were around 2mb each for months, and then we added another stream for the month of December, and it corrupted whatever was set. We've since moved providers, used a fresh instance of Icecast, recreated the icecast.xml file, and it's still not renaming the acess.log to access.log_datetimestamp and creating a new one at 10mb? How do I use that HUP command again to test whatever you wanted me to do with it again? |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed May 12, 2010 2:04 am Post subject: |
|
|
HUP will tell icecast to reload the xml (if it can) and it will also reopen the logs, so make sure icecast can write to the directory (logdir). he kill command will send a signal to a specified process
eg kill -HUP <pid>
The fact that a new log file is created would indicate that access is ok although the changeowner or chroot tags are obviously something that could change that.
karl. |
|
| Back to top |
|
 |
|