2 ms·
Many, many things. (Note: not an openrc expert, so not commenting on whether it's possible to arrange these things using entirely what openrc provides, in a uni
by JoshTriplett 2y ago
Many, many things. (Note: not an openrc expert, so not commenting on whether it's possible to arrange these things using entirely what openrc provides, in a uniform fashion that works identically on any openrc system.)
Universal trivial logging, including of text just printed to the daemon's stdout/stderr, and you can easily ask "give me the log messages from just this application". And you can log to memory for stateless systems, or to disk.
Service monitoring as the default expectation: services are a thing that are monitored and restarted if they fail, not a thing that gets run once and hopefully stays running.
Full integration with all kinds of event handling. Whether something is triggered by a kernel event (e.g. new device), a timer job, an incoming socket, or system boot, it uses exactly the same mechanism to start a service. So you don't need one mechanism (cron) for timers and another (inetd) for sockets and another (init scripts) for system boot. And all of them use the same service monitoring, logging, etc.
Easy integration with various kinds of sandboxing. One line in a .service file and a service runs in a chroot, or has no network access, etc.
And then there's just the general standardization effort to unify the dozens of different places that things get configured into one mechanism that's the same across distributions. For instance, before systemd, distributions had various different places to configure the hostname; now, distributions have largely standardized on `/etc/hostname`. There are many more instances of such standardization, and most of them have been successful.