Mai 19 15:06:08 Framework13 avahi-daemon[140597]: Got SIGTERM, quitting.
Mai 19 15:06:08 Framework13 avahi-daemon[140597]: Leaving mDNS multicast group on interface enp127s0u1u3u3.IPv6 with address ____::____.
Mai 19 15:06:08 Framework13 systemd[1]: Stopping Avahi mDNS/DNS-SD Stack...
Mai 19 15:06:08 Framework13 avahi-daemon[140597]: Leaving mDNS multicast group on interface enp127s0u1u3u3.IPv4 with address 192.168.x.y.
Mai 19 15:06:08 Framework13 avahi-daemon[140597]: Leaving mDNS multicast group on interface lo.IPv6 with address ::1.
Mai 19 15:06:08 Framework13 avahi-daemon[140597]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
Mai 19 15:06:08 Framework13 avahi-daemon[140597]: avahi-daemon 0.8 exiting.
Mai 19 15:06:08 Framework13 systemd[1]: avahi-daemon.service: Deactivated successfully.
Mai 19 15:06:08 Framework13 systemd[1]: Stopped Avahi mDNS/DNS-SD Stack.
Can anyone here confirm that my observation is correct? Does anyone have a link to further information?
When I start the avahi-daemon.service manually, the printer is found as expected and I can print without any problems.
I find two things disturbing and unattractive at this point.
Firstly, it is a pity that the avahi-daemon has been deactivated ‘just like that’. Perhaps the reference to this was not noticed in the other messages of the update.
Secondly, it is a pity that the printer also stopped working with the removal of IPP Everywhere.
On the second point, here is the long story in brief:
This is my first newly purchased printer. Of course I paid attention to Linux compatibility. I was all the more delighted that I only had to connect the printer to the network and was able to print without any further installation work. Setting it up under Manjaro seemed as easy and convenient as on my wife’s iPad and the children’s Windows computer.
Barely two weeks later, I have to print a handout at the last minute. The shock is profound when the new printer suddenly no longer exists and the quick installation via CUPS only produces a jumble of numbers on the paper.
Why does the installation of a printer that was already ‘just working’ have to require two hours of research and analysis as well as an AUR-ppd package? So where exactly are we on the road to a ‘Year of the Linux Desktop’?
To check avahi-daemon.socket and avahi-daemon.service
systemctl --no-pager -l status avahi-daemon.socket avahi-daemon.service
My partner’s Epson printer is not supported by IPP Everywhere driverless printing so I had to install an AUR package on my system
And any AUR package may need a rebuild after repository packages are updated
I suspect printer supports IPP Everywhere and also has a vendor-specific software driver in AUR
Please advise manufacturer name and model number of printer and name of AUR package
Okay - let’s come up with the two obvious solutions.
Like @nikgnomic and @Teo suggest, one can (re-)enable avahi again. This will work until yet an other update disables avahi.
Personally, I used an other way. I installed the printer using it’s ability to tell cups about it’s capabilities (this is what ipp everywhere is made for). It works in the cups web ui as well as on the command line.
IPv6 is known to cause issues with layman systems - that should be understand as one or more systems run by a user with no extensive knowledge on IPv6.
ipp everywhere is not depending on avahi but it is a protocol which presumably should be understood by the majority of printers.
avahi is network service discovery daemon which uses broadcast to the network’s broadcast address to discover services - including printers.
But why was avahi-daemon then disabled (as shown in my initial post)? To be on the safe side, I checked my history again. I have not deactivated the service manually.
Avahi was (and is) fully functional. The service just stopped unexpectedly and therefore a Zeroconf service was not available just at the moment I needed and expected it. This is annoying.
I get this and that’s the lesson I’ve learnt. But did I have to learn it and did I want to learn it? In my opinion, Zeroconf is there to take work off my hands and make my everyday life easier.
I can’t agree with this and I think this advice is wrong. It is precisely this type of approach that has prevented the introduction of IPv6 for 20 years. Furthermore, this attitude prevents modern IP networks from ‘just working’. Because instead of tackling things and enabling progress, the old is being held on to.
Well, almost … For Zeroconf solutions such as IPP Everywhere, mDNS (Multicast DNS) is always used. Link-local multicast addresses are used for both IPv4 and IPv6. The actual mechanism for service discovery - i.e. finding and announcing services in the local network - remains the same and is based on mDNS and DNS-SD.
mDNS is not an obstacle in my network, neither via IPv4 nor via IPv6, and works with high performance. In my opinion, a further discussion on this topic goes beyond the scope of this article.
I wanted to and did express my disappointment that a Zeroconf service had suddenly disappeared. From this perspective, I think it is good that ‘Zetar’ does not activate avahi by default.
The service got a signal to terminate - that could be caused anything - restarting the system would have restored functionality.
Then the answer is to locate the cause … and IPv6 is known to cause weird issues if not correct configured - hence the advise to disable IPv6…
You are entitled to that opinion - but unless you run a massive campus or company worldwide network you don’t need IPv6.
For private networks such as a small home network there is absolutely no reason to use IPv6 in as it is just complicating the maintenance.
No - that is not the reason. The real reason is because IPv6 is not backwards compatible with IPv4.
In any case I have no problems if the world should decide to roll out IPv6 on a massive scale as long as I can roll a private IPv4 and let my ISP handle the rest.
Even if you need a large network with 10.000 hosts - you can still manage using a private IPv4 network.
//EDIT: 2025-05-25T13:15:00Z
Just looked up the IPv6 - it became an Internet Standard in July 2017.