summaryrefslogtreecommitdiff
path: root/Utility
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2015-06-02 14:38:24 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2015-06-02 14:38:24 -0400
commitcae0e19d03f8b4dc8c2e43dd36aa067c0d02a6e4 (patch)
treebafd769e01cc32d7f7ead6c6008233846a0620f9 /Utility
parent91dfe3bc1a7cc678ade4f03756f1065f3a72c590 (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')
-rw-r--r--Utility/DBus.hs10
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 $