[patch] halt/reboot/shutdown cleanup

[Jilles Tjoelker]

On Mon, May 14, 2012 at 08:52:44AM -0600, Warner Losh wrote:

> On May 14, 2012, at 8:36 AM, Warner Losh wrote:

> > On May 14, 2012, at 3:25 AM, Doug Barton wrote:

> >> This topic comes up very often as users are confused by the fact that we
> >> have 2 different methods for shutdown/reboot, and the ones that seem the
> >> most obvious (halt and reboot) are the most pathological.

> >> IMO we should maintain the old behavior as binaries with scary names
> >> that the anachronists can use in local aliases, and we should modify
> >> halt and reboot in a manner similar to what Jilles is suggesting.

> > See my other post for a way forward, sans bogusly scary names.

The names fastboot and fasthalt could be used for the traditional
behaviour.

> This may also be a cultural divide between the embedded world, where
> halt means halt right now and reboot where reboot means reboot right
> now and the server world where users need to be told of things and a
> more generic infrastructure needs to be in place.  In embedded, when
> you decide to reboot, you know everybody else has cleaned up and you
> want to give the best experience to the user by doing it as fast as
> possible.  In the server space, people that are logged in need to be
> told, there's a richer framework that needs to run, etc and time to
> get back to passing WiFi packets isn't as important.

In that embedded case, you may want 'reboot -q', which will remain
unchanged. This calls reboot(2) directly so it syncs the disks but does
not attempt to terminate any processes cleanly.

I have found 4 seconds of useless sleeps in the 'shutdown -r now'
process: 2 seconds in shutdown and 2 seconds in init. I have used an
init without the delay for quite a while without problems and the delay
in shutdown seems useless (between saying the shutdown is "now" and
actually signaling init to do it).

With those delays removed (patch below), shutting down via shutdown or
init may be even faster than via reboot. This is because reboot always
waits at least 5 seconds between sending SIGTERM and SIGKILL, while init
stops waiting immediately if the last process terminates. Reboot may be
faster if something is hung or if rc.shutdown exists and is very slow,
which may be the case on embedded platforms.

Soft updates syncing at shutdown is also very slow, but that is a kernel
issue.

> The distaste for extra, useless messages, I'll admit, is a personality
> quirk that I share with many people.

I don't feel strongly about the messages.

Index: sbin/init/init.c
===================================================================
--- sbin/init/init.c	(revision 235360)
+++ sbin/init/init.c	(working copy)
@@ -646,8 +646,6 @@
 	if (Reboot) {
 		/* Instead of going single user, let's reboot the machine */
 		sync();
-		alarm(2);
-		pause();
 		reboot(howto);
 		_exit(0);
 	}
Index: sbin/shutdown/shutdown.c
===================================================================
--- sbin/shutdown/shutdown.c	(revision 235360)
+++ sbin/shutdown/shutdown.c	(working copy)
@@ -356,7 +356,6 @@
 	syslog(LOG_NOTICE, "%s by %s: %s",
 	    doreboot ? "reboot" : dohalt ? "halt" : dopower ? "power-down" : 
 	    "shutdown", whom, mbuf);
-	(void)sleep(2);
 
 	(void)printf("\r\nSystem shutdown time has arrived\007\007\r\n");
 	if (killflg) {

-- 
Jilles Tjoelker