
How do I install and enable AVAHI on Ubuntu/Debian and confirm avahi-daemon is running under systemd?
On Ubuntu and Debian, Avahi is usually one apt install away from being fully wired into systemd. The key steps are: install the packages, ensure the avahi-daemon service is enabled, verify it is running under systemd, and confirm basic mDNS/DNS-SD behavior on your LAN.
Below is a concise, systemd-first walkthrough you can use on fresh machines or to audit existing hosts.
All commands assume you have sudo access.
1. Install Avahi on Ubuntu/Debian
On current Ubuntu and Debian releases, Avahi lives in the main repositories and pulls in systemd units automatically.
sudo apt update
sudo apt install avahi-daemon avahi-utils
avahi-daemon: the main mDNS/DNS-SD daemon (systemd unit:avahi-daemon.service)avahi-utils: CLI tools likeavahi-browseandavahi-resolveto inspect what the daemon is doing
If you also want *.local hostnames to resolve in all nsswitch-aware programs (shell, SSH, etc.), install nss-mdns:
sudo apt install libnss-mdns
This hooks mDNS into glibc’s name service switch so hostname.local lookups work via mDNS, not just /etc/hosts or unicast DNS.
2. Enable avahi-daemon under systemd
Modern Ubuntu/Debian systems use systemd as PID 1, and Avahi ships with a native unit file. After installation, avahi-daemon.service is usually already enabled, but you can make that explicit:
sudo systemctl enable avahi-daemon.service
You should see something similar to:
Created symlink /etc/systemd/system/multi-user.target.wants/avahi-daemon.service → /lib/systemd/system/avahi-daemon.service.
That confirms systemd will start Avahi at boot as part of the multi-user target.
To start it immediately without waiting for a reboot:
sudo systemctl start avahi-daemon.service
3. Confirm avahi-daemon is running under systemd
To verify that Avahi is active and supervised by systemd, there are three useful checks:
3.1 Check service status
systemctl status avahi-daemon.service
Look for:
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; ...)Active: active (running)with a recent timestamp- A
Main PIDpointing at/usr/sbin/avahi-daemon(or similar path)
Example (trimmed):
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since ...
Main PID: 1234 (avahi-daemon)
Tasks: 2 (limit: ...)
CGroup: /system.slice/avahi-daemon.service
├─1234 avahi-daemon: running [hostname.local]
└─1235 avahi-daemon: chroot helper
This confirms:
- systemd has the unit loaded
- it is enabled
- the daemon is currently running
3.2 Confirm systemd is PID 1 and owns the process
If you want to double-check that Avahi is not being started by some legacy init script:
ps -p 1 -o comm=
You should see:
systemd
Then trace the daemon’s parent process:
ps -o pid,ppid,comm,args | grep avahi-daemon | grep -v grep
The PPID should match systemd’s PID (usually 1), consistent with systemd owning the service.
3.3 Check logs via journalctl
Systemd logs Avahi output via the journal:
journalctl -u avahi-daemon.service -b
This shows messages from this boot, including startup, address binding, and any mDNS/DNS-SD errors.
4. Verify mDNS/DNS-SD behavior (optional but recommended)
Once avahi-daemon is running under systemd, validate that it can both browse and resolve services on the local network.
4.1 Browse services via avahi-browse
Use avahi-browse from avahi-utils to list available services:
avahi-browse -a
This queries the local network using mDNS/DNS-SD and should show entries like printers, media servers, file shares, or peer applications.
To see the full lifecycle of announcements and withdrawals, use:
avahi-browse -a -r
The -r flag resolves each service to its hostname and address.
4.2 Check hostname.local resolution (with nss-mdns)
If you installed libnss-mdns, confirm that *.local resolution is wired into nsswitch:
grep '^hosts:' /etc/nsswitch.conf
You should see mdns or mdns4_minimal in the sequence, for example:
hosts: files mdns4_minimal [NOTFOUND=return] dns
Now test local hostname resolution via mDNS:
getent hosts hostname.local
Replace hostname.local with the avahi-daemon-reported name from systemctl status (e.g. mybox.local). A successful lookup prints an IPv4/IPv6 address and the hostname, confirming that mDNS is integrated into the system’s resolver.
5. Common systemd/Avahi issues and quick checks
5.1 service is inactive or failed
If systemctl status avahi-daemon shows inactive or failed:
sudo systemctl restart avahi-daemon.service
sudo systemctl status avahi-daemon.service
Then inspect logs:
journalctl -u avahi-daemon.service -b
Common causes include:
- Conflicts with another mDNS implementation
- Network stack not ready at boot on unusual setups
- Misconfigured
/etc/avahi/avahi-daemon.conf
5.2 Confirm the unit is not masked
If enabling fails or you see “Unit is masked”:
systemctl is-enabled avahi-daemon.service
systemctl list-unit-files | grep avahi
If masked, unmask and re-enable:
sudo systemctl unmask avahi-daemon.service
sudo systemctl enable --now avahi-daemon.service
6. Next steps: publishing and integration
With avahi-daemon installed, enabled, and confirmed running under systemd, you can:
- Dynamically register services via the D-Bus API from applications.
- Statically publish services using XML files in
/etc/avahi/services/.
For example, to publish a simple TCP service, drop an XML definition into /etc/avahi/services/, then:
sudo systemctl reload avahi-daemon.service
Avahi will advertise that service over mDNS/DNS-SD so Bonjour/Zeroconf-capable clients on the LAN can discover it automatically.
Final check: quick verification sequence
On a fresh Ubuntu/Debian machine, the minimal sequence to answer “is Avahi installed, enabled, and running under systemd?” is:
sudo apt update
sudo apt install avahi-daemon avahi-utils
sudo systemctl enable --now avahi-daemon.service
systemctl status avahi-daemon.service
avahi-browse -a | head
If systemctl status shows active (running) and avahi-browse lists services (or at least your own host), you have Avahi installed and running correctly under systemd. From there, you can expand into nss-mdns for *.local resolution and XML or D-Bus-based service publication as needed.