diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2015-06-02 14:38:24 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2015-06-02 14:38:24 -0400 |
| commit | cae0e19d03f8b4dc8c2e43dd36aa067c0d02a6e4 (patch) | |
| tree | bafd769e01cc32d7f7ead6c6008233846a0620f9 /Utility/DBus.hs | |
| parent | 91dfe3bc1a7cc678ade4f03756f1065f3a72c590 (diff) | |
Revert "When listing DBus services, also list activatable services."
This reverts commit 334954d8bf9113b679f8af29ad481b0daece86f7.
Sebastian thinks best to revert this:
It seems to me the reason I needed to look at activatable sockets
might actually be a networkd bug, and I was in error about patch 0001.
On my machines (without DHCP), networkd quits after configuring the
links. I thought this had to do with network activation, but that was
probably mistaken. This was obscured by my testing the change by doing
systemctl stop/start on networkd; now that I actually unplugged the
network cable, I noticed no DBus messages are triggered by this on
this machine. Your test case might have had a similar problem
(networkd quitting on idle). Might be related to [1].
On another machine (with DHCP) networkd remains active all the time,
and patch 0002 works there. You might want to revert 0001, though:
Suppose someone’s running no manager at all, so that polling would be
required. Because networkd is still listed as activable, we would
refrain from polling – by mistake, because networkd doesn’t seem to
actually go active if we listen on its bus, and it’s listed as
activable even when it’s not configured. Connectivity-related messages
will come in when stopping/starting the service, but not when
unplugging the cable.
Diffstat (limited to 'Utility/DBus.hs')
| -rw-r--r-- | Utility/DBus.hs | 10 |
1 files changed, 2 insertions, 8 deletions
diff --git a/Utility/DBus.hs b/Utility/DBus.hs index 108ef735b..5b0470301 100644 --- a/Utility/DBus.hs +++ b/Utility/DBus.hs @@ -22,14 +22,8 @@ type ServiceName = String listServiceNames :: Client -> IO [ServiceName] listServiceNames client = do - active <- do - reply <- callDBus client "ListNames" [] - return $ fromVariant =<< headMaybe (methodReturnBody reply) - activatable <- do - reply <- callDBus client "ListActivatableNames" [] - return $ fromVariant =<< headMaybe (methodReturnBody reply) - let service_names = fromMaybe [] active ++ fromMaybe [] activatable - return service_names + reply <- callDBus client "ListNames" [] + return $ fromMaybe [] $ fromVariant =<< headMaybe (methodReturnBody reply) callDBus :: Client -> MemberName -> [Variant] -> IO MethodReturn callDBus client name params = call_ client $ |