12:13:40 Hi. 12:13:47 I want to tell about a bug. 12:15:21 The issue is about: 12:15:24 maintenance 14:12:53 svc:/system/avahi-bridge-dsd:default 12:17:32 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. 12:17:47 I show the log file entry: 12:19:15 root@openindiana ~ # tail -n 3 /var/svc/log/system-avahi-bridge-dsd:default.log 12:19:27 Failed to kill daemon: No such process 12:19:28 [ Jul 7 14:12:53 Method "stop" exited with status 0. ] 12:19:28 [ Jul 7 14:12:53 Restarting too quickly, changing state to maintenance. ] 12:20:06 The SMF service multicast runs too, does not enter maintenance state thus stays online. 12:20:50 I brought this up in #openindiana channel two days ago, and was asked to tell this in the #oi-dev channel, too. 12:21:14 Only reboot fixes the problem above. 12:23:28 Must reboot to bring svc:/system/avahi-bridge-dsd:default online again. svcadm clear/restart won't bring online the SMF service. 17:24:32 Hi. If someone wants to answer to my bug-report, I am regularily in the #openindiana channel. 17:25:37 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. 17:29:12 Aedil: situation sounds like a missing piece in integration of avahi-bridge-dst or some other part of MATE with SMF. 17:29:17 You could run the broken application by hand. Something like 17:29:46 avahi-daemon-bridge-dsd --debug 17:30:10 you said " The SMF service multicast runs too". did you mean svc:/network/dns/multicast:default ? 17:30:41 might generate more useful diagnostics (although it's supposed to log to syslog, so you could check if anything has ended up there) 17:31:01 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.. 17:32:26 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. 17:32:44 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 17:35:58 Well, on OI anyway, I don't think other distros inherited it 17:36:43 Yes. I mean svc:/network/dns/multicast:default. I will disaable svc:/network/dns/multicast:default and try if that fixes the issue! 17:37:25 I am rebooting my OI VM. 17:43:01 saw some oddness with the bridge enabled which went away when I disabled it; haven't dug into how it's all structured. 17:43:15 svc:/network/dns/multicast:default, the SMF service avahi-daemon-bridge-dsd is offline after boot-up, but seems to work good. 17:43:31 After disabling the SMF service 17:45:59 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. 17:47:03 When I originally activated my AVAHI MDNS service on OI, someone suggested me to also enable the SMF multicast service. 17:47:54 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. 18:17:52 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. 18:20:20 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).