[dv_dt]

It's an interesting feature but inetd (or xinetd) did it for a long time decoupled from the boot process.

A pro for systemd doing it is maybe consistent nomenclature for service startup, but a con is that it couples in yet another use case to systemd which may lead to a higher risk of security, maintainability problems down the line.

[SwellJoe]

I'm not sure why starting services two different ways would lead to fewer security problems. Seems like a classic example of reducing surface area for attack. One way to start services means one pile of code to audit, one configuration syntax to understand (that it's new is a negative, but that it is declarative rather than procedural in the case of initscripts is a huge win; xinetd is also declarative, so systemd is converging on the known better way to configure starting services), one place to look when figuring out what is running and what is supposed to be running on your system.

There have been init bugs in the past. There have been xinetd bugs in the past (and inetd was occasionally notorious with regard to security, though it was usually the services it provided access to rather than inetd itself). There will be bugs in systemd. But, how does consolidating service startup into one project increase the risk?

[dv_dt]

Well for one, systemd hooks to a large number of functions/subsystems that used to be more isolated. Logging, udev, dbus, churn, networking functions, etc. So it's a bit of a judgement call to say it has a larger or smaller attack surface than separating the functions out. I don't know how to really quantify if in the end it ends up more risky one way or another.