Open ghost opened 8 years ago
Hi @Wiegraf, thank you for this very detailed bug report. I have not had any free time to work on this and therefore are thankful for your analysis, changes will come when I get some time to work on this.
I'm thinking of removing Avahi (@samalba also suggested this) from the core image, since it would be better to configure and run Avahi daemon elsewhere anyways. Then since Gnome Tracker is not run by default either, dbus is not necessary to run either anymore and therefore the default container command should be changed to execute netatalk -d
. A bootstrapping entrypoint script could still be a good idea, depending on what bootstrapping features which should be supported.
I have also thought of creating some other images based on this extending to eg. include Avahi daemon, or one to have libpam-ldap installed for LDAP authentication of AFP shares (I use this personally on my home server).
Problem: When the server is first made with the
AVAHI=1
flag, the process list looks something like this, and your computer is automatically discoverable by Finder, thus appearing on the left-hand navigation bar.I'm starting from accessing the container (
docker exec -it netatalk /bin/bash
or similar).When you reboot the server, or something unexpected happens, the server doesn't appear as before in the left-hand side bar, though you can still mount it by IP address. The process list looks like this:
Therefore, the avahi-daemon and dbus services aren't being restarted along with the other services.
Temporary Solution: Running
service dbus start
thenservice avahi-daemon start
thenkill -1 1
(PID 1 for netatalk -d) resolves the issue until the next boot/error. Running services:20 and 21 are save to kill as well, which makes the two working models rather comparable. Obviously, however, this solution is nonideal for most use cases.
Suggested Solution: I think it would be wise to enable these services from the Dockerfile or entrypoint. Running
update-rc.d dbus defaults
along withupdate-rc.d avahi-daemon defaults
gives the following output:avahi-daemon doesn't start running, try as it may, because dbus never starts. Log entry generated:
Failed to start message bus: The pid file "/var/run/dbus/pid" exists, if the message bus is not running, remove this file
Removing/var/run/dbus/pid
and rebooting indeed seems to fix the issue.This solution isn't permanent since the file will reappear after every boot. In the Dockerfile, I tried using the command
service dbus start
since it seemed to gracefully remove the pid file when run manually.So far the results are good. Replacing
avahi-daemon -D
withservice avahi-daemon start
might be a good idea as well, given these findings.Conclusion I suggest using
service dbus start
in place ofdbus-daemon --system
in the Dockerfile to more gracefully handle the destruction of the stale PID file/var/run/dbus/pid
, which appears to cause issues with dbus and by extension avahi when restarting the container.