View previous topic :: View next topic |
Author |
Message |
kozlov
Joined: 26 Sep 2006 Posts: 41 Location: Poland, Gdansk
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Jan 02, 2008 2:55 pm Post subject: |
|
|
Before any changes to logging occur, I think there needs to be some discussion on what people actually want keeping backward computability . One suggestion is to have a logging section in a <mount> setting, so those logs only get mount-specific log entries.
karl. |
|
Back to top |
|
|
kozlov
Joined: 26 Sep 2006 Posts: 41 Location: Poland, Gdansk
|
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Jan 02, 2008 5:32 pm Post subject: |
|
|
no it's not implemented yet, I haven't heard of many opinions on logging possibilities, but we don't want something that can be complicated to configure or code up.
karl. |
|
Back to top |
|
|
kozlov
Joined: 26 Sep 2006 Posts: 41 Location: Poland, Gdansk
|
Posted: Wed Jan 02, 2008 5:57 pm Post subject: |
|
|
karlH wrote: |
(...) we don't want something that can be complicated to configure or code up. |
Huh? One entry in mount section which specifies log file and eventually one that specifies if entries are stored in *global* log, too... ? Never mind, if you think that could decrease stability and/or server's efficiency (I'm not an advanced programmer so I don't know if), do as you wish. Even without proposed abilities Icecast will be better than SC. Just tried to give an idea. _________________ polska dokumentacja serwera Icecast2 / polish documentation of Icecast2 |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Jan 02, 2008 6:30 pm Post subject: |
|
|
There's actually 3 log files, error/access and playlist logs. My suggestion was purely based on setups where an icecast can have many mountpoints each one by a different user. The problem with log per mount is the naming, as mountpoints can have / in them.
It won't be a stability issue but it will use an extra file descriptor per extra log. My main concern is not having many different ways of having the logs split up, while dumping everything into say 1 error log is simple it may also be inconvenient but I may be missing some other way these logs could be split up.
karl. |
|
Back to top |
|
|
rongage
Joined: 10 Jun 2008 Posts: 5
|
Posted: Fri Oct 03, 2008 7:36 pm Post subject: Suggestion |
|
|
First of all, I could REALLY use this feature. I need per-mountpoint logging ability.
How about having a "logfile" and "errorfile" parameter in each mount definition? This eliminates the "naming" issue from being icecast's issue - just like in the apache config files. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri Oct 03, 2008 8:38 pm Post subject: |
|
|
well the awkward point is for me is when wildcard mounts are defined, I see 2 possibilities, a shared log between those where a log id is shared or a separate log is allocated but then you have to deal with a unique name which could be mountpoint based but the / would have to be handled. As an example the / could be mapped to _ so /DJ/name.ogg becomes <logdir>/DJ_name.ogg.log
karl. |
|
Back to top |
|
|
rongage
Joined: 10 Jun 2008 Posts: 5
|
Posted: Fri Oct 03, 2008 10:48 pm Post subject: Wildcard mountpoints |
|
|
Forgive me for this suggestion, but it could help the discussion here.
How about a simple macro-replacement setup for defining the logfile name. Something like the following:
%m == mountpoint name
%p == TCP port number
%i == IP Address of listener
%u == authenticated user
and so on...
This would allow you to define a logfile as such:
logfile = %m/access.log
Shouldn't be that hard to implement, would create a log per mountpoint, should support auto-creating directories and files as needed, and so on. I would think this will solve the problem at hand.
Just an idea... |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri Oct 03, 2008 11:36 pm Post subject: |
|
|
having a variety of expandable parameters is fine but your %m would still have the problem I mentioned and I suspect we'd want something basic first to make sure things are ok. To make it easier initially, we'll avoid a reload changing the active log. Let me get kh2 out of the way and then I'll look at the logging lines as an id will need to be passed.
karl. |
|
Back to top |
|
|
|