> All those init.d scripts do about 95% the same thing, all hacked > together in shell. Most of them are probably just slightly edited > versions of some few paleo-scripts. > > Set the location of the pid file, set the path of the executable, set > the command line flags/options, maybe change some flags/options based > on some options in another file like /etc/sysconfig/daemon_name (also > shell commands which are just executed inline), then the > start/stop/reload/restart/status case statements. And the dependencies > of course. > > It really could just be config files like xinetd or logrotate except > for a few hard cases where you could have a "run this script" > attribute.
Replacing "run these scripts in the right order" with a config-driven "service manager" sounds like a sensible development. (Not necessarily the One True Way, but certainly an option). Pulling complicated things like chroot, capabilities etc into one place, getting them right, and then letting services specify what they want, rather than everyone having to re-invent the same shell scripts sounds like it would encourage use of those features. I can even see some more advanced functionality to specify checks / frequencies for "is this service still running / alive" that effectively moves a lot of watchdog functionality into the "service manager". I'm somewhat confused (without reading the implementation details, just conceptually) as to why the "service manager" is also providing DHCP client, SNTP client, virtual consoles, session management... I can completely understand why the "do one thing" crowd are taking objection to that. Regards, Tim.
