Hi.

I want to tell about a bug.

The issue is about:

maintenance 14:12:53 svc:/system/avahi-bridge-dsd:default

The SMF avahi-bridge-dsd:default service runs fine, until I log-in to MATE DM through lightdm and start the Caja file manager and access the network (Windows network). After opening the Caja file manager and opening the Netork tab, svc:/system/avahi-bridge-dsd:default enters maintenance state.

I show the log file entry:

root@openindiana ~ # tail -n 3 /var/svc/log/system-avahi-bridge-dsd:default.log

Failed to kill daemon: No such process

[ Jul 7 14:12:53 Method "stop" exited with status 0. ]

[ Jul 7 14:12:53 Restarting too quickly, changing state to maintenance. ]

The SMF service multicast runs too, does not enter maintenance state thus stays online.

I brought this up in #openindiana channel two days ago, and was asked to tell this in the #oi-dev channel, too.

Only reboot fixes the problem above.

Must reboot to bring svc:/system/avahi-bridge-dsd:default online again. svcadm clear/restart won't bring online the SMF service.

Hi. If someone wants to answer to my bug-report, I am regularily in the #openindiana channel.

I switched my /home on Linux from a 4TB HDD to a M.2 NVME SSD from Samsung. The login time into KDE is much faster, good speed boost in overal for several use-cases.

Aedil: situation sounds like a missing piece in integration of avahi-bridge-dst or some other part of MATE with SMF.

You could run the broken application by hand. Something like

avahi-daemon-bridge-dsd --debug

you said " The SMF service multicast runs too". did you mean svc:/network/dns/multicast:default ?

might generate more useful diagnostics (although it's supposed to log to syslog, so you could check if anything has ended up there)

both avahi and /network/dns/multicast are mDNS agents. I wouldn't think you'd need both running but I haven't looked at this closely..

I ended up disabling system/avahi-bridge-dsd:default on my systems; haven't noticed any ill effects but I'm not a big mDNS user.

sommerfeld on illumos we run mdns as the agent, we run an avahi bridge to it (not as the agent) so that clients expecting the avahi api still work

Well, on OI anyway, I don't think other distros inherited it

Yes. I mean svc:/network/dns/multicast:default. I will disaable svc:/network/dns/multicast:default and try if that fixes the issue!

I am rebooting my OI VM.

saw some oddness with the bridge enabled which went away when I disabled it; haven't dug into how it's all structured.

svc:/network/dns/multicast:default, the SMF service avahi-daemon-bridge-dsd is offline after boot-up, but seems to work good.

After disabling the SMF service

Yes, thank you! Disabling the service multicast seems to fox my problem with Caja (click the Network tab). Now I can click the network tab in Caja and the OI MDNS server on the client seems to still be active and oversable through my other MDNS clients.

When I originally activated my AVAHI MDNS service on OI, someone suggested me to also enable the SMF multicast service.

I can now understand the multicast serice is like the mdnsd service shipped with NetBSD that you would not enable in addition to the avahi server.

Yes. I was the problem enabling svc:/network/dns/multicast:default in addition to offline 19:37:53 svc:/system/avahi-bridge-dsd:default. Now my OI mdns Avahi server stays observable in my local network.

I use Avahi with the ssh.service file enabled. This is very nice in you can show the file system through sftp with a double click on many systems on all discovered hosts in the network tab of the file browser (like nautilus).