Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2018-06-16T22:44:50Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2168Icecast should expose the YP server messages to the admin status pages per mount2018-06-16T22:44:50ZThomas B. RückerIcecast should expose the YP server messages to the admin status pages per mountThere are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simp...There are hundreds if not thousands of streams that fail to list properly on dir.xiph.org and it's obvious that nobody notices.
The admin interface should expose detailed information about the status of a YP listing. As per #2167 a simplified status should be also exposed to the XML used for public status.
People don't read the error.log, ever, especially in this case.
We should expose:
* If the YP server accepted the initial touch
* If the server accepted the latest touch
* What was the last status message from the YP server for a failed touch
* What was the latest status message from the YP server, including successful
* Count of YP touches since source connection
* Count of failed YP touches since source connection
Rationale is, that there might be intermittent failures so we should expose both latest message and latest failure. Also latest message, if successful could contain some information like "server outdated and insecure, please update" or otherwise from the YP administration.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2284Icecast segfaults on startup and shutdown2018-07-02T00:38:16ZBrendonIcecast segfaults on startup and shutdownUsing the latest 2.4.3 with SSL on Debian 8 x64 (happens with SSL disabled as well). Running icecast using daemontools. This also happened with 2.4.2 being started with upstart. Startup script is:
```
exec /usr/local/bin/icecast -c /etc...Using the latest 2.4.3 with SSL on Debian 8 x64 (happens with SSL disabled as well). Running icecast using daemontools. This also happened with 2.4.2 being started with upstart. Startup script is:
```
exec /usr/local/bin/icecast -c /etc/icecast/icecast.xml
```
I've noticed that the icecast process segfaults on both startup and shutdown.
Shutdown:
```
Aug 24 14:50:01 ngradio-staging kernel: [80171.821413] icecast[16264]: segfault at 48 ip 000000000040fa8e sp 00007f2af4087dd0 error 4 in icecast[400000+34000]
```
Startup:
```
Aug 24 14:41:02 ngradio-staging kernel: [79632.697742] icecast[14984]: segfault at 0 ip 00007fc773ea3c3a sp 00007fc775798e18 error 4 in libc-2.19.so[7fc773e22000+1a2000]
```
Observations:
- Happens 100% of the time the process is stopped.
- Happens nearly 100% of the time the process is started, and at times can happen 5-10 times before the icecast process will start. Sometimes I can't get the process to start at all when I'm starting it manually via the cli (tried 10-20 times then gave up).
- Happens with the liquidsoap processes trying to connect and with liquidsoap completely down.
- Nothing seems to be correlated with these segfaults, nor with this happening once or multiple times before the process ultimately starts.
- I don't get a segfault on startup when running Icecast via valgrind, but I do when running directly on the cli, via strace, or via daemontools.
- Sometimes if I start / restart icecast a bunch via daemontools, I can't get the process to start up at all. A reboot seems to be the only thing that helps.
I uploaded my Icecast config and some valgrind output in #2283. This is the tail end of the strace output:
```
munmap(0x7f23bacb1000, 4096) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
write(7, "[2016-08-24 14:53:33] INFO conn"..., 118) = 118
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
write(7, "[2016-08-24 14:53:33] INFO conn"..., 836) = 836
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, 300 <unfinished ...>
+++ killed by SIGSEGV +++
```
Let me know if I can provide any other info. As of right now, this is simply a nuisance, but without daemontools restarting the process over and over until it finally does start up, this would probably be a blocker.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2201network throughput limited at 70mbps2018-07-07T09:17:24Zwilson chuanetwork throughput limited at 70mbpsHi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere aroun...Hi I have setup 3 icecast servers for eradioportal.com. These are running in a hyperV environment using CentOS v6.6
I have noticed that despite being on a 1gbps connection, the maximum network throughput i am getting is somewhere around the 70mbps only.
Is this a bug? or is this a misconfiguration error?
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2200icecast stats addition (per mount cumulative listener counter)2018-07-07T09:19:54Zddndukkicecast stats addition (per mount cumulative listener counter)Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
s...Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
so it appears in /icecasts/source/ node with name like 'listener_connections'.
<icestats>
<listener_connections>3</listener_connections>
<source mount="/test">
<listener_connections>2</listener_connections>
...
</source>
</icecasts>
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2331Add history to status-json.xsl2018-07-07T19:19:02ZRoger HågensenAdd history to status-json.xslSince history is now implemented in https://gitlab.xiph.org/xiph/icecast-server/commit/3dd8bdbf40e0988d331724f2a2b5c2bf774584b4 it is hopefully trivial to add this to status-json.xsl as well?Since history is now implemented in https://gitlab.xiph.org/xiph/icecast-server/commit/3dd8bdbf40e0988d331724f2a2b5c2bf774584b4 it is hopefully trivial to add this to status-json.xsl as well?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2332Change playlist_new default from 4 to 102018-07-09T11:30:46ZRoger HågensenChange playlist_new default from 4 to 10Change `src->history = playlist_new(4 /* DOCUMENT: default is max_tracks=4. */);`
To `src->history = playlist_new(10 /* DOCUMENT: default is max_tracks=10. */);`
Other servers like Shoutcast has 10, various players and webplayers has 10...Change `src->history = playlist_new(4 /* DOCUMENT: default is max_tracks=4. */);`
To `src->history = playlist_new(10 /* DOCUMENT: default is max_tracks=10. */);`
Other servers like Shoutcast has 10, various players and webplayers has 10.
Most service providers do minimal configuration changes so a default of 10 is beneficial as that is most likely what users want anyway.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2108Registrable URL handlers in connection.c instead of hardcoded list2018-07-16T09:09:26ZMarvin ScholzRegistrable URL handlers in connection.c instead of hardcoded listSuggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Suggested in TODO
>general registerable url-handlers in connection.c rather than hard-coded list
>(already getting unmaintainable)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2135Return "return" code for command_manageauth iceresponse2018-07-16T09:12:54ZMarvin ScholzReturn "return" code for command_manageauth iceresponseReturn "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Return "return" code in iceresponse for command_manageauth, to indicate if it failed or succeeded.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2336Icecast 2.5.x relays not working2018-07-26T10:19:39ZPhilipp SchafftIcecast 2.5.x relays not workingRelays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Relays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2316MP3 files sent by Icecast do not play on Chrome2018-08-27T12:34:43ZLaurensGMP3 files sent by Icecast do not play on ChromeI have a webpage with Jplayer to play .mp3 files from an Icecast server. Up to and including icecast version 2.4.0 this works on all browsers (Firefox, IE, Edge, Chrome on Windows; Firefox, Puffin, Chrome on Android). When using icecast ...I have a webpage with Jplayer to play .mp3 files from an Icecast server. Up to and including icecast version 2.4.0 this works on all browsers (Firefox, IE, Edge, Chrome on Windows; Firefox, Puffin, Chrome on Android). When using icecast versions 2.4.2 or 2.4.3 it works on all browsers except Chrome.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2329Config file using url auth causes SIGILL on SIGHUP2018-09-28T13:17:37ZMarvin ScholzConfig file using url auth causes SIGILL on SIGHUPReported by spr0cketeer on 21 Nov 2017 (Github):
Hello icecasters!
Using icecast master cd0a3f9
getting a SIGILL when sending a SIGHUP to reread config file.
Only happens when using url auth:
```
<mount> ...Reported by spr0cketeer on 21 Nov 2017 (Github):
Hello icecasters!
Using icecast master cd0a3f9
getting a SIGILL when sending a SIGHUP to reread config file.
Only happens when using url auth:
```
<mount>
<mount-name>/test</mount-name>
<authentication type="url">
<option name="listener_add" value="http://example.com/auth"/>
</authentication>
</mount>
```
Server is running on haswell architecture - related: karlheyes/icecast-kh#157
```
Thread 1 "icecast" received signal SIGHUP, Hangup.
[2017-11-20 23:02:55] INFO sighandler/_sig_hup Caught signal 1, scheduling config re-read...
[2017-11-20 23:02:55] INFO auth_url/auth_get_url_auth URL based authentication setup
[New Thread 0x7fffeebd4700 (LWP 9495)]
[2017-11-20 23:02:55] INFO auth/auth_run_thread Authentication thread started
[2017-11-20 23:02:55] WARN CONFIG/__check_hostname Warning, <hostname> not configured, using default value "localhost". This will cause problems, e.g. this breaks YP directory listings. YP directory listing support will be disabled.
[2017-11-20 23:02:55] WARN CONFIG/_parse_root Warning, <location> not configured, using default value "Earth".
[2017-11-20 23:02:55] WARN CONFIG/_parse_root Warning, <admin> contact not configured, using default value "icemaster@localhost". This breaks YP directory listings. YP directory support will be disabled.
[2017-11-20 23:02:55] INFO auth/auth_run_thread Authentication thread shutting down
[2017-11-20 23:02:55] INFO auth_url/auth_url_clear Doing auth URL cleanup
[2017-11-20 23:02:55] INFO connection/get_tls_certificate No TLS capability on any configured ports
[Thread 0x7ffff7fba700 (LWP 8767) exited]
Thread 5 "icecast" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffeecd6700 (LWP 8770)]
__GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
38 pthread_rwlock_unlock.c: No such file or directory.
(gdb) bt
#0 __GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
#1 0x000000000042ac25 in thread_rwlock_unlock_c (rwlock=rwlock@entry=0x642800 <_locks>, line=line@entry=754, file=file@entry=0x42fe9f "cfgfile.c") at thread.c:568
#2 0x000000000040b66c in config_release_config () at cfgfile.c:754
#3 config_reread_config () at cfgfile.c:701
#4 0x0000000000411025 in _slave_thread (arg=arg@entry=0x0) at slave.c:751
#5 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#6 0x00007ffff68546ba in start_thread (arg=0x7fffeecd6700) at pthread_create.c:333
#7 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) thread apply all bt
Thread 7 (Thread 0x7fffeebd4700 (LWP 9495)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=150000) at thread.c:626
#2 0x000000000042304a in auth_run_thread (arg=arg@entry=0x7fffd800b490) at auth.c:359
#3 0x000000000042a6cd in _start_routine (arg=0x7fffd800bce0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7fffeebd4700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 6 (Thread 0x7fffeec55700 (LWP 8771)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=150000) at thread.c:626
#2 0x0000000000421183 in event_run_thread (arg=arg@entry=0x0) at event.c:174
#3 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7fffeec55700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7fffeecd6700 (LWP 8770)):
#0 __GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
#1 0x000000000042ac25 in thread_rwlock_unlock_c (rwlock=rwlock@entry=0x642800 <_locks>, line=line@entry=754, file=file@entry=0x42fe9f "cfgfile.c") at thread.c:568
#2 0x000000000040b66c in config_release_config () at cfgfile.c:754
#3 config_reread_config () at cfgfile.c:701
#4 0x0000000000411025 in _slave_thread (arg=arg@entry=0x0) at slave.c:751
#5 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#6 0x00007ffff68546ba in start_thread (arg=0x7fffeecd6700) at pthread_create.c:333
#7 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7ffff7eb8700 (LWP 8769)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=200000) at thread.c:626
#2 0x0000000000428afd in yp_update_thread (arg=arg@entry=0x0) at yp.c:732
#3 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7ffff7eb8700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7ffff7f39700 (LWP 8768)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=300000) at thread.c:626
#2 0x000000000041556e in _stats_thread (arg=arg@entry=0x0) at stats.c:737
#3 0x000000000042a6cd in _start_routine (arg=0x68f160) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7ffff7f39700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7ffff7fbc740 (LWP 8763)):
#0 0x00007ffff657e70d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000040c6ee in poll (__timeout=300, __nfds=<optimised out>, __fds=0x7fffffffa450) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 wait_for_serversock (timeout=300) at connection.c:302
#3 _accept_connection (duration=300) at connection.c:371
#4 connection_accept_loop () at connection.c:616
#5 0x000000000040685a in _server_proc () at main.c:356
#6 main (argc=<optimised out>, argv=<optimised out>) at main.c:601
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2339After logrotate Icecast not using new access.log and error.log files2018-09-28T13:24:06ZDoug TinklenbergAfter logrotate Icecast not using new access.log and error.log filesThe logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.p...The logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.pid file.
So what's happening is that after a logrotate the Icecast service continues to use the access.log-date file rather then the new access.log file that is created during the logrotate. The only way to get it to use the new log files is to restart the icecast service.
Why is the logrotate command trying to kill a pid file that doesn't exist and is there another postrotate command that should be used instead.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2225Make listen backlog customizable2018-09-28T14:05:00ZMarvin ScholzMake listen backlog customizableExcerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instanc...Excerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instances on our media streaming cluster. [...]
>
> We ran into an issue that clients which where connecting to our streams
> seemed to be 'hanging' on the connection setup frequently. The client
> 'thinks' it is connected, but no data.
>
> People suggested that it probably had to do with the poll() call. So, I
> looked into that.
>
> I found that the issue was actually caused by the very low listen
> backlog (5).
> On our clusters, we typically set this to 8192. Yes it is high, but we
> do a _lot_ of streaming and host very high volume websites.
Attached are the submitted patches for 2.4, 2.5 and 2.3.3
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2192URL auth: override status code and send custom headers2018-09-28T15:04:52ZThomas B. RückerURL auth: override status code and send custom headersCurrently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send...Currently we're hardcoded to 401, if the backend refuses authentication. 403 might also be desireable or 30x with a _location_ header.
This needs two things:
* capability to set a custom status (including message)
* capability to send headers that will be forwarded to the client
The latter can also be used to set cookies, so is useful by itself.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2080Limit/Filter access types available through a listener socket2018-10-02T08:29:07ZThomas B. RückerLimit/Filter access types available through a listener socketOne thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especial...One thing that might be worth considering is to add another setting to listener sockets that would limit which requests are handled on that port.
Listener clients, POST/sources, admin, STATS, XSLT, static files - come to mind.
Especially in case of professional installations there is often the desire to limit exposure to potential attacks to a minimum.
That way there could be a listener client port on public IP, while all advanced functionality would only be available on a firewalled IP/port.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2130Add POST support to admin requests2018-10-04T10:42:35ZMarvin ScholzAdd POST support to admin requestsDue to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is th...Due to how web stuff works and the web interface handles things (auth managements for instance) it is mandatory that we support POST, for properly sending data to the server.
(Just one downside of GET that already should be enough is that the password would be in cleartext in the browser history)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2111Race condition in fserv.c?2018-10-04T10:53:27ZMarvin ScholzRace condition in fserv.c?>race condition between avl_tree_unlock(pending_tree) and
>thread_cond_wait(&fserv_cond) in fserv.c, it's a pain to fix but should be.
Found in the TODO, still relevant?>race condition between avl_tree_unlock(pending_tree) and
>thread_cond_wait(&fserv_cond) in fserv.c, it's a pain to fix but should be.
Found in the TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2104Check: Bytes sent and time listening might be broken?2018-10-04T10:54:41ZMarvin ScholzCheck: Bytes sent and time listening might be broken?> logging - bytes send and time listening may both be broken?
As mentioned in the TODO file, we should check this.
> logging - bytes send and time listening may both be broken?
As mentioned in the TODO file, we should check this.
Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2126listener_remove is not triggered when kicking users2018-10-04T11:08:04ZMarius Flagelistener_remove is not triggered when kicking usersWhen kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as...When kicking users, listener_remove isn't triggered. This has been tested on Icecast 2.3.3.
I haven't tested if this works if you remove a mount point, but one would like the same functionality here, that listener_remove is triggered as well. I use these triggers to update a database with listeners and to make sure I have consistency, it would be nice if both triggers (listener_add and listener_remove) were triggered whatever causes a listener to be added and removed.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schafft