All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <lennart@poettering.net>
To: Simon Horman <horms@verge.net.au>
Cc: kexec list <kexec@lists.infradead.org>,
	Marti Raudsepp <marti@juffo.org>,
	systemd-devel <systemd-devel@lists.freedesktop.org>
Subject: Re: Doing kexec reboot right in systemd
Date: Mon, 26 Mar 2012 20:07:30 +0200	[thread overview]
Message-ID: <20120326180729.GB5398@tango.0pointer.de> (raw)
In-Reply-To: <20120322223646.GC26794@verge.net.au>

On Fri, 23.03.12 07:36, Simon Horman (horms@verge.net.au) wrote:

> 
> On Thu, Mar 22, 2012 at 09:14:56PM +0200, Marti Raudsepp wrote:
> > Hi list,
> 
> Hi Marti,
> 
> > I was recently pondering how systemd could use kexec "properly", in a
> > reasonably general way, to make reboots faster. I exchanged an email
> > with Poettering on the systemd list and he suggested me to ask here.
> > 
> > My current proposal:
> > 1. Include a template 'kexec-load.service' with kexec-tools, which
> > distros/users could customize to load the right kernel and initrd via
> > /sbin/kexec

Hmm, so since this would then belong in the shutdown path of systemd,
and only be added for the kexec shutdown path I actually think it would
make more sense to add this into systemd itself instead of kexec-tools,
to ensure the right ordering.

Marti, sorry for changing my mind on this: would be great if you could
prep a patch for this for systemd itself.

> > 3. During a reboot, after systemd has finished shutting down, it
> > detects via /sys/kernel/kexec_loaded whether the kexec kernel is
> > loaded. If 1, it performs a 'kexec -e'. If not, it does a normal
> > reboot.

I'd like to keep kexec.target different from reboot.target by
default, so that people have both options available.

So, how I'd envision this:

a) we introduce kexec-load.service which is always in the kexec.target
   shutdown path, never in reboot.target. Doesn't need to be enabled.

b) kexec-load.service becomes a NOP if a kernel is already loaded

c) "systemctl reboot" continues to check whether a kernel is already
   loaded, and if so results in kexec.target being started rather than
   reboot.target

d) If the user wants that the machine is always rebooted via kexec,
   never with traditional reboot, he can manually create a symlink
   /etc/systemd/system/reboot.target to
   /etc/systemd/system/kexec.target.

That way, that in general both paths always exist, unless the admin
manually loaded a kernel or manually redirected all reboots to kexec.

Does that make sense?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2012-03-26 18:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-22 19:14 Doing kexec reboot right in systemd Marti Raudsepp
2012-03-22 22:36 ` Simon Horman
2012-03-26 18:07   ` Lennart Poettering [this message]
2012-03-26 18:25     ` Marti Raudsepp
2012-03-27 10:01       ` Lennart Poettering
2012-03-27 23:19         ` Simon Horman
2012-03-23  9:35 ` Bouchard Louis
2012-03-23 18:45   ` Marti Raudsepp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120326180729.GB5398@tango.0pointer.de \
    --to=lennart@poettering.net \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=marti@juffo.org \
    --cc=systemd-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.