Am 12.07.2014 um 17:08 schrieb Lamar Owen lowen@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@...> 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@ipa ~]# systemctl list-unit-files |grep ssh sshd-keygen.service static sshd.service enabled sshd@.service static sshd.socket disabled
What is the difference between sshd.service and sshd@.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?