I think you might have some misconceptions about how systemd starts daemons: absent any other ordering constraints, systemd will try to start multiple services simultaneously. It won’t necessarily wait for one service to finish starting before starting a second service.
Let’s take a concrete example of a database daemon, and a web daemon that stores its configuration in a database. In a traditional init system, you’d want to impose an ordering constraint so the database daemon is always started before the web daemon. If we instead use systemd and the database server supports socket activation, then it doesn’t matter what order the two daemons are started. There two possibilities:
- The database daemon starts first, and web daemon starts second. The web can talk to the database as normal.
- The web daemon starts first and blocks when it tries to connect to the database. Systemd notices the attempt to connect to the socket and starts the database daemon. The web daemon continues running once the database daemon has finished initialising and accepts the connection.
As you can see from case (2), systemd could even try to start both daemons simultaneously. It’s the act of communication that synchronises the start up of the two daemons rather than metadata in the