Avahi doesn't survive container restarts (or other phenomena)

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).

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0 147912  6068 ?        Ssl  08:06   0:00 netatalk -d
message+    15  0.0  0.0  42124  2188 ?        Ss   08:06   0:00 dbus-daemon --system
avahi       18  0.0  0.0  32488  3096 ?        S    08:06   0:00 avahi-daemon: running [ubuntu.local]
avahi       19  0.0  0.0  32100   256 ?        S    08:06   0:00 avahi-daemon: chroot helper
root        20  0.4  0.0 141000 10320 ?        S    08:06   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        21  0.0  0.0  67380  5832 ?        S    08:06   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        23  0.1  0.0  20224  3204 ?        Ss   08:06   0:00 /bin/bash
root        37  0.0  0.0  17500  2072 ?        R+   08:06   0:00 ps aux

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:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.3  0.0  74180  6232 ?        Ss   08:09   0:00 netatalk -d
root        21  0.8  0.0 141000 10472 ?        S    08:09   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        22  0.0  0.0  67380  5820 ?        S    08:09   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        23  0.5  0.0  20232  3240 ?        Ss   08:09   0:00 /bin/bash
root        32  0.0  0.0  17500  2184 ?        R+   08:09   0:00 ps aux

Therefore, the avahi-daemon and dbus services aren't being restarted along with the other services.

Temporary Solution:
Running service dbus start then service avahi-daemon start then kill -1 1 (PID 1 for netatalk -d) resolves the issue until the next boot/error. Running services:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.0 147912  6336 ?        Ssl  09:05   0:00 netatalk -d
root        20  1.0  0.0 141184 10340 ?        S    09:05   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        21  0.0  0.0  67380  5756 ?        S    09:05   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        22  0.0  0.0  20248  3260 ?        Ss   09:05   0:00 /bin/bash
message+    43  0.0  0.0  42124  2188 ?        Ss   09:05   0:00 /usr/bin/dbus-daemon --system
avahi       60  0.1  0.0  32364  3200 ?        S    09:06   0:00 avahi-daemon: running [ubuntu.local]
avahi       61  0.0  0.0  32100   256 ?        S    09:06   0:00 avahi-daemon: chroot helper
root        63  0.0  0.0  17500  2132 ?        R+   09:06   0:00 ps aux

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 with update-rc.d avahi-daemon defaults gives the following output:

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.6  0.0  74180  6092 ?        Ss   09:10   0:00 netatalk -d
avahi       18  0.0  0.0      0     0 ?        Z    09:10   0:00 [avahi-daemon] <defunct>
avahi       19  0.0  0.0      0     0 ?        Z    09:10   0:00 [avahi-daemon] <defunct>
root        20  5.3  0.0 141000 10384 ?        S    09:10   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        21  0.0  0.0  67380  5688 ?        S    09:10   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        22  1.0  0.0  20248  3264 ?        Ss   09:10   0:00 /bin/bash
root        30  0.0  0.0  17500  2128 ?        R+   09:10   0:00 ps aux

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.

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.6  0.0 147912  6100 ?        Ssl  09:19   0:00 netatalk -d
message+    17  0.0  0.0  42124  2256 ?        Ss   09:19   0:00 dbus-daemon --system
avahi       20  0.3  0.0  32488  2980 ?        S    09:19   0:00 avahi-daemon: running [ubuntu.local]
avahi       21  0.0  0.0  32100   256 ?        S    09:19   0:00 avahi-daemon: chroot helper
root        22  4.3  0.0 141000 10412 ?        S    09:19   0:00 /usr/sbin/afpd -d -F /etc/afp.conf
root        23  0.0  0.0  67380  5832 ?        S    09:19   0:00 /usr/sbin/cnid_metad -d -F /etc/afp.conf
root        25  2.0  0.0  20252  3040 ?        Ss   09:19   0:00 /bin/bash
root        32  0.0  0.0  17500  2076 ?        R+   09:19   0:00 ps aux

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.

# service dbus start 
Removing stale PID file /var/run/dbus/pid..
Starting system message bus: dbus.

So far the results are good. Replacing avahi-daemon -D with service avahi-daemon start might be a good idea as well, given these findings.

Conclusion
I suggest using service dbus start in place of dbus-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.

[cptactionhank]

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).