On Sun, Mar 18, 2012 at 3:25 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan <pa...@poluan.info> wrote: >> >> On Mar 18, 2012 3:52 PM, "Canek Peláez Valdés" <can...@gmail.com> wrote: >>> >>> If the config file doesn't exists, the service will not start, and you >>> can check the reason why with >>> >>> systemctl status sshd.service >>> >>> And of course you can set another mini sevice unit file to create the >>> hostkeys. But I repeat: I think those tasks belong into the package >>> manager, no the init script. >>> >> >> Between installation by package manager and actual execution by the init >> system, things might happen on the required file(s). Gentoo's initscript >> guards against this possibility *plus* providing helpful error messages in >> /var/rc.log >> >> Or, said configuration files might be corrupted; the OpenRC initscript -- if >> written defensively -- will be able to detect that and (perhaps) fallback to >> something sane. systemd can't do that, short of putting all required >> intelligence into a script which it executes on boot. > > That is a completely valid point, but I don't think that task belongs > into the init system. The init system starts and stops services, and > monitors them; checking for configuration files and creating hostkeys > is part of the installation process. If something got corrupted > between installation time and now, I would prefer my init system not > to start a service; just please tell me that something is wrong. > > However, it's of course debatible. I agree with systemd's behavior; > it's cleaner, more elegant, and it follows the Unix tradition: do one > thing, and doing it right.
I like and see benefit to the systemd approach, honestly, but I don't think it necessarily follows to say that "that belongs in the installation process, since it shouldn't be the responsibility of the init process." The way things sit currently, Gentoo doesn't default to adding new services to any runlevel, and in the process of setting up or reconfiguring a system, services may be added, removed, then possibly added again. Having a service's launch script perform one-time checks makes perfect sense in this regard. It's lazy evaluation; you don't do non-trivial work until you know it needs to be done. (And generating a 2048-bit or 4096-bit SSH key certainly qualifies as non-trivial work!) Also, I think the "code golf" argument is a poor one; how many lines something does to meet some particular goal ignores any other intended goals the compared object also meets. When you're comparing apples to apples, the argument is fine. When you're comparing apples to oranges, the argument is weakened; they're both fruits, but they still have different purposes in the larger context. In this case, I think the happy medium would be for systemd to start a service-provided launch script, which performs whatever additional checks are wanted or desired. Either way, it's the responsibility of whoever maintains the package for that service. -- :wq
