Explain the internal working of D-Bus service activation?

Service activation is driven by .service files, small key-value configuration files placed in directories like /usr/share/dbus-1/system-services/ for the system bus, each one mapping a bus name to the executable that provides it.

[D-BUS Service]
Name=org.example.MyService
Exec=/usr/libexec/my-service --no-fork

At startup, the bus daemon scans these directories and builds an in-memory table mapping each activatable bus name to its corresponding Exec line, without actually launching anything yet. When a method call arrives addressed to a bus name that has no current owner, the bus daemon checks this table; if a match exists, it forks and execs the specified command, then holds the original method call message in a pending queue.

The newly started process is expected to connect to the bus and call RequestName for the exact name it was activated for. Once that registration succeeds, the bus daemon delivers the queued method call to it, completing the activation transparently from the original caller's point of view, aside from the extra latency of the process actually starting up. If the process fails to register the expected name within a timeout, the original call fails with an error instead.