Change:
Describe the bug When printing to Brother MFC-L2700DW printer (with created from a similar model in nixpkgs), CUPS often (but not always) complains about "Impossible to connect to Name or service not known" even though I followed the and enabled . To Reproduce Steps to reproduce the behavior: Brother MFC-L2700DW printer. NixOS as follows: (full configuration ) something to http://localhost:631/printers/BrotherMFC-L2700DWseries and see the "Impossible to connect to Name or service not known" message. Expected behavior The job is sent to the printer and printed. Additional context When the printer cannot be connected, running usually helps and the stuck job gets to the printer. After my investigation, I think that the cause is long delay in mDNS name resolution. By default NixOS uses NSS module, which tries to resolve both IPv4 and IPv6 addresses sequentially. It seems to start with IPv6, which does not resolve to a valid address so after 5s timeout the resolution continues with IPv4. So the address of the printer is returned after slightly more that 5 seconds (can be verified with ), which seems to be too long for CUPS so it gives up and tries again later and the same repeats, because nscd in NixOS does not cache the results. My current solution to the problem is to switch from NSS to with the following in my : I've also tried but it didn't help. The question is whether to make it easier for others. Possible things that come to my mind: Document this at Wiki Extend to provide e.g. option. Enable caching in nscd Something else? Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(wsh): nixpkgs: Maintainer information:
Confirm, I have the same problem (with Xerox WorkCentre). And your workaround fixed it for me too. Thanks!
I wanted to link this issue from the and found that there a comment suggesting that he might have the same problem. does the above workaround make your setup work without restarting cups after booting? If yes, I'd update your comment, because it's not accurate. The is not needed, because it is pulled in by mentioned on the previous line.
Hi, I'm back and I'll test your workaround soon. About , I thought it should have been pulled, but it wasn't at the time. I vaguely remember triple checking and it wasn't there.
Sorry, I can't test it again. My printer is busted.
OK, thanks for letting me know :-)
Ok, my printer has sudently revived and this solves the issue for me as well.
I marked this as stale due to inactivity. &rarr;
Confirming that the issue still exists with current nixos-unstable.
Out of curiosity, is this workaround supposed to break or use outdated softwares? If not, would it make sense to directly apply your workaround by default?
This workaround makes mDNS working only for IPv4. If you are on a IPv6-only network, mDNS won't work for you. On mixed IPv4/IPv6 network, you might not see some devices. That's definitely not what some people want :-) Btw, may be relevant to this problem. I've not read all the comments there, but the keywords seem similar to what I remember when debugging this issue. I think the solution might be to increase or decrease some timeout somewhere, but I'm not sure where. More debugging/analysis is needed.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Same happening here with a Canon MF643C. I found a workaround, but yours seems better. Mine was to manually add the expected on '/etc/hosts' file. This only works if your printer has a fixed ip (like 10.1.2.3). networking.extraHosts = '' 10.1.2.3 '';
I also hit this issue. Given that (I assume) most people are running ipv4, can we not try the v4 exclusive module first, and still fallback to the one that also works with v6, so that it "just works" for this rather common use case? Given, that will slowdown v6 name resolution, but I guess we could also add a big warning in the option.
Looks like this is closed by
Unfortunately, that commit is not sufficient for me. Current version of CUPS complains with: "No destination host name supplied by cups-browsed for printer "BrotherMFCL2700DWseriesmDNS", is cups-browsed running?" The referenced commit makes my contain the following line: hosts: mymachines mdns4minimal [NOTFOUND=return] files myhostname dns mdns With it, running returns an IPv6 address: fd76:76f3:2dcb:0:3205:5cff:fecb:4509 From the output of it seems that the command first asks for IPv6 address, so the is somehow ignored and the address is returned by at the end of the line. I can ping and connect that address via so I don't know why CUPS cannot print to it. Anyway, if I disable IPv6 in the printer, returns the IPv4 address, but only after the 5 second timeout, which is too long for CUPS. What I need is also at the end of line. I'll ask at and submit a PR to do that if people do not complain.
Please submit a PR.
Uses a direct printer install. Same sort of problems encountered.

Discussion:
system.nssModules = optional (cfg.nssmdns4 || cfg.nssmdns6) pkgs.nssmdns; system.nssDatabases.hosts = let <del> mdnsMinimal = if (cfg.nssmdns4 && cfg.nssmdns6) then "mdns_minimal" </del> <ins> mdns = if (cfg.nssmdns4 && cfg.nssmdns6) then "mdns" </ins> else if (!cfg.nssmdns4 && cfg.nssmdns6) then <del> "mdns6_minimal" </del> <ins> "mdns6" </ins> else if (cfg.nssmdns4 && !cfg.nssmdns6) then <del> "mdns4_minimal" </del> <ins> "mdns4" </ins> else ""; in optionals (cfg.nssmdns4 || cfg.nssmdns6) (mkMerge [ <del> (mkBefore [ "${mdnsMinimal} [NOTFOUND=return]" ]) # before resolve (mkAfter [ "mdns" ]) # after dns </del> <ins> (mkBefore [ "${mdns}_minimal [NOTFOUND=return]" ]) # before resolve (mkAfter [ "${mdns}" ]) # after dns </ins> ]); environment.systemPackages = [ cfg.package ];