Every time I have the same result. It looks like it’s running OK:
[monty@nix0:~/code/nixes]$ nixos-version
23.11.20240322.56528ee (Tapir)
[monty@nix0:~/code/nixes]$ sudo systemctl status avahi-daemon
WARNING: terminal is not fully functional
Press RETURN to continue
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/etc/systemd/system/avahi-daemon.service; enabled; preset: enabled)
Active: active (running) since Tue 2024-04-09 10:01:54 PDT; 2 days ago
TriggeredBy: ● avahi-daemon.socket
Main PID: 929 (avahi-daemon)
Status: "Server startup complete. Host name is nix0.local. Local service cookie is 3745394373."
IP: 10.4M in, 27.9K out
IO: 1.5M read, 0B written
Tasks: 1 (limit: 9405)
Memory: 2.8M
CPU: 10.125s
CGroup: /system.slice/avahi-daemon.service
└─929 "avahi-daemon: running [nix0.local]"
But the name never resolves:
[monty@nix0:~/code/nixes]$ avahi-resolve -vn nix0.local
Server version: avahi 0.8; Host name: nix0.local
Failed to resolve host name 'nix0.local': Timeout reached
[monty@nix0:~/code/nixes]$ ping nix0.local
ping: nix0.local: Name or service not known
I have a debian server that also uses avahi for timemachine and everything works there, so I have something to compare to that is working.
After trying several variations with avahi-resolve (-vn, -v4n and -v6n) on my laptop, I find it often fails to resolve the laptop. (Interestingly, the output clearly reports the host name of the laptop, and then reports timeout, same as yours.)
It did resolve a few times, but failed more often. Trying to resolve the name of a different machine (also running nixOS) always succeeds. None of this was reported in the system journal.
Repeating the steps on the remote machine fails in exactly the same way: avahi-resolve -vn host.local reports timeout, but avahi-resolve -vn remote.local succeeds. That is, my remote can resolve my laptop but not itself.
This suggest the problem may be specific to resolving the machine running the resolver.
The system journal reports several messages for avahi-daemon during startup, including WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. These problems seem consistent with such a warning. I haven’t investigated the warning yet because I have more critical problems. (I do not use .local much anymore.)
Can you see if your failures are limited to resolving the name of the local machine?
Unfortunately I have no clear answers. Networking on Linux has many moving parts and they do not all play well together. Too many tools try to manage too much of the stack, leading to conflicts.
To troubleshoot, I first would try configuring services.avahi.enable = true; and leave all other settings at their default values. (My better-working hosts using avahi are configured this way.) This should result in nssmdns = false. Maybe this will work, maybe not.
This conflicts with some of what avahi tries to do. But maybe this is why my results differ from yours. (I have a vague recollection that resolved takes extra steps to support the resolver built into glibc, which could account for better behavior. Embedding hostname resolution in glibc seems insane to me.)
You also might consider installing the nix package nssmdns. I would expect the nixos avahi config to manage that, but maybe not.
Arch Wiki: Avahi may help you a bit; although there is not much there. This lead me to exploring avahi-resolve -v4n and -v6n, as well as avahi-browse. There also are non-avahi tools useful for testing mDNS lookups, which could provide useful info – especially if they actually use the network instead of whatever “magic” glibc does.
The avahi-daemon supports --debug to increase log verbosity, but I’d have to dig much deeper to figure out how to activate that.
I hope this helps. Let us know if you learn anything more about the problem.
Thanks. I tried using just services.avahi.enable = true;, no luck. Then I tried with your resolved config snippet. Same thing. The ArchWiki link is handy, thanks. I’ll play with it a bit more and see what I can come up with. I’m thinking that maybe running Debian and then just managing the software with nix is going to be easier to get working than using NixOS. I don’t know enough about all of the layers to be able to debug something like this.
@montyz did you ever get to the bottom of this?
I used to have just services.avahi.enable = true; enabled and both .local resolution and printing worked ~ a year ago. Somewhere down the line printer stopped working and I stopped using a mac machine on the network, so didn’t bother fixing avahi.
Got here by trying to fix the printer (which works if I access it by .lan), but .local is broken
Hm never mind, manually switched from .lan to .local without any configuration.nix changes and it started magically working again . Love these types of issues.
. Love these types of issues.