Etcd and fleet

Posted Oct 25, 2014 19:14 UTC (Sat) by dlang (guest, #313)
In reply to: Etcd and fleet by kleptog
Parent article: Etcd and fleet

why would something like fleet be impossible with sysvinit?

Etcd and fleet

Posted Oct 25, 2014 20:55 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

Because to be able to have a stable system and to do things like failover you have to be able to answer the question "is this service still running?" and be able to receive a notification when a service dies. Sysvinit doesn't do that, it just starts services and forgets about them.

Things like daemontools are a step up, since it can at least tell when something dies, but it doesn't have the same kind of control.

Since unit files can also do things like job scheduling, you'd have to write something to distribute cron jobs as well.

You could probably attempt it with sysinit, but you'd get completely lost in the half-baked status scripts, inconsistent logging and other annoyances.

Etcd and fleet

Posted Oct 25, 2014 21:01 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

"Is this service still running" is a rather complex question to answer, and it's far from clear that what an init system can do is sufficient.

There are lots of times when the process has not exited that the service is not healthy enough to function and failover is needed.

Sysvinit does support restarting processes if they exit, that's what inittab did. It did the job well and wasn't hard to manage (I had a server at one time with several hundred entries in inittab

Etcd and fleet

Posted Oct 25, 2014 23:42 UTC (Sat) by anselm (subscriber, #2796) [Link]

In sysvinit, when you run your services from inittab, you give up the convenience of being able to start and stop them manually using “/etc/init.d/SCRIPT start” (or whatever). You also give up the ability to start them in a defined order so as to obey dependencies on other services. When you run your services by means of init scripts, you give up automatic restarts (and must add them again by means of piling on more hacks). This is an arbitrary and inconvenient dichotomy.

Systemd handles all services identically, whether they're automatically restarted or not. Dependencies and manual start/stop are available for all services. Exactly under what conditions a service is restarted, as well as rate-limiting for restarts, can be extensively configured. Systemd also supports “watchdog” functionality that can restart a service if the process appears to be running but hasn't shown signs of life for a specific time. In this respect systemd is in fact considerably superior to sysvinit.

Claiming that ”sysvinit does support restarting processes if they exit” is technically correct (under certain limited circumstances, anyway). Claiming that sysvinit does it as well as systemd, however, is ludicrous.

Etcd and fleet

Posted Oct 28, 2014 5:17 UTC (Tue) by raven667 (subscriber, #5198) [Link]

On sysvinit a tool like fleet would have to do all of its own service management, it would have to a parent of all the processes, manage cgroups, etc., in effect it would have to be systemd itself.