• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst No service file found in /etc/avahi/services

W

wbwb

Auf meinem Rechner (Tumbleweed, KDE 6.3.2) läuft der avahi-daemon.
Code: 
# systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-03-04 21:52:13 CET; 4 days ago
 Invocation: 241c1be8ebc84cbf9ee2e0146d514e20
TriggeredBy: ● avahi-daemon.socket
   Main PID: 1574 (avahi-daemon)
     Status: "Server startup complete. Host name is blabla.local. Local service cookie is 1388330504."
      Tasks: 1 (limit: 37628)
        CPU: 4.553s
     CGroup: /system.slice/avahi-daemon.service
             └─1574 "avahi-daemon: running [blabla.local]"
Warum, weiß ich nicht wirklich. Vielleicht wurde er mit der Installation gestartet. Meine Drucker brauchen ihn jedenfalls nicht.
Wie dem auch sei, mein Log wird im 20sec Takt von folgenden drei aufeinander folgenden Zeilen geflutet:
Code: 
# journalctl -f
avahi-daemon[..]: No service file found in /etc/avahi/services.
avahi-daemon[..]: Failed to parse address 'fe80::1%enp0s13f0u3u4', ignoring.
avahi-daemon[..]: Failed to parse address 'fe80::1%wlp114s0f0', ignoring.
Und ja, i.d. Tat gibt's in /etc/avahi/services weder 'service files', noch irgend etwas anderes
Code: 
# l /etc/avahi/services
total 0
drwxr-xr-x 1 root root   0 Nov 20 11:09 ./
drwxr-xr-x 1 root root 102 Nov 20 11:09 ../
Meine resolv.conf beinhaltet
Code: 
# cat /etc/resolv.conf
# Generated by NetworkManager
search Speedport_W_723V_1_47_000
nameserver fe80::1%enp0s13f0u3u4
nameserver 192.168.2.1
nameserver fe80::1%wlp114s0f0
Die Link-local Adressen sind also da (Man beachte: Speedport W723V :cool:) und passen auch mit
Code: 
# ip a | grep -e enp0s13f0u3u4 -e wlp114s0f0
3: wlp114s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.2.162/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp114s0f0
7: enp0s13f0u3u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.2.185/24 brd 192.168.2.255 scope global dynamic noprefixroute enp0s13f0u3u4
Was sind das für service files die da fehlen, braucht man die(?)
und was will der avahi-daemon da denn 'parsen' das er nicht findet(?)
und muss er das und warum(?)
und natürlich insbesondere: wie bekomme ich die Meldungen aus dem Log?

(Dr. Googles Therapievorschläge haben mir bisher nicht geholfen.)
 
susejunky

susejunky

Moderator
Teammitglied
wbwb schrieb:
... Wie dem auch sei, mein Log wird im 20sec Takt von folgenden drei aufeinander folgenden Zeilen geflutet:
Code: 
# journalctl -f
avahi-daemon[..]: No service file found in /etc/avahi/services.
avahi-daemon[..]: Failed to parse address 'fe80::1%enp0s13f0u3u4', ignoring.
avahi-daemon[..]: Failed to parse address 'fe80::1%wlp114s0f0', ignoring.
Und ja, i.d. Tat gibt's in /etc/avahi/services weder 'service files', noch irgend etwas anderes
Zum Vergrößern anklicken....
Zu den avahi services siehe
Code: 
man avahi.service
oder
Wenn Du avahi nicht benötigst, dann deaktiviere oder deinstalliere es doch?! Ich selbst nutze avahi nicht und habe es auch nicht installiert.
 
OP
W

wbwb

Sauerland schrieb:
Poste mal:
Code: 
zypper se -si avahi
Zum Vergrößern anklicken....

Code: 
# zypper se -si avahi
Loading repository data...
Reading installed packages...

S  | Name                   | Type    | Version  | Arch   | Repository
---+------------------------+---------+----------+--------+----------------------
i  | avahi                  | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-client3       | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-client3-32bit | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-common3       | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-common3-32bit | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-core7         | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-devel         | package | 0.8-37.2 | x86_64 | Main Repository (OSS)
i  | libavahi-glib1         | package | 0.8-37.3 | x86_64 | Main Repository (OSS)
i  | libavahi-libevent1     | package | 0.8-37.2 | x86_64 | Main Repository (OSS)

susejunky schrieb:
Wenn Du avahi nicht benötigst, dann deaktiviere oder deinstalliere es doch?!
Zum Vergrößern anklicken....
Ja ... das dachte ich auch erst - bevor ich hier dann doch lieber noch mal nachfrage, denn:
Code: 
# systemctl stop avahi-daemon
Stopping 'avahi-daemon.service', but its triggering units are still active:
avahi-daemon.socket
Warum ist dieser Socket noch lebendig, wenn ich den Service stoppe?
 
S

Sauerland

Erst den service disablen:
Code: 
systemctl disable avahi-daemon.service
dann stoppen:
Code: 
systemctl stop avahi-daemon.service
dann den socket stoppen:
Code: 
systemctl stop avahi-daemon.socket
 
S

Sauerland

@susejunky
Hab ich so bei mir ausprobiert, funktioniert nicht.
disable stoppt auch nicht.

Letzten Beitrag von mir hab ich ausprobiert und funktioniert.

Der socket wird durch den service aktiviert.
 
OP
W

wbwb

Habe beides probiert. Zunächst mit laufendem avahi-daemon (so wie im Thread Start)
Code: 
# ss -a | grep avahi
nl    UNCONN     0      0                                                                    rtnl:avahi-daemon/206525                  *      
nl    UNCONN     0      0                                                                    rtnl:avahi-daemon/206525                  *      
u_str LISTEN     0      4096                                             /run/avahi-daemon/socket 1724387                             * 0
Dann nach den 3 Schritten von @Sauerland
Code: 
# ss -a | grep avahi
also kein Socket mehr und der avahi-daemon ist natürlich inactive (dead).

Oder mit laufendem avahi-daemon (so wie im Thread Start) und dann nach den 3 Schritten von @susejunky
Code: 
# ss -a | grep avahi
also auch kein Socket mehr und der avahi-daemon ist auch inactive (dead).

Wenn ich ss richtig angewendet habe(?) wären bei mir damit anscheinend beide Wege hilfreich.
In jedem Fall habe ich gelernt, dass man auch einen Socket mit systemctl stoppen kann. Nett.

Jetzt lasse ich das Ding 1-2 Tage laufen und wenn sich nichts im Zusammenhang mit avahi beschwert, werden die zugehörigen Packete entfernt.
 
Zuletzt bearbeitet:
OP
W

wbwb

Der Diskurs hat sich jetzt zwar ein bisschen von der ursprünglichen Frage entfernt, aber für mich reicht das als Lösung allemal.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben