Fails to start with disabled Avahi daemon socket #1590
Comments
|
Here is a full reproducer: First make it running Then break it This gives the error: Then fix it again: And break it again I think, this is only some issue with some leftover state. |
|
I just wanted to add that creating a new container with Avahi disabled works, but it's a pain to always have to reinstall everything and I just did that recently when upgrading to F41. So after breaking it with I can continue with And the new container works with Avahi disabled. So the issue title is a bit misleading, because toolbox does start and work with Avahi disabled, but seems to be failing to start with Avahi disabled if the container was created with Avahi enabled. Is there any workaround to somehow remove the knowledge about Avahi from the existing container without reinstalling everything into a new container? |
|
I see that it is a bind mount that the container added for the Avahi daemon socket. Hm, not sure if there is a way to modify an existing container's mount points or make the bind optional only if the path exists. This seems to be a limitation of the underlying container runtime and not toolbox. I might need to recreate the container then anyway. Please feel free to close this issue, this might be actually working as expected, I just got a bit confused about how these containers work and what services they mount automatically. |
|
Yes, this is a legitimate bug, and I think it can be fixed. The problem, as you found out, is that Toolbx specifies the bind mount for the Avahi socket when creating the container: $ podman create --volume /run/avahi-daemon/socket:/run/avahi-daemon/socket ...... which leads to the snippet in To avoid that trap, at some point, Toolbx started doing the bind mounts at run-time because the entire Sadly, we never finished the migration because nobody reported any problems with the existing static mounts. :( We need to do the same change for the Avahi bind mount, but now in the Go implementation. The Want to submit a pull request? :) |
|
I would like to, but first need to get a bit familiar with Go and don't have too much time, so can't make any guarantees. |
|
@debarshiray I was wondering if this avahi mount is needed at all. Reading a bit about Avahi, it seems it uses a DBus API and the DBus socket is already mounted by toolbox. I tested locally, that with a container created with avahi daemon not running, so no |
|
I found the commit that added this avahi mount at 29c155f and the original issue at #209 In the issue there are various possible reasons mentioned and I am not sure if this mount was the one that actually fixed things, because the examples from the issue work for me fine without the mount e.g. |
|
I think, I see how this works. So |
|
I had a brief look at the code and with non-existant Go skills my take would be to add the following to {"/run/avahi-daemon/socket", "/run/avahi-daemon/socket", ""},which "works for me", but if there are systems with any non-standard paths used by the systemd socket, it won't work, so probably this won't pass... |
debarshiray
changed the title
Describe the bug
I've recently disabled the
avahi-daemon.serviceandavahi-daemon.socketunits, because I don't need Avahi (I only need to resolve mDNS and I can do that withsystemd-resolvedalready). After this I can't start my Fedora Toolbox anymore.The toolbox enter does not tell me what the problem is:
toolbox enter debug logs
However, when I try to start the container with Podman it reveals the problem:
Podman start debug logs
Steps how to reproduce the behaviour
Probably the following:
/run/avahi-daemon/socket)Expected behaviour
Expect the toolbox to work also without Avahi.
Actual behaviour
The toolbox fails to start.
Screenshots
N/A
Output of
toolbox --version(v0.0.90+)Toolbx package info (
rpm -q toolbox)Output of
podman versionPodman package info (
rpm -q podman)Info about your OS
Fedora 41 Sericea
Additional context
Re-enabling Avahi daemon/socket fixes the problem - I just don't want to use Avahi...
The text was updated successfully, but these errors were encountered: