[darkice] Re: watch darkice errors and restart if necessarily

  • From: "Niels Dettenbach (Syndicat IT&Internet)" <nd@xxxxxxxxxxxx>
  • To: darkice@xxxxxxxxxxxxx
  • Date: Sun, 15 Jan 2012 19:36:57 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



JoergSorge <joergsorge@xxxxxxxxx> schrieb:
>> Happy hacking
>;-)
>ok, slowly, I understand, but it is one thing here, why I use Niels'
>rc-script. I have to manage several streams! So I can't use killall?

If it really makes sense to bring further redirections into the origin rc 
script pls let me know this with a short explanation.

just btw:
Another option for you may be to use any of the typical small or sophisticated 
logfile "monitor" apps which - as a own process - watch aginst any defined 
strings in logging files and restart stuff like darkice processes as required 
by that.

Personally i hardly prefer the icecast status variant (service based) as it 
catches the most of all thinkable local (or remote) problems or problems we've 
faced over the past years within darkice streaming scenarios. It makes no sense 
to know if you can ping any server or the icecast server as it may down even if 
the IP could be pinged.

We "often" (up to several times a day) have ring buffer write errors within 
some logs even if the stream is working after that without any process restart 
- so i did not used that as a restart signal for us, but may be i'm in a 
"wrong" setup here.

Generally it would be nice to have a more detailed understanding or even 
handling of special signal and error behaviours of darkice in the future or may 
be something could be made within darkice (like in icecasts) to catch up 
network errors and handle them in a self healing way asap - or just stopping 
the process byself properly if the stream could/is not rendered any longer by 
the process, this would help to see if "something is wrong" and monitor/restart 
the darkice process.

May be it would help if darkice would be extended against "network reliability" 
(i.e. like automatic reconnects to servers, configuration of timeouts, retries, 
pings etc.).

But yes/sorry, i'm did not find the time yet to dig into that deeper and my C 
knowledge is very small too - hope i'm not on the wrong way here currently but 
if i can help here within the devel process pls let me know this.


cheers,


Niels.
- --
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iIEEAREIAEEFAk8THMc6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDV7IAJ4xqoNrJKVd
vv5O4xJ7P6F/sOoQzACfWYU5oA73NXPwXsTgIHCtOeYTqYg=
=Lxbj
-----END PGP SIGNATURE-----


Other related posts: