[CentOS] Cemtos 7 : Systemd alternatives ?
Lamar Owen
lowen at pari.edu
Sat Jul 12 15:08:44 UTC 2014
[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.
> Just pointing out one of several approaches to respawning a daemon without
> the overhead of systemd.
Replying to David: So you'd prefer the overhead of cron plus shells plus
a bit of arcane syntax? When I first replied to this crontab line, I
honestly thought you were being tongue-in-cheek.
I have a similar sort of kluge in place, on a CentOS 6 system at a
client, that uses the autossh package to hold open ssh reverse tunnels;
reverse tunnels are great when the client's machine is behind a
known-to-change-frequently dynamic address.
> I went with this approach since the problem is not
> with radvd or its init script but with my IPv6 tunnel provider.
Sounds like something that systemd's concept of process dependencies
could solve for you with an easier (and non-executable) syntax. Systemd
provides an 'OnFailure' directive that allows you to do whatever you'd
like upon failure of an particular 'unit.' That sort of mechanism might
allow you to implement the process equivalent of Cisco IOS' IP SLA's.
(You could mount /etc (and /var) noexec and have /usr and friends
mounted read-only, even.)
> I wanted
> something that didn't require modifying any of the installed bits.
This is why sysadmin configs for systemd are in /etc and the OS-supplied
configs are in /usr. Your /etc 'units' to systemd will override the OS
installed ones, and are all collected together in one well-defined and
standard place.
> This
> approach also means that updates to radvd and friends don't overwrite my
> modifications.
This is why sysadmin configs for systemd are in /etc and the OS-supplied
configs are in /usr. Your /etc 'units' for systemd will not be touched
by the updates to the OS-supplied ones.
> Just "playing with" the IPv6 stuff so having it down for up
> to five minutes also isn't a problem. The source of the problem goes away
> when my ISP provides IPv6 and I don't need to tunnel IPv6 in IPv4 anymore.
If you can figure out IPv6 then systemd should be no sweat.
> I look at systemd as being yet another nuclear fly swatter. Overkill for
> simple problems that can and should be be addressed at the problem without a
> sweeping, system level change.
I have done all of the various init styles at various times, so I make
this statement having 27 years of experience dealing with Unix-like
systems (I won't bore anyone with the list): in my quick perusal of
systemd and its documentation, I'm cautiously optimistic that maybe
finally we have something that a sysadmin can really make sing. Time
will tell, of course, whether systemd actually addresses the core
problems or not; we've already had one round of an init replacement,
Upstart, that didn't succeed in fully addressing the core problems (but
will be with us until 2020 as part of EL6). And I always reserve the
right to be wrong.
But traditional SystemV init last appears in EL5, which, while it is
still supported until 2017, is two major versions old at this point. And
in case you missed the announcement from Red Hat, EL5.11 is the last
minor version update of EL5, with subsequent updates being released as
they come and not batched into point releases. (I now know my last
targeted version for IA64 rebuilding, which is good.....as long as I can
put in some automation to grab updates from then on).
More information about the CentOS
mailing list