Les Mikesell <lesmikesell@...> writes:
>
> On Thu, Jul 10, 2014 at 8:39 AM, David G. Miller <dave@...> wrote:
> >
> >> Generally speaking, if a service is broken to the point that it needs
> >> something to automatically restart it I'd rather have it die
> >> gracefully and not do surprising things until someone fixes it. But
> >> then again, doesn't mysqld manage to accomplish that in a
> >> fully-compatible manner on Centos6?
> >>
> > Can't find the original post so replying and agreeing with Les. Have the
> > same ongoing problem with radvd. When My IPv6 tunnel provider burps, the
> > tunnel drops. The tunnel daemon usually reconnects but radvd stays down.
> > Solution:
> >
> > */12 * * * * /sbin/service radvd status > /dev/null 2>&1 || /sbin/service
> > radvd start 2>&1
> >
> > in crontab. How hard is that? And without all of the systemd nonsense.
>
> Or, if you want things to respawn, the original init handled that very
> nicely via inittab. Also,running a shell as the parent of your
> daemon as a watchdog that can repair its environment and restart it if
> it exits doesn't have much overhead. Programs share the loaded
> executable code across all instances and you pretty much always have
> some shells running on a linux/unix box - a few more won't matter.
>
Just pointing out one of several approaches to respawning a daemon without
the overhead of systemd. I went with this approach since the problem is not
with radvd or its init script but with my IPv6 tunnel provider. I wanted
something that didn't require modifying any of the installed bits. This
approach also means that updates to radvd and friends don't overwrite my
modifications. 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.
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.
Cheers,
Dave
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
