[ale] [systemd] Boot speed

James Taylor James.Taylor at eastcobbgroup.com
Mon Feb 19 11:08:14 EST 2018


 I don't entirely disagree with that observation, but there are still,
and will be a lot of major systems that don't lend themselves well to
that model.
For example, the SAP HANA systems use multiterabyte in memory databases
that don't get rebooted because it can take hours, maybe days to write
back and reload the databases from disk.
That was one of the drivers for live kernel patching that is now
available.
I agree that large containerized server farms (plantations?) are the
norm for consumer cloud space, but I don't think non-ephemeral systems
are going away any time soon.

None of which is relevant to the systemd argument, in any case.
-jt

 

James Taylor
678-697-9420
james.taylor at eastcobbgroup.com



>>> Jerald Sheets via Ale <ale at ale.org> 2/19/2018 10:19 AM >>> 
So let me interject into this conversational process a “norm”
that’s evolving out in silicon valley.

We don’t reboot.  When a machine is sufficiently “Sick” that
something as “profound” as a reboot is expected to be needed, the
instance is terminated and a new node stands up in its place.  There’s
no such thing as persistent nodes any more in large scale work.  YES,
there’s a lot of architecture around that, and YES there’s a lot of
clustering and session maintenance voodoo around that on the application
side.  However, not having to keep up with instances any more and/or
terminate/replace instead of reboot is every bit as fast as some of
these boot times we’re discussing here.

It is my opinion (and prediction) that this will be something of a
non-issue over the next several years.

I cannot tell you the number of systems that are either running in a
containerized fashion with CoreOS, stripped down operating systems you
create yourself with not much more than a boot loader and a single boot
environment on the OS to run a single app with a single set of boot
scripts for that single app or even micro containers over docker that
run nothing but OS libraries and language dependencies required to run
the app itself…nothing more…(i.e., no SystemD OR SysV Init at all)

Our long-standing way of doing things is on the move again, folks. 
This particular conversation would now be classified as a “legacy”
conversation.  Look to container and lambda-style infrastructure to
start taking big chunks of workload “out there”.

While you may be skeptical because of your current environment you care
for and feed, one day you may have to leave it and go somewhere else,
and what you find at your new role may look nothing like what you’re
dealing with today.

My last 3 years (23rd, 24th, and 25th year in the business)has been
more education than I encountered the first 3 years of my career.

—j


> On Feb 18, 2018, at 9:57 PM, Solomon Peachy via Ale <ale at ale.org>
wrote:
> 
> On Sun, Feb 18, 2018 at 03:41:23PM -0500, Steve Litt via Ale wrote:
>> It also isn't all that necessary. Most run scripts, as they come
from
>> the factory (at least with Void Linux) have no process dependency
>> checking, and in practice things seem to work just fine. But if one
>> wants process dependency checking, it simply requires a simple "if"
>> statement within the dependent process' run script.
> 
> So... if the parent restarts, who is going to restart the
dependents?
> 
>> Runit can do that. I'm not sure it's a good idea: I'd rather ip
link
>> set dev eth0 down;ip link set dev eth0 up, and same with wlo1. With
>> such a change, I'd rather fix it up manually. For situations where
the
>> network goes down and back up again, all I can say is my computer
>> brings back its network connection without the need of having the
>> network be a service.
> 
> I'd rather _not_ fix things up manually, by the time I've finished
> everyhing it would have been faster (and less disruptive) to just
reboot
> the system.
> 
> Annoyingly there's a big gotcha that I missed -- Google apparently
> requires matching IPv6 RDNS entries.  I'd set up the HE tunnel
> so long ago I forgot that they automatically created those
> entries.  Meanwhile, 2 days in, and Comcast hasn't fulfiled my
ticket.
> 
> (DNS had already switched over by the time I'd discovered this, so I
> couldn't just revert back.  Joy...)
> 
>> Problem is, with systemd's welded together entanglement of large
>> sections of software with applications and the underlying OS,
systemd
>> completely changes the way you adjust your software, and IMHO not
for
>> the better if you're at all DIY.
> 
> You and I draw the "DIY" line at different places.
> 
> (I don't administer my own systems for the joy of it; they have
specific
> jobs to fulfil and I'm too much of a paranoid git to trust my data
on
> anyone else's systems..)
> 
>> You never saw this kind of thing with Vim vs Emacs: Neither tried
to
>> weld itself into irreplacibility. You don't see this thing with KDE
vs
>> Gnome: Neither was successful enough in welding itself into
>> irreplacibility.
> 
> Emacs's viper-mode is arguably a better vi than vim.  :P
> 
>> The last piece of software to generate this level of antipathy and
>> resistance was Windows.
> 
> ...Yet for all that antipathy and resistance, windows still easily
rules
> the [PC] world.
> 
> - Solomon
> --
> Solomon Peachy			       pizza at shaftnet dot
org
> Coconut Creek, FL                          ^^ (email/xmpp) ^^
> Quidquid latine dictum sit, altum videtur.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo




More information about the Ale mailing list