mherger wrote:
> Please define correctly ;-).
"Correctly" might not be the best word. "Completely"? I'm thinking about
Spotify Connect (because I like to use the Spotify app on my phone but
play on my Squeezeboxes). As you know, without mDNS, LMS is invisible to
the Spotify App on other devices. Phillipe's bridging plugins all (I
think) share the same issue.
mherger wrote:
> >That's a limitation indeed.
I agree :)
mherger wrote:
> This is a first version of the image. I could imagine we could have more
>
> images. But I wouldn't know how to get mDNS working right now.
> Suggestions welcome (I'm sure some of the guys who helped me with the
> initial image already did this, and I refused to accept it for v1 :-)).
>
Absolutely, I understand this very much a developing idea. This is one
of the fundamentals to me, and worth looking at early, but may not be to
others.
My concern is that mDNS _won't_ work unless the networking model is
changed. I've seen some discussion in other areas about exposing the
host's dbus to the container to get this to work, but it doesn't seem to
be reliabe. Other than this I'm not sure either! Whilst there are some
Docker experts paying attention to this, hopefully someone can come up
with an idea.
mherger wrote:
> > There is no supervisor. There can be a problem with Docker ('zombie
>
> We discussed this and came to the conclusion that an image which crashes
>
> should crash, and not hide behind some supervisor restarting it. Because
>
> if it crashes, then there's something wrong. The user better knows about
>
> it. I personally (without Docker) can't remember the last time LMS
> crashed. It shouldn't happen.
Yes, I read the discussion and I agree with you. My concern is not about
LMS crashing, it's about this:
mherger wrote:
> > 'zombie processes aren't terminated'
> > (https://github.com/krallin/tini/issues/8)) that manifests itself
> when
> > the PID 1 process doesn't expect to need to look after other
> processes
> > that are created.
>
> But why would there be so many helpers? Because these helpers crashed,
> or because LMS crashed? Running LMS under a supervisor wouldn't fix the
>
> helpers crashing problem.
>
I'm not sure anything crashed. The discussion in my link quoted above is
a fairly good description, but essentially, the PID 1 process (that LMS
becomes if it is the container entrypoint) that runs in Linux is
expected to reap processes that have been spawned asynchronously but not
awaited because (for example) the process that originally started them
has itself terminated. Things like systemd and bash have the necessary
code to do this, but most normal programs (like LMS) do not. Docker
doesn't pass this responsibility onto the host, so if PID 1 inside the
container can't do this, processes that fall into this category become
"zombie" processes - they have exited but are not removed from whatever
list of current processes the kernel keeps.
I don't want to make this out to be a big problem - in Docker >= 1.13,
it's very easy to avoid it by simply adding "--init" to the Docker run
command (this actually runs the "tini" code referenced in my link which
was adopted into the Docker source). It just needs to be noticed if it's
happening and have that addition made.
------------------------------------------------------------------------
BobSammers's Profile: http://forums.slimdevices.com/member.php?userid=66026
View this thread: http://forums.slimdevices.com/showthread.php?t=111828
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
