Am 12.07.2014 um 17:08 schrieb Lamar Owen <lowen at pari.edu>: > [I wasn't going to reply; but after thinking about it for quite a while, > there are a few points here that deserve just a bit of level-headed > attention.] > > On 07/11/2014 10:53 AM, David G. Miller wrote: >> Les Mikesell <lesmikesell at ...> writes: >> >>> Or, if you want things to respawn, the original init handled that >>> very nicely via inittab. > > Replying to Les' comment: the original inittab respawn method is > completely brain-dead, blindly respawning without any thought for what > conditions might need to be checked, etc. That’s probably true. But still, I believe that much of the complexity of systemd (that it apparently has) comes from the fact that it’s most intended to provide a „smooth“ desktop experience. Now, it looks like almost everything is a „service“. Can I pick an example? [root at ipa ~]# systemctl list-unit-files |grep ssh sshd-keygen.service static sshd.service enabled sshd at .service static sshd.socket disabled What is the difference between sshd.service and sshd at .service? Am I right in assuming that the sshd-keygen.service is responsible for creating the initial host-keys? I may be wrong, but sshd works nice on my 100+ servers without a special service for this. In fact, I loathed the Solaris-behavior, where you had to „refresh“ the service for this (or something to this effect) On FreeBSD, if I want to create new keys, I delete the old ones and restart the service. I very rarely need that, so I just assume it’s the same on RHEL. Can anyone give an example from a stock RHEL7 install that could not have been done with a traditional SysV-init?