Linux: concerns over systemd [OT]

Barry Shein bzs at world.std.com
Wed Oct 22 18:31:02 UTC 2014


On October 21, 2014 at 16:43 morrowc.lists at gmail.com (Christopher Morrow) wrote:
 > On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan <asullivan at dyn.com> wrote:
 > > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote:
 > >> But
 > >> for example some of my servers boot in seconds.
 > >
 > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS
 > > Handbook_, available at
 > 
 > it's really not clear to me that 'reboots in seconds' is a thing to optimize...

The unix community has exerted great amounts of effort over the
decades to speed up reboot, particularly after crashes but also
planned. Perhaps you don't remember the days when an fsck was
basically mandatory and could take 15-20 minutes on a large disk.

Then we added the clean bit (disk unmounted cleanly, no need for
fsck), reorg'd the file system layout to speed up fsck considerably
and make it more reliable/recoverable, added journaled file systems
which really sped things up often eliminating the need to fsck after a
crash entirely and recovering in seconds, various attempts to figure
out the dependency graph of servers and services which need to be
started so they could be started in parallel where dependencies are
met, etc.

And learned how to do hot failover and master/slave servers etc.

And you whisk all that away with "it's not really clear to me that
'reboots in seconds' is a think to be optimized"????

To me that's like saying it's not important to try to design so one
can recover from a network outage in seconds.

Anyhow, if it's not clear: I disagree.

 > 
 > I suppose the win is:
 >   "Is the startup/shutdown process clear, conscise and understandable
 > at 3am local time?"
 > 
 > followed by:
 >   "Can I adjust my startup processes to meet my needs easily and
 > without finding a phd in unix?"
 > 
 > If systemd is simply a change in how I think about /etc/init.d/* and
 > /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility
 > then it's a fail.

Actually, much of that is less important except perhaps to a hobbyist.

You only have to get the startup/shutdown process etc right once in a
while and generally during a planned outage.

Recovering from a failure or going back into service quickly after a
planned outage is critical and can be critical at any time.

Obviously one can appeal to extremum but what you say doesn't make
sense to me. At any rate, you are disputing a huge, decades long, and
widely fought battle. It's certainly not my opinion.


-- 
        -Barry Shein

The World              | bzs at TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*



More information about the NANOG mailing list