Apple has the same problem with launchd.
In Apple's case, the trigger messages are not entirely asynchronous, as with systemd, but they may as well be, since the Mac ports being used most frequently do not have peer information available, and are (effectively) just integers.
This leads to what I call the "on behalf of" problem.
Something starts running. And you want to know *why*. Clearly, it;s running because someone requested one or more of the services it provides -- but there's no way to know who it is running "on behalf of" to provide that service.
Say, however, you figure out that service 'C' is running "on behalf of" service 'M'.
Who is service 'M' running "on behalf of"?
In Mac OS X, it's *almost* possible to get the information as to where every thread in everything is pending a response from something else in its stack. But it's not possible to figure out the entity relationship, because you can't trace the other end of a connection.
So I can perhaps figure out that an application is pinwheeling -- that's the cursor that the display server puts up on a Mac OS X application when it's not responding to "are you alive?" chatter from the display server within it's main app loop. It happens when someone does a blocking operation in the main app loop, instead of packaging up the operation that might block, and giving it to a thread delegate instead: it means someone made a coding error, because they expected an operation to never block ...and then it blocked.
So I actually want to see where it's blocked (which I can) and see who it's trying to get work from, that's not responding to the work request -- which I can't, because I can't see "the service on the other end".
Both launchd/Mach ports, and systemd suffer from this problem.
But if I were permitted to ask the question... then I could find the next entity in the chain... and I could ask "what are you waiting on?", and follow the chain down to the actual problem.
The display server puts up the pinwheel, I option-click it (or whatever), and a dialog pops up and says:
MagicDraw is hung waiting for RemoteFilerPro,
which is hung waiting for access to "remote_filter_cache_file.ca",
which is hung in the kernel on a permissions check,
which is hung, waiting on DirectoryServices,
which is hung, waiting on mDNSResponder,
which is hung waiting on a network response from "VPN.bob.net",
which is hung waiting on a response from network interface "Wi-Fi2" ...which would be frigging useful. Because then I could say to myself "Oh. The VPN is down because the Wi-Fi is out. Better reset the router again."
But I can't do that.