Am 12.07.2014 um 17:08 schrieb Lamar Owen <lowen@xxxxxxxx>:
> [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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
