From owner-freebsd-arch@FreeBSD.ORG Sun May 13 22:06:48 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7EAA1065673 for ; Sun, 13 May 2012 22:06:48 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 220338FC15 for ; Sun, 13 May 2012 22:06:48 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 1C6313592FB for ; Mon, 14 May 2012 00:06:47 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E66CE2847A; Mon, 14 May 2012 00:06:46 +0200 (CEST) Date: Mon, 14 May 2012 00:06:46 +0200 From: Jilles Tjoelker To: freebsd-arch@freebsd.org Message-ID: <20120513220646.GA12826@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 22:06:48 -0000 There is duplication of code between sbin/reboot and init: both can cleanly shut down the system, for some value of "cleanly". Because the code in init is activated by the kernel (sending a signal to init), it makes sense to keep that and remove the duplicate from sbin/reboot. This also ensures that /etc/rc.shutdown is executed in all "clean" shutdowns. Before 9.0, init could not shut down the system 100% correctly during single user mode (for example, it inappropriately ran /etc/rc.shutdown), but this has been fixed. Also, the normal forms of halt and reboot will now call shutdown so users get a clear message of the event. Halt and reboot still support the -q option to invoke reboot(2) without anything else. The -d and -n options now require -q (because init is signaled if -q is not used, and init will not do dump or nosync). The -l option of halt and reboot now not only suppresses logging, but also user notification. It does this by signaling init directly and not going through shutdown. The -o option of shutdown goes away because there does not seem any point in executing halt or reboot if they are going to send the same signal to init anyway. diff --git a/include/paths.h b/include/paths.h index 6503934..f93cf39 100644 --- a/include/paths.h +++ b/include/paths.h @@ -84,6 +84,7 @@ #define _PATH_RSH "/usr/bin/rsh" #define _PATH_SENDMAIL "/usr/sbin/sendmail" #define _PATH_SHELLS "/etc/shells" +#define _PATH_SHUTDOWN "/sbin/shutdown" #define _PATH_TTY "/dev/tty" #define _PATH_UNIX "don't use _PATH_UNIX" #define _PATH_VI "/usr/bin/vi" diff --git a/sbin/reboot/reboot.8 b/sbin/reboot/reboot.8 index 13d7098..50c27ee 100644 --- a/sbin/reboot/reboot.8 +++ b/sbin/reboot/reboot.8 @@ -55,12 +55,11 @@ The .Nm halt and .Nm -utilities flush the file system cache to disk, send all running processes -a -.Dv SIGTERM -(and subsequently a -.Dv SIGKILL ) -and, respectively, halt or restart the system. +utilities invoke +.Xr shutdown 8 +or signal +.Xr init 8 +to, respectively, halt or restart the system. The action is logged, including entering a shutdown record into the user accounting database. .Pp @@ -69,7 +68,9 @@ The options are as follows: .It Fl d The system is requested to create a crash dump. This option is -supported only when rebooting, and it has no effect unless a dump +supported only when rebooting together with the +.Fl q +option, and it has no effect unless a dump device has previously been specified with .Xr dumpon 8 . .It Fl k Ar kernel @@ -86,25 +87,14 @@ This may change in the future. .It Fl l The halt or reboot is .Em not -logged to the system log. -This option is intended for applications such as -.Xr shutdown 8 , -that call -.Nm -or -.Nm halt -and log this themselves. +logged to the system log and not announced to users. .It Fl n The file system cache is not flushed. -This option should probably not be used. +This option should probably not be used and only works together with the +.Fl q +option. .It Fl p The system will turn off the power if it can. -If the power down action fails, the system -will halt or reboot normally, depending on whether -.Nm halt -or -.Nm -was called. .It Fl q The system is halted or restarted quickly and ungracefully, and only the flushing of the file system cache is performed (if the @@ -122,12 +112,6 @@ utilities are nothing more than aliases for the and .Nm utilities. -.Pp -Normally, the -.Xr shutdown 8 -utility is used when the system needs to be halted or restarted, giving -users advance warning of their impending doom and cleanly terminating -specific programs. .Sh SEE ALSO .Xr getutxent 3 , .Xr boot 8 , diff --git a/sbin/reboot/reboot.c b/sbin/reboot/reboot.c index d927db0..285437a 100644 --- a/sbin/reboot/reboot.c +++ b/sbin/reboot/reboot.c @@ -44,31 +44,27 @@ __FBSDID("$FreeBSD$"); #include #include #include -#include #include #include #include #include +#include #include #include #include #include #include #include -#include static void usage(void); -static u_int get_pageins(void); static int dohalt; int main(int argc, char *argv[]) { - struct utmpx utx; const struct passwd *pw; - int ch, howto, i, fd, lflag, nflag, qflag, sverrno; - u_int pageins; + int ch, howto, fd, lflag, qflag; const char *user, *kernel = NULL; if (strcmp(getprogname(), "halt") == 0) { @@ -76,7 +72,7 @@ main(int argc, char *argv[]) howto = RB_HALT; } else howto = 0; - lflag = nflag = qflag = 0; + lflag = qflag = 0; while ((ch = getopt(argc, argv, "dk:lnpq")) != -1) switch(ch) { case 'd': @@ -89,7 +85,6 @@ main(int argc, char *argv[]) lflag = 1; break; case 'n': - nflag = 1; howto |= RB_NOSYNC; break; case 'p': @@ -107,6 +102,10 @@ main(int argc, char *argv[]) if ((howto & (RB_DUMP | RB_HALT)) == (RB_DUMP | RB_HALT)) errx(1, "cannot dump (-d) when halting; must reboot instead"); + if (!qflag && (howto & RB_DUMP) != 0) + errx(1, "cannot dump (-d) without immediate reboot(2) (-q)"); + if (!qflag && (howto & RB_NOSYNC) != 0) + errx(1, "cannot disable sync (-n) without immediate reboot(2) (-q)"); if (geteuid()) { errno = EPERM; err(1, NULL); @@ -129,6 +128,16 @@ main(int argc, char *argv[]) } } +#ifndef RESCUE + if (!lflag) { + execl(_PATH_SHUTDOWN, _PATH_SHUTDOWN, + (howto & RB_POWEROFF) != 0 ? "-p" : + (howto & RB_HALT) != 0 ? "-h" : + "-r", "now", (char *)NULL); + warn("cannot execute %s; signaling init(8)", _PATH_SHUTDOWN); + } +#endif + /* Log the reboot. */ if (!lflag) { if ((user = getlogin()) == NULL) @@ -142,80 +151,12 @@ main(int argc, char *argv[]) syslog(LOG_CRIT, "rebooted by %s", user); } } - utx.ut_type = SHUTDOWN_TIME; - gettimeofday(&utx.ut_tv, NULL); - pututxline(&utx); - - /* - * Do a sync early on, so disks start transfers while we're off - * killing processes. Don't worry about writes done before the - * processes die, the reboot system call syncs the disks. - */ - if (!nflag) - sync(); - - /* - * Ignore signals that we can get as a result of killing - * parents, group leaders, etc. - */ - (void)signal(SIGHUP, SIG_IGN); - (void)signal(SIGINT, SIG_IGN); - (void)signal(SIGQUIT, SIG_IGN); - (void)signal(SIGTERM, SIG_IGN); - (void)signal(SIGTSTP, SIG_IGN); - - /* - * If we're running in a pipeline, we don't want to die - * after killing whatever we're writing to. - */ - (void)signal(SIGPIPE, SIG_IGN); - - /* Just stop init -- if we fail, we'll restart it. */ - if (kill(1, SIGTSTP) == -1) - err(1, "SIGTSTP init"); - - /* Send a SIGTERM first, a chance to save the buffers. */ - if (kill(-1, SIGTERM) == -1 && errno != ESRCH) - err(1, "SIGTERM processes"); - - /* - * After the processes receive the signal, start the rest of the - * buffers on their way. Wait 5 seconds between the SIGTERM and - * the SIGKILL to give everybody a chance. If there is a lot of - * paging activity then wait longer, up to a maximum of approx - * 60 seconds. - */ - sleep(2); - for (i = 0; i < 20; i++) { - pageins = get_pageins(); - if (!nflag) - sync(); - sleep(3); - if (get_pageins() == pageins) - break; - } - - for (i = 1;; ++i) { - if (kill(-1, SIGKILL) == -1) { - if (errno == ESRCH) - break; - goto restart; - } - if (i > 5) { - (void)fprintf(stderr, - "WARNING: some process(es) wouldn't die\n"); - break; - } - (void)sleep(2 * i); - } - - reboot(howto); - /* FALLTHROUGH */ -restart: - sverrno = errno; - errx(1, "%s%s", kill(1, SIGHUP) == -1 ? "(can't restart init): " : "", - strerror(sverrno)); + if (kill(1, (howto & RB_POWEROFF) != 0 ? SIGUSR2 : + (howto & RB_HALT) != 0 ? SIGUSR1 : + SIGINT) == -1) + err(1, "signal init"); + pause(); /* NOTREACHED */ } @@ -228,18 +169,3 @@ usage(void) "usage: reboot [-dlnpq] [-k kernel]\n"); exit(1); } - -static u_int -get_pageins(void) -{ - u_int pageins; - size_t len; - - len = sizeof(pageins); - if (sysctlbyname("vm.stats.vm.v_swappgsin", &pageins, &len, NULL, 0) - != 0) { - warnx("v_swappgsin"); - return (0); - } - return pageins; -} diff --git a/sbin/shutdown/shutdown.8 b/sbin/shutdown/shutdown.8 index b7067e1..37152ac 100644 --- a/sbin/shutdown/shutdown.8 +++ b/sbin/shutdown/shutdown.8 @@ -42,10 +42,6 @@ .Fl h | Fl p | .Fl r | Fl k .Oc -.Oo -.Fl o -.Op Fl n -.Oc .Ar time .Op Ar warning-message ... .Nm poweroff @@ -77,30 +73,6 @@ The option does not actually halt the system, but leaves the system multi-user with logins disabled (for all but super-user). -.It Fl o -If one of the -.Fl h , -.Fl p -or -.Fl r -options are specified, -.Nm -will execute -.Xr halt 8 -or -.Xr reboot 8 -instead of sending a signal to -.Xr init 8 . -.It Fl n -If the -.Fl o -option is specified, prevent the file system cache from being flushed by passing -.Fl n -to -.Xr halt 8 -or -.Xr reboot 8 . -This option should probably not be used. .It Ar time .Ar Time is the time at which diff --git a/sbin/shutdown/shutdown.c b/sbin/shutdown/shutdown.c index 6e662a8..945bef2 100644 --- a/sbin/shutdown/shutdown.c +++ b/sbin/shutdown/shutdown.c @@ -88,9 +88,9 @@ static struct interval { #undef S static time_t offset, shuttime; -static int dohalt, dopower, doreboot, killflg, mbuflen, oflag; +static int dohalt, dopower, doreboot, killflg, mbuflen; static char mbuf[BUFSIZ]; -static const char *nosync, *whom; +static const char *whom; static void badtime(void); static void perform_shutdown(void); @@ -116,7 +116,6 @@ main(int argc, char **argv) errx(1, "NOT super-user"); #endif - nosync = NULL; readstdin = 0; /* @@ -152,10 +151,8 @@ main(int argc, char **argv) killflg = 1; break; case 'n': - nosync = "-n"; - break; case 'o': - oflag = 1; + /* Ignore -n and -o for compatibility. */ break; case 'p': dopower = 1; @@ -176,12 +173,6 @@ main(int argc, char **argv) if (killflg + doreboot + dohalt + dopower > 1) usage("incompatible switches -h, -k, -p and -r"); - if (oflag && !(dohalt || dopower || doreboot)) - usage("-o requires -h, -p or -r"); - - if (nosync != NULL && !oflag) - usage("-n requires -o"); - getoffset(*argv++); poweroff: @@ -351,8 +342,6 @@ timeout(int signo __unused) static void perform_shutdown(void) { - char *empty_environ[] = { NULL }; - syslog(LOG_NOTICE, "%s by %s: %s", doreboot ? "reboot" : dohalt ? "halt" : dopower ? "power-down" : "shutdown", whom, mbuf); @@ -370,39 +359,12 @@ perform_shutdown(void) (void)printf("halt"); else if (dopower) (void)printf("power-down"); - if (nosync != NULL) - (void)printf(" no sync"); (void)printf("\nkill -HUP 1\n"); #else - if (!oflag) { - (void)kill(1, doreboot ? SIGINT : /* reboot */ - dohalt ? SIGUSR1 : /* halt */ - dopower ? SIGUSR2 : /* power-down */ - SIGTERM); /* single-user */ - } else { - if (doreboot) { - execle(_PATH_REBOOT, "reboot", "-l", nosync, - (char *)NULL, empty_environ); - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", - _PATH_REBOOT); - warn(_PATH_REBOOT); - } - else if (dohalt) { - execle(_PATH_HALT, "halt", "-l", nosync, - (char *)NULL, empty_environ); - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", - _PATH_HALT); - warn(_PATH_HALT); - } - else if (dopower) { - execle(_PATH_HALT, "halt", "-l", "-p", nosync, - (char *)NULL, empty_environ); - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", - _PATH_HALT); - warn(_PATH_HALT); - } - (void)kill(1, SIGTERM); /* to single-user */ - } + (void)kill(1, doreboot ? SIGINT : /* reboot */ + dohalt ? SIGUSR1 : /* halt */ + dopower ? SIGUSR2 : /* power-down */ + SIGTERM); /* single-user */ #endif finish(0); } @@ -534,7 +496,7 @@ usage(const char *cp) if (cp != NULL) warnx("%s", cp); (void)fprintf(stderr, - "usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time [warning-message ...]\n" + "usage: shutdown [-] [-h | -p | -r | -k] time [warning-message ...]\n" " poweroff\n"); exit(1); } -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun May 13 22:43:05 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD158106566C for ; Sun, 13 May 2012 22:43:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 279AC8FC08 for ; Sun, 13 May 2012 22:43:05 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4DMg8MC036261 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 16:42:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120513220646.GA12826@stack.nl> Date: Sun, 13 May 2012 16:42:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120513220646.GA12826@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 13 May 2012 16:42:08 -0600 (MDT) Cc: freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 22:43:05 -0000 On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: > Also, the normal forms of halt and reboot will now call shutdown so > users get a clear message of the event. I hate these messages, which is why I always use halt or reboot to avoid = them. I find the additional delays from doing a shutdown -r to also be = annoying, which is why I never use them. > Halt and reboot still support the -q option to invoke reboot(2) = without > anything else. The -d and -n options now require -q (because init is > signaled if -q is not used, and init will not do dump or nosync). >=20 > The -l option of halt and reboot now not only suppresses logging, but > also user notification. It does this by signaling init directly and = not > going through shutdown. >=20 > The -o option of shutdown goes away because there does not seem any > point in executing halt or reboot if they are going to send the same > signal to init anyway. Generally, I think this is a really bad idea, just like the last time it = was proposed. Warner > diff --git a/include/paths.h b/include/paths.h > index 6503934..f93cf39 100644 > --- a/include/paths.h > +++ b/include/paths.h > @@ -84,6 +84,7 @@ > #define _PATH_RSH "/usr/bin/rsh" > #define _PATH_SENDMAIL "/usr/sbin/sendmail" > #define _PATH_SHELLS "/etc/shells" > +#define _PATH_SHUTDOWN "/sbin/shutdown" > #define _PATH_TTY "/dev/tty" > #define _PATH_UNIX "don't use _PATH_UNIX" > #define _PATH_VI "/usr/bin/vi" > diff --git a/sbin/reboot/reboot.8 b/sbin/reboot/reboot.8 > index 13d7098..50c27ee 100644 > --- a/sbin/reboot/reboot.8 > +++ b/sbin/reboot/reboot.8 > @@ -55,12 +55,11 @@ The > .Nm halt > and > .Nm > -utilities flush the file system cache to disk, send all running = processes > -a > -.Dv SIGTERM > -(and subsequently a > -.Dv SIGKILL ) > -and, respectively, halt or restart the system. > +utilities invoke > +.Xr shutdown 8 > +or signal > +.Xr init 8 > +to, respectively, halt or restart the system. > The action is logged, including entering a shutdown record into the = user > accounting database. > .Pp > @@ -69,7 +68,9 @@ The options are as follows: > .It Fl d > The system is requested to create a crash dump. > This option is > -supported only when rebooting, and it has no effect unless a dump > +supported only when rebooting together with the > +.Fl q > +option, and it has no effect unless a dump > device has previously been specified with > .Xr dumpon 8 . > .It Fl k Ar kernel > @@ -86,25 +87,14 @@ This may change in the future. > .It Fl l > The halt or reboot is > .Em not > -logged to the system log. > -This option is intended for applications such as > -.Xr shutdown 8 , > -that call > -.Nm > -or > -.Nm halt > -and log this themselves. > +logged to the system log and not announced to users. > .It Fl n > The file system cache is not flushed. > -This option should probably not be used. > +This option should probably not be used and only works together with = the > +.Fl q > +option. > .It Fl p > The system will turn off the power if it can. > -If the power down action fails, the system > -will halt or reboot normally, depending on whether > -.Nm halt > -or > -.Nm > -was called. > .It Fl q > The system is halted or restarted quickly and ungracefully, and only > the flushing of the file system cache is performed (if the > @@ -122,12 +112,6 @@ utilities are nothing more than aliases for the > and > .Nm > utilities. > -.Pp > -Normally, the > -.Xr shutdown 8 > -utility is used when the system needs to be halted or restarted, = giving > -users advance warning of their impending doom and cleanly terminating > -specific programs. > .Sh SEE ALSO > .Xr getutxent 3 , > .Xr boot 8 , > diff --git a/sbin/reboot/reboot.c b/sbin/reboot/reboot.c > index d927db0..285437a 100644 > --- a/sbin/reboot/reboot.c > +++ b/sbin/reboot/reboot.c > @@ -44,31 +44,27 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > -#include > #include > #include > #include > #include > +#include > #include > #include > #include > #include > #include > #include > -#include >=20 > static void usage(void); > -static u_int get_pageins(void); >=20 > static int dohalt; >=20 > int > main(int argc, char *argv[]) > { > - struct utmpx utx; > const struct passwd *pw; > - int ch, howto, i, fd, lflag, nflag, qflag, sverrno; > - u_int pageins; > + int ch, howto, fd, lflag, qflag; > const char *user, *kernel =3D NULL; >=20 > if (strcmp(getprogname(), "halt") =3D=3D 0) { > @@ -76,7 +72,7 @@ main(int argc, char *argv[]) > howto =3D RB_HALT; > } else > howto =3D 0; > - lflag =3D nflag =3D qflag =3D 0; > + lflag =3D qflag =3D 0; > while ((ch =3D getopt(argc, argv, "dk:lnpq")) !=3D -1) > switch(ch) { > case 'd': > @@ -89,7 +85,6 @@ main(int argc, char *argv[]) > lflag =3D 1; > break; > case 'n': > - nflag =3D 1; > howto |=3D RB_NOSYNC; > break; > case 'p': > @@ -107,6 +102,10 @@ main(int argc, char *argv[]) >=20 > if ((howto & (RB_DUMP | RB_HALT)) =3D=3D (RB_DUMP | RB_HALT)) > errx(1, "cannot dump (-d) when halting; must reboot = instead"); > + if (!qflag && (howto & RB_DUMP) !=3D 0) > + errx(1, "cannot dump (-d) without immediate reboot(2) = (-q)"); > + if (!qflag && (howto & RB_NOSYNC) !=3D 0) > + errx(1, "cannot disable sync (-n) without immediate = reboot(2) (-q)"); > if (geteuid()) { > errno =3D EPERM; > err(1, NULL); > @@ -129,6 +128,16 @@ main(int argc, char *argv[]) > } > } >=20 > +#ifndef RESCUE > + if (!lflag) { > + execl(_PATH_SHUTDOWN, _PATH_SHUTDOWN, > + (howto & RB_POWEROFF) !=3D 0 ? "-p" : > + (howto & RB_HALT) !=3D 0 ? "-h" : > + "-r", "now", (char *)NULL); > + warn("cannot execute %s; signaling init(8)", = _PATH_SHUTDOWN); > + } > +#endif > + > /* Log the reboot. */ > if (!lflag) { > if ((user =3D getlogin()) =3D=3D NULL) > @@ -142,80 +151,12 @@ main(int argc, char *argv[]) > syslog(LOG_CRIT, "rebooted by %s", user); > } > } > - utx.ut_type =3D SHUTDOWN_TIME; > - gettimeofday(&utx.ut_tv, NULL); > - pututxline(&utx); > - > - /* > - * Do a sync early on, so disks start transfers while we're off > - * killing processes. Don't worry about writes done before the > - * processes die, the reboot system call syncs the disks. > - */ > - if (!nflag) > - sync(); > - > - /* > - * Ignore signals that we can get as a result of killing > - * parents, group leaders, etc. > - */ > - (void)signal(SIGHUP, SIG_IGN); > - (void)signal(SIGINT, SIG_IGN); > - (void)signal(SIGQUIT, SIG_IGN); > - (void)signal(SIGTERM, SIG_IGN); > - (void)signal(SIGTSTP, SIG_IGN); > - > - /* > - * If we're running in a pipeline, we don't want to die > - * after killing whatever we're writing to. > - */ > - (void)signal(SIGPIPE, SIG_IGN); > - > - /* Just stop init -- if we fail, we'll restart it. */ > - if (kill(1, SIGTSTP) =3D=3D -1) > - err(1, "SIGTSTP init"); > - > - /* Send a SIGTERM first, a chance to save the buffers. */ > - if (kill(-1, SIGTERM) =3D=3D -1 && errno !=3D ESRCH) > - err(1, "SIGTERM processes"); > - > - /* > - * After the processes receive the signal, start the rest of the > - * buffers on their way. Wait 5 seconds between the SIGTERM and > - * the SIGKILL to give everybody a chance. If there is a lot of > - * paging activity then wait longer, up to a maximum of approx > - * 60 seconds. > - */ > - sleep(2); > - for (i =3D 0; i < 20; i++) { > - pageins =3D get_pageins(); > - if (!nflag) > - sync(); > - sleep(3); > - if (get_pageins() =3D=3D pageins) > - break; > - } > - > - for (i =3D 1;; ++i) { > - if (kill(-1, SIGKILL) =3D=3D -1) { > - if (errno =3D=3D ESRCH) > - break; > - goto restart; > - } > - if (i > 5) { > - (void)fprintf(stderr, > - "WARNING: some process(es) wouldn't die\n"); > - break; > - } > - (void)sleep(2 * i); > - } > - > - reboot(howto); > - /* FALLTHROUGH */ >=20 > -restart: > - sverrno =3D errno; > - errx(1, "%s%s", kill(1, SIGHUP) =3D=3D -1 ? "(can't restart = init): " : "", > - strerror(sverrno)); > + if (kill(1, (howto & RB_POWEROFF) !=3D 0 ? SIGUSR2 : > + (howto & RB_HALT) !=3D 0 ? SIGUSR1 : > + SIGINT) =3D=3D -1) > + err(1, "signal init"); > + pause(); > /* NOTREACHED */ > } >=20 > @@ -228,18 +169,3 @@ usage(void) > "usage: reboot [-dlnpq] [-k kernel]\n"); > exit(1); > } > - > -static u_int > -get_pageins(void) > -{ > - u_int pageins; > - size_t len; > - > - len =3D sizeof(pageins); > - if (sysctlbyname("vm.stats.vm.v_swappgsin", &pageins, &len, = NULL, 0) > - !=3D 0) { > - warnx("v_swappgsin"); > - return (0); > - } > - return pageins; > -} > diff --git a/sbin/shutdown/shutdown.8 b/sbin/shutdown/shutdown.8 > index b7067e1..37152ac 100644 > --- a/sbin/shutdown/shutdown.8 > +++ b/sbin/shutdown/shutdown.8 > @@ -42,10 +42,6 @@ > .Fl h | Fl p | > .Fl r | Fl k > .Oc > -.Oo > -.Fl o > -.Op Fl n > -.Oc > .Ar time > .Op Ar warning-message ... > .Nm poweroff > @@ -77,30 +73,6 @@ The > option > does not actually halt the system, but leaves the > system multi-user with logins disabled (for all but super-user). > -.It Fl o > -If one of the > -.Fl h , > -.Fl p > -or > -.Fl r > -options are specified, > -.Nm > -will execute > -.Xr halt 8 > -or > -.Xr reboot 8 > -instead of sending a signal to > -.Xr init 8 . > -.It Fl n > -If the > -.Fl o > -option is specified, prevent the file system cache from being flushed = by passing > -.Fl n > -to > -.Xr halt 8 > -or > -.Xr reboot 8 . > -This option should probably not be used. > .It Ar time > .Ar Time > is the time at which > diff --git a/sbin/shutdown/shutdown.c b/sbin/shutdown/shutdown.c > index 6e662a8..945bef2 100644 > --- a/sbin/shutdown/shutdown.c > +++ b/sbin/shutdown/shutdown.c > @@ -88,9 +88,9 @@ static struct interval { > #undef S >=20 > static time_t offset, shuttime; > -static int dohalt, dopower, doreboot, killflg, mbuflen, oflag; > +static int dohalt, dopower, doreboot, killflg, mbuflen; > static char mbuf[BUFSIZ]; > -static const char *nosync, *whom; > +static const char *whom; >=20 > static void badtime(void); > static void perform_shutdown(void); > @@ -116,7 +116,6 @@ main(int argc, char **argv) > errx(1, "NOT super-user"); > #endif >=20 > - nosync =3D NULL; > readstdin =3D 0; >=20 > /* > @@ -152,10 +151,8 @@ main(int argc, char **argv) > killflg =3D 1; > break; > case 'n': > - nosync =3D "-n"; > - break; > case 'o': > - oflag =3D 1; > + /* Ignore -n and -o for compatibility. */ > break; > case 'p': > dopower =3D 1; > @@ -176,12 +173,6 @@ main(int argc, char **argv) > if (killflg + doreboot + dohalt + dopower > 1) > usage("incompatible switches -h, -k, -p and -r"); >=20 > - if (oflag && !(dohalt || dopower || doreboot)) > - usage("-o requires -h, -p or -r"); > - > - if (nosync !=3D NULL && !oflag) > - usage("-n requires -o"); > - > getoffset(*argv++); >=20 > poweroff: > @@ -351,8 +342,6 @@ timeout(int signo __unused) > static void > perform_shutdown(void) > { > - char *empty_environ[] =3D { NULL }; > - > syslog(LOG_NOTICE, "%s by %s: %s", > doreboot ? "reboot" : dohalt ? "halt" : dopower ? = "power-down" :=20 > "shutdown", whom, mbuf); > @@ -370,39 +359,12 @@ perform_shutdown(void) > (void)printf("halt"); > else if (dopower) > (void)printf("power-down"); > - if (nosync !=3D NULL) > - (void)printf(" no sync"); > (void)printf("\nkill -HUP 1\n"); > #else > - if (!oflag) { > - (void)kill(1, doreboot ? SIGINT : /* reboot */ > - dohalt ? SIGUSR1 : /* halt */ > - dopower ? SIGUSR2 : /* power-down */ > - SIGTERM); /* single-user = */ > - } else { > - if (doreboot) { > - execle(_PATH_REBOOT, "reboot", "-l", nosync,=20 > - (char *)NULL, empty_environ); > - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", > - _PATH_REBOOT); > - warn(_PATH_REBOOT); > - } > - else if (dohalt) { > - execle(_PATH_HALT, "halt", "-l", nosync, > - (char *)NULL, empty_environ); > - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", > - _PATH_HALT); > - warn(_PATH_HALT); > - } > - else if (dopower) { > - execle(_PATH_HALT, "halt", "-l", "-p", nosync, > - (char *)NULL, empty_environ); > - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", > - _PATH_HALT); > - warn(_PATH_HALT); > - } > - (void)kill(1, SIGTERM); /* to single-user */ > - } > + (void)kill(1, doreboot ? SIGINT : /* reboot */ > + dohalt ? SIGUSR1 : /* halt */ > + dopower ? SIGUSR2 : /* power-down */ > + SIGTERM); /* single-user */ > #endif > finish(0); > } > @@ -534,7 +496,7 @@ usage(const char *cp) > if (cp !=3D NULL) > warnx("%s", cp); > (void)fprintf(stderr, > - "usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time = [warning-message ...]\n" > + "usage: shutdown [-] [-h | -p | -r | -k] time = [warning-message ...]\n" > " poweroff\n"); > exit(1); > } >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-arch@FreeBSD.ORG Mon May 14 01:24:41 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7D1A106564A for ; Mon, 14 May 2012 01:24:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5F57F8FC0A for ; Mon, 14 May 2012 01:24:41 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4E1MVbb036992 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 19:22:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120513220646.GA12826@stack.nl> Date: Sun, 13 May 2012 19:22:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <81FA7C45-89FF-475A-A19A-8F761D74483F@bsdimp.com> References: <20120513220646.GA12826@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 13 May 2012 19:22:31 -0600 (MDT) Cc: freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 01:24:42 -0000 After the short discussion on IRC, I don't think that there's consensus = this patch is a good idea at all. I don't recall that being the outcome = of the last round of discussions either. Maybe we need: #!/bin/sh case ${HALT_METHOD:-bsd} in *) /sbin/bsdhalt $* linux) /sbin/shutdown -h $* now esac and similar for reboot, since that would also solve the problem... Warner On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: > There is duplication of code between sbin/reboot and init: both can > cleanly shut down the system, for some value of "cleanly". Because the > code in init is activated by the kernel (sending a signal to init), it > makes sense to keep that and remove the duplicate from sbin/reboot. = This > also ensures that /etc/rc.shutdown is executed in all "clean" = shutdowns. >=20 > Before 9.0, init could not shut down the system 100% correctly during > single user mode (for example, it inappropriately ran = /etc/rc.shutdown), > but this has been fixed. >=20 > Also, the normal forms of halt and reboot will now call shutdown so > users get a clear message of the event. >=20 > Halt and reboot still support the -q option to invoke reboot(2) = without > anything else. The -d and -n options now require -q (because init is > signaled if -q is not used, and init will not do dump or nosync). >=20 > The -l option of halt and reboot now not only suppresses logging, but > also user notification. It does this by signaling init directly and = not > going through shutdown. >=20 > The -o option of shutdown goes away because there does not seem any > point in executing halt or reboot if they are going to send the same > signal to init anyway. >=20 > diff --git a/include/paths.h b/include/paths.h > index 6503934..f93cf39 100644 > --- a/include/paths.h > +++ b/include/paths.h > @@ -84,6 +84,7 @@ > #define _PATH_RSH "/usr/bin/rsh" > #define _PATH_SENDMAIL "/usr/sbin/sendmail" > #define _PATH_SHELLS "/etc/shells" > +#define _PATH_SHUTDOWN "/sbin/shutdown" > #define _PATH_TTY "/dev/tty" > #define _PATH_UNIX "don't use _PATH_UNIX" > #define _PATH_VI "/usr/bin/vi" > diff --git a/sbin/reboot/reboot.8 b/sbin/reboot/reboot.8 > index 13d7098..50c27ee 100644 > --- a/sbin/reboot/reboot.8 > +++ b/sbin/reboot/reboot.8 > @@ -55,12 +55,11 @@ The > .Nm halt > and > .Nm > -utilities flush the file system cache to disk, send all running = processes > -a > -.Dv SIGTERM > -(and subsequently a > -.Dv SIGKILL ) > -and, respectively, halt or restart the system. > +utilities invoke > +.Xr shutdown 8 > +or signal > +.Xr init 8 > +to, respectively, halt or restart the system. > The action is logged, including entering a shutdown record into the = user > accounting database. > .Pp > @@ -69,7 +68,9 @@ The options are as follows: > .It Fl d > The system is requested to create a crash dump. > This option is > -supported only when rebooting, and it has no effect unless a dump > +supported only when rebooting together with the > +.Fl q > +option, and it has no effect unless a dump > device has previously been specified with > .Xr dumpon 8 . > .It Fl k Ar kernel > @@ -86,25 +87,14 @@ This may change in the future. > .It Fl l > The halt or reboot is > .Em not > -logged to the system log. > -This option is intended for applications such as > -.Xr shutdown 8 , > -that call > -.Nm > -or > -.Nm halt > -and log this themselves. > +logged to the system log and not announced to users. > .It Fl n > The file system cache is not flushed. > -This option should probably not be used. > +This option should probably not be used and only works together with = the > +.Fl q > +option. > .It Fl p > The system will turn off the power if it can. > -If the power down action fails, the system > -will halt or reboot normally, depending on whether > -.Nm halt > -or > -.Nm > -was called. > .It Fl q > The system is halted or restarted quickly and ungracefully, and only > the flushing of the file system cache is performed (if the > @@ -122,12 +112,6 @@ utilities are nothing more than aliases for the > and > .Nm > utilities. > -.Pp > -Normally, the > -.Xr shutdown 8 > -utility is used when the system needs to be halted or restarted, = giving > -users advance warning of their impending doom and cleanly terminating > -specific programs. > .Sh SEE ALSO > .Xr getutxent 3 , > .Xr boot 8 , > diff --git a/sbin/reboot/reboot.c b/sbin/reboot/reboot.c > index d927db0..285437a 100644 > --- a/sbin/reboot/reboot.c > +++ b/sbin/reboot/reboot.c > @@ -44,31 +44,27 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > -#include > #include > #include > #include > #include > +#include > #include > #include > #include > #include > #include > #include > -#include >=20 > static void usage(void); > -static u_int get_pageins(void); >=20 > static int dohalt; >=20 > int > main(int argc, char *argv[]) > { > - struct utmpx utx; > const struct passwd *pw; > - int ch, howto, i, fd, lflag, nflag, qflag, sverrno; > - u_int pageins; > + int ch, howto, fd, lflag, qflag; > const char *user, *kernel =3D NULL; >=20 > if (strcmp(getprogname(), "halt") =3D=3D 0) { > @@ -76,7 +72,7 @@ main(int argc, char *argv[]) > howto =3D RB_HALT; > } else > howto =3D 0; > - lflag =3D nflag =3D qflag =3D 0; > + lflag =3D qflag =3D 0; > while ((ch =3D getopt(argc, argv, "dk:lnpq")) !=3D -1) > switch(ch) { > case 'd': > @@ -89,7 +85,6 @@ main(int argc, char *argv[]) > lflag =3D 1; > break; > case 'n': > - nflag =3D 1; > howto |=3D RB_NOSYNC; > break; > case 'p': > @@ -107,6 +102,10 @@ main(int argc, char *argv[]) >=20 > if ((howto & (RB_DUMP | RB_HALT)) =3D=3D (RB_DUMP | RB_HALT)) > errx(1, "cannot dump (-d) when halting; must reboot = instead"); > + if (!qflag && (howto & RB_DUMP) !=3D 0) > + errx(1, "cannot dump (-d) without immediate reboot(2) = (-q)"); > + if (!qflag && (howto & RB_NOSYNC) !=3D 0) > + errx(1, "cannot disable sync (-n) without immediate = reboot(2) (-q)"); > if (geteuid()) { > errno =3D EPERM; > err(1, NULL); > @@ -129,6 +128,16 @@ main(int argc, char *argv[]) > } > } >=20 > +#ifndef RESCUE > + if (!lflag) { > + execl(_PATH_SHUTDOWN, _PATH_SHUTDOWN, > + (howto & RB_POWEROFF) !=3D 0 ? "-p" : > + (howto & RB_HALT) !=3D 0 ? "-h" : > + "-r", "now", (char *)NULL); > + warn("cannot execute %s; signaling init(8)", = _PATH_SHUTDOWN); > + } > +#endif > + > /* Log the reboot. */ > if (!lflag) { > if ((user =3D getlogin()) =3D=3D NULL) > @@ -142,80 +151,12 @@ main(int argc, char *argv[]) > syslog(LOG_CRIT, "rebooted by %s", user); > } > } > - utx.ut_type =3D SHUTDOWN_TIME; > - gettimeofday(&utx.ut_tv, NULL); > - pututxline(&utx); > - > - /* > - * Do a sync early on, so disks start transfers while we're off > - * killing processes. Don't worry about writes done before the > - * processes die, the reboot system call syncs the disks. > - */ > - if (!nflag) > - sync(); > - > - /* > - * Ignore signals that we can get as a result of killing > - * parents, group leaders, etc. > - */ > - (void)signal(SIGHUP, SIG_IGN); > - (void)signal(SIGINT, SIG_IGN); > - (void)signal(SIGQUIT, SIG_IGN); > - (void)signal(SIGTERM, SIG_IGN); > - (void)signal(SIGTSTP, SIG_IGN); > - > - /* > - * If we're running in a pipeline, we don't want to die > - * after killing whatever we're writing to. > - */ > - (void)signal(SIGPIPE, SIG_IGN); > - > - /* Just stop init -- if we fail, we'll restart it. */ > - if (kill(1, SIGTSTP) =3D=3D -1) > - err(1, "SIGTSTP init"); > - > - /* Send a SIGTERM first, a chance to save the buffers. */ > - if (kill(-1, SIGTERM) =3D=3D -1 && errno !=3D ESRCH) > - err(1, "SIGTERM processes"); > - > - /* > - * After the processes receive the signal, start the rest of the > - * buffers on their way. Wait 5 seconds between the SIGTERM and > - * the SIGKILL to give everybody a chance. If there is a lot of > - * paging activity then wait longer, up to a maximum of approx > - * 60 seconds. > - */ > - sleep(2); > - for (i =3D 0; i < 20; i++) { > - pageins =3D get_pageins(); > - if (!nflag) > - sync(); > - sleep(3); > - if (get_pageins() =3D=3D pageins) > - break; > - } > - > - for (i =3D 1;; ++i) { > - if (kill(-1, SIGKILL) =3D=3D -1) { > - if (errno =3D=3D ESRCH) > - break; > - goto restart; > - } > - if (i > 5) { > - (void)fprintf(stderr, > - "WARNING: some process(es) wouldn't die\n"); > - break; > - } > - (void)sleep(2 * i); > - } > - > - reboot(howto); > - /* FALLTHROUGH */ >=20 > -restart: > - sverrno =3D errno; > - errx(1, "%s%s", kill(1, SIGHUP) =3D=3D -1 ? "(can't restart = init): " : "", > - strerror(sverrno)); > + if (kill(1, (howto & RB_POWEROFF) !=3D 0 ? SIGUSR2 : > + (howto & RB_HALT) !=3D 0 ? SIGUSR1 : > + SIGINT) =3D=3D -1) > + err(1, "signal init"); > + pause(); > /* NOTREACHED */ > } >=20 > @@ -228,18 +169,3 @@ usage(void) > "usage: reboot [-dlnpq] [-k kernel]\n"); > exit(1); > } > - > -static u_int > -get_pageins(void) > -{ > - u_int pageins; > - size_t len; > - > - len =3D sizeof(pageins); > - if (sysctlbyname("vm.stats.vm.v_swappgsin", &pageins, &len, = NULL, 0) > - !=3D 0) { > - warnx("v_swappgsin"); > - return (0); > - } > - return pageins; > -} > diff --git a/sbin/shutdown/shutdown.8 b/sbin/shutdown/shutdown.8 > index b7067e1..37152ac 100644 > --- a/sbin/shutdown/shutdown.8 > +++ b/sbin/shutdown/shutdown.8 > @@ -42,10 +42,6 @@ > .Fl h | Fl p | > .Fl r | Fl k > .Oc > -.Oo > -.Fl o > -.Op Fl n > -.Oc > .Ar time > .Op Ar warning-message ... > .Nm poweroff > @@ -77,30 +73,6 @@ The > option > does not actually halt the system, but leaves the > system multi-user with logins disabled (for all but super-user). > -.It Fl o > -If one of the > -.Fl h , > -.Fl p > -or > -.Fl r > -options are specified, > -.Nm > -will execute > -.Xr halt 8 > -or > -.Xr reboot 8 > -instead of sending a signal to > -.Xr init 8 . > -.It Fl n > -If the > -.Fl o > -option is specified, prevent the file system cache from being flushed = by passing > -.Fl n > -to > -.Xr halt 8 > -or > -.Xr reboot 8 . > -This option should probably not be used. > .It Ar time > .Ar Time > is the time at which > diff --git a/sbin/shutdown/shutdown.c b/sbin/shutdown/shutdown.c > index 6e662a8..945bef2 100644 > --- a/sbin/shutdown/shutdown.c > +++ b/sbin/shutdown/shutdown.c > @@ -88,9 +88,9 @@ static struct interval { > #undef S >=20 > static time_t offset, shuttime; > -static int dohalt, dopower, doreboot, killflg, mbuflen, oflag; > +static int dohalt, dopower, doreboot, killflg, mbuflen; > static char mbuf[BUFSIZ]; > -static const char *nosync, *whom; > +static const char *whom; >=20 > static void badtime(void); > static void perform_shutdown(void); > @@ -116,7 +116,6 @@ main(int argc, char **argv) > errx(1, "NOT super-user"); > #endif >=20 > - nosync =3D NULL; > readstdin =3D 0; >=20 > /* > @@ -152,10 +151,8 @@ main(int argc, char **argv) > killflg =3D 1; > break; > case 'n': > - nosync =3D "-n"; > - break; > case 'o': > - oflag =3D 1; > + /* Ignore -n and -o for compatibility. */ > break; > case 'p': > dopower =3D 1; > @@ -176,12 +173,6 @@ main(int argc, char **argv) > if (killflg + doreboot + dohalt + dopower > 1) > usage("incompatible switches -h, -k, -p and -r"); >=20 > - if (oflag && !(dohalt || dopower || doreboot)) > - usage("-o requires -h, -p or -r"); > - > - if (nosync !=3D NULL && !oflag) > - usage("-n requires -o"); > - > getoffset(*argv++); >=20 > poweroff: > @@ -351,8 +342,6 @@ timeout(int signo __unused) > static void > perform_shutdown(void) > { > - char *empty_environ[] =3D { NULL }; > - > syslog(LOG_NOTICE, "%s by %s: %s", > doreboot ? "reboot" : dohalt ? "halt" : dopower ? = "power-down" :=20 > "shutdown", whom, mbuf); > @@ -370,39 +359,12 @@ perform_shutdown(void) > (void)printf("halt"); > else if (dopower) > (void)printf("power-down"); > - if (nosync !=3D NULL) > - (void)printf(" no sync"); > (void)printf("\nkill -HUP 1\n"); > #else > - if (!oflag) { > - (void)kill(1, doreboot ? SIGINT : /* reboot */ > - dohalt ? SIGUSR1 : /* halt */ > - dopower ? SIGUSR2 : /* power-down */ > - SIGTERM); /* single-user = */ > - } else { > - if (doreboot) { > - execle(_PATH_REBOOT, "reboot", "-l", nosync,=20 > - (char *)NULL, empty_environ); > - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", > - _PATH_REBOOT); > - warn(_PATH_REBOOT); > - } > - else if (dohalt) { > - execle(_PATH_HALT, "halt", "-l", nosync, > - (char *)NULL, empty_environ); > - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", > - _PATH_HALT); > - warn(_PATH_HALT); > - } > - else if (dopower) { > - execle(_PATH_HALT, "halt", "-l", "-p", nosync, > - (char *)NULL, empty_environ); > - syslog(LOG_ERR, "shutdown: can't exec %s: %m.", > - _PATH_HALT); > - warn(_PATH_HALT); > - } > - (void)kill(1, SIGTERM); /* to single-user */ > - } > + (void)kill(1, doreboot ? SIGINT : /* reboot */ > + dohalt ? SIGUSR1 : /* halt */ > + dopower ? SIGUSR2 : /* power-down */ > + SIGTERM); /* single-user */ > #endif > finish(0); > } > @@ -534,7 +496,7 @@ usage(const char *cp) > if (cp !=3D NULL) > warnx("%s", cp); > (void)fprintf(stderr, > - "usage: shutdown [-] [-h | -p | -r | -k] [-o [-n]] time = [warning-message ...]\n" > + "usage: shutdown [-] [-h | -p | -r | -k] time = [warning-message ...]\n" > " poweroff\n"); > exit(1); > } >=20 > --=20 > Jilles Tjoelker > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-arch@FreeBSD.ORG Mon May 14 09:25:30 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 319F7106564A for ; Mon, 14 May 2012 09:25:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D6DCE151544; Mon, 14 May 2012 09:25:29 +0000 (UTC) Message-ID: <4FB0CF88.5010309@FreeBSD.org> Date: Mon, 14 May 2012 02:25:28 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Warner Losh References: <20120513220646.GA12826@stack.nl> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:25:30 -0000 On 5/13/2012 3:42 PM, Warner Losh wrote: > > On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >> Also, the normal forms of halt and reboot will now call shutdown >> so users get a clear message of the event. > > I hate these messages, which is why I always use halt or reboot to > avoid them. You hate messages? Seriously? > I find the additional delays from doing a shutdown -r to > also be annoying, which is why I never use them. If things are working as they should be, running rc.shutdown won't cause any delays at all vs. the brute force method used by 'shutdown'. The only time you'll see a delay is if something that's being killed actually needs it to cleanly shut down. >> Halt and reboot still support the -q option to invoke reboot(2) >> without anything else. The -d and -n options now require -q >> (because init is signaled if -q is not used, and init will not do >> dump or nosync). >> >> The -l option of halt and reboot now not only suppresses logging, >> but also user notification. It does this by signaling init directly >> and not going through shutdown. >> >> The -o option of shutdown goes away because there does not seem >> any point in executing halt or reboot if they are going to send the >> same signal to init anyway. > > Generally, I think this is a really bad idea, just like the last time > it was proposed. 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. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Mon May 14 14:39:58 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7FD91065698; Mon, 14 May 2012 14:39:58 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4E83C8FC18; Mon, 14 May 2012 14:39:58 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4EEaeAx042761 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 May 2012 08:36:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4FB0CF88.5010309@FreeBSD.org> Date: Mon, 14 May 2012 08:36:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 14 May 2012 08:36:41 -0600 (MDT) Cc: Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:39:58 -0000 On May 14, 2012, at 3:25 AM, Doug Barton wrote: > On 5/13/2012 3:42 PM, Warner Losh wrote: >>=20 >> On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >>> Also, the normal forms of halt and reboot will now call shutdown >>> so users get a clear message of the event. >>=20 >> I hate these messages, which is why I always use halt or reboot to >> avoid them.=20 >=20 > You hate messages? Seriously? Seriously. And I'd appreciate it if you didn't mock me on this. It is = rude and insulting and not constructive to a dialog. >> I find the additional delays from doing a shutdown -r to >> also be annoying, which is why I never use them. >=20 > If things are working as they should be, running rc.shutdown won't = cause > any delays at all vs. the brute force method used by 'shutdown'. The > only time you'll see a delay is if something that's being killed > actually needs it to cleanly shut down. halt and reboot are low level interfaces. shutdown is the higher level = interface that people should use. >>> Halt and reboot still support the -q option to invoke reboot(2) >>> without anything else. The -d and -n options now require -q >>> (because init is signaled if -q is not used, and init will not do >>> dump or nosync). >>>=20 >>> The -l option of halt and reboot now not only suppresses logging, >>> but also user notification. It does this by signaling init directly >>> and not going through shutdown. >>>=20 >>> The -o option of shutdown goes away because there does not seem >>> any point in executing halt or reboot if they are going to send the >>> same signal to init anyway. >>=20 >> Generally, I think this is a really bad idea, just like the last time >> it was proposed. >=20 > 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. >=20 > 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. Warner= From owner-freebsd-arch@FreeBSD.ORG Mon May 14 14:58:07 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D72161065670; Mon, 14 May 2012 14:58:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 85A9B8FC0C; Mon, 14 May 2012 14:58:07 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4EEqiP4042857 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 14 May 2012 08:52:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> Date: Mon, 14 May 2012 08:52:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 14 May 2012 08:52:45 -0600 (MDT) Cc: Doug Barton , Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:58:08 -0000 On May 14, 2012, at 8:36 AM, Warner Losh wrote: >=20 > On May 14, 2012, at 3:25 AM, Doug Barton wrote: >=20 >> On 5/13/2012 3:42 PM, Warner Losh wrote: >>>=20 >>> On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >>>> Also, the normal forms of halt and reboot will now call shutdown >>>> so users get a clear message of the event. >>>=20 >>> I hate these messages, which is why I always use halt or reboot to >>> avoid them.=20 >>=20 >> You hate messages? Seriously? >=20 > Seriously. And I'd appreciate it if you didn't mock me on this. It = is rude and insulting and not constructive to a dialog. >=20 >>> I find the additional delays from doing a shutdown -r to >>> also be annoying, which is why I never use them. >>=20 >> If things are working as they should be, running rc.shutdown won't = cause >> any delays at all vs. the brute force method used by 'shutdown'. The >> only time you'll see a delay is if something that's being killed >> actually needs it to cleanly shut down. >=20 > halt and reboot are low level interfaces. shutdown is the higher = level interface that people should use. >=20 >>>> Halt and reboot still support the -q option to invoke reboot(2) >>>> without anything else. The -d and -n options now require -q >>>> (because init is signaled if -q is not used, and init will not do >>>> dump or nosync). >>>>=20 >>>> The -l option of halt and reboot now not only suppresses logging, >>>> but also user notification. It does this by signaling init directly >>>> and not going through shutdown. >>>>=20 >>>> The -o option of shutdown goes away because there does not seem >>>> any point in executing halt or reboot if they are going to send the >>>> same signal to init anyway. >>>=20 >>> Generally, I think this is a really bad idea, just like the last = time >>> it was proposed. >>=20 >> 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. >>=20 >> 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. >=20 > See my other post for a way forward, sans bogusly scary names. 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. The distaste for extra, useless messages, I'll admit, is a personality = quirk that I share with many people. Warner= From owner-freebsd-arch@FreeBSD.ORG Mon May 14 22:48:19 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89ECA106564A; Mon, 14 May 2012 22:48:19 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 22E688FC08; Mon, 14 May 2012 22:48:19 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 58B2A1DD65E; Tue, 15 May 2012 00:48:17 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 3E0822847A; Tue, 15 May 2012 00:48:17 +0200 (CEST) Date: Tue, 15 May 2012 00:48:17 +0200 From: Jilles Tjoelker To: Warner Losh Message-ID: <20120514224817.GA31383@stack.nl> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 22:48:19 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Tue May 15 00:38:57 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CB76106564A for ; Tue, 15 May 2012 00:38:57 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id BEF238FC08 for ; Tue, 15 May 2012 00:38:56 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q4F0ctsE014786; Mon, 14 May 2012 20:38:55 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q4F0cs3u014785; Mon, 14 May 2012 20:38:54 -0400 (EDT) (envelope-from wollman) Date: Mon, 14 May 2012 20:38:54 -0400 (EDT) From: Garrett Wollman Message-Id: <201205150038.q4F0cs3u014785@hergotha.csail.mit.edu> To: jilles@stack.nl X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: <20120514224817.GA31383@stack.nl> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 14 May 2012 20:38:55 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: arch@freebsd.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 00:38:57 -0000 In article <20120514224817.GA31383@stack.nl>, julles@stack.nl writes: >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). It's useful to me, as it gives me time to log out cleanly. -GAWollman -- Garrett A. Wollman | What intellectual phenomenon can be older, or more oft wollman@bimajority.org| repeated, than the story of a large research program Opinions not shared by| that impaled itself upon a false central assumption my employers. | accepted by all practitioners? - S.J. Gould, 1993 From owner-freebsd-arch@FreeBSD.ORG Tue May 15 02:15:45 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B656106566C for ; Tue, 15 May 2012 02:15:45 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4C18FC0A for ; Tue, 15 May 2012 02:15:44 +0000 (UTC) Received: by werg1 with SMTP id g1so3719516wer.13 for ; Mon, 14 May 2012 19:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zv45ugk07xMpVZqrc3+I3lUtduQNZ6FG0nJGDgJJRic=; b=CFCE4LZJCuPUbJWhrEpipdlTEcadQ+ccBKhiu7wdGHDNOhrSRCckl68jq2cNZL9Nuu ShwpaFn0YRTMZ/64DdMi9KyvUV3u+MV84nf7aq8ePJpT+IMVeZ/m6C+8Lom4JtZT7zIu LX6r4vBApNTBe5U7XJ96rHzReKA4HhxzdiQfA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Zv45ugk07xMpVZqrc3+I3lUtduQNZ6FG0nJGDgJJRic=; b=TXJ/IrGT2q4J6VFNqk6s4ogemwpZXg3awI4/30fUxoSQhGZX8MRd2c/ACEu8Z+KcIJ 1jwD8ef/NjBYym4sq166Wy5YG2MR4CueaOaB3RycfGXNsZRa5CCbsmkIw1p9ct4aIXUv s6cLKhfvTJn7utZFmIDAyY/oLk1kl73OA4Y/rPSkOh5utlvSI2rBZtfi7iXJqUvN5Ifq TGn52jbgGAm9Aa9mdCpkOlQp1JX6oJG2VWfHJSQ2Wa+yIyC24wg0zgmrMKA6OVw9MvFP 1Walicwf+iE9Pta0vAfxlrDrGEUI3KjjbHSoRWdI7TQqA9WsgLPKx2GZFaLNggPn/wIj uDRA== Received: by 10.216.137.156 with SMTP id y28mr6562827wei.61.1337048138510; Mon, 14 May 2012 19:15:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.120.6 with HTTP; Mon, 14 May 2012 19:15:08 -0700 (PDT) In-Reply-To: <201205150038.q4F0cs3u014785@hergotha.csail.mit.edu> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <88BE52F2-E8CC-455D-B7AF-CB1F876D48B7@bsdimp.com> <20120514224817.GA31383@stack.nl> <201205150038.q4F0cs3u014785@hergotha.csail.mit.edu> From: Eitan Adler Date: Mon, 14 May 2012 22:15:08 -0400 Message-ID: To: Garrett Wollman Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnhbuD732MdGBgIBOA/DagrhziDlx9UhJ+e4pzmjjuvyfUIWAIMQxAV0Grk5px32XzFd75n Cc: arch@freebsd.org, jilles@stack.nl Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 02:15:45 -0000 On 14 May 2012 20:38, Garrett Wollman wrote: > In article <20120514224817.GA31383@stack.nl>, julles@stack.nl writes: >>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). > > It's useful to me, as it gives me time to log out cleanly. don't use "now" then :) -- Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Wed May 16 14:24:53 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF2F1065672 for ; Wed, 16 May 2012 14:24:53 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E948F8FC1B for ; Wed, 16 May 2012 14:24:52 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D351F65BC; Wed, 16 May 2012 14:24:51 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A21808ADD; Wed, 16 May 2012 16:24:51 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <4FAC3EAB.6050303@delphij.net> Date: Wed, 16 May 2012 16:24:51 +0200 In-Reply-To: <4FAC3EAB.6050303@delphij.net> (Xin Li's message of "Thu, 10 May 2012 15:18:19 -0700") Message-ID: <861umkurt8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:24:53 -0000 Xin Li writes: > Is there any concern of changing this to allow a few memory pages be > locked and remove the limit when the calling process is superuser? Good idea - this would allow gnupg to work without a setuid bit. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed May 16 14:30:34 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB498106564A; Wed, 16 May 2012 14:30:34 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0728FC19; Wed, 16 May 2012 14:30:34 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D317865C3; Wed, 16 May 2012 14:30:33 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AA1708ADF; Wed, 16 May 2012 16:30:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Warner Losh References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> Date: Wed, 16 May 2012 16:30:33 +0200 In-Reply-To: <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> (Warner Losh's message of "Mon, 14 May 2012 08:36:40 -0600") Message-ID: <86wr4ctcza.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:30:34 -0000 Warner Losh writes: > Doug Barton writes: > > Warner Losh writes: > > > I hate these messages, which is why I always use halt or reboot to > > > avoid them.=20 > > You hate messages? Seriously? > Seriously. And I'd appreciate it if you didn't mock me on this. It > is rude and insulting and not constructive to a dialog. Sorry, Warner, but what I see here is *you* attacking and insulting Jilles and Doug. > The distaste for extra, useless messages, I'll admit, is a personality > quirk that I share with many people. "The silent majority supports me" is not a valid argument. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed May 16 16:35:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4818E1065675; Wed, 16 May 2012 16:35:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id F24948FC12; Wed, 16 May 2012 16:35:09 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4GGVPYA072598 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 10:31:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: <86wr4ctcza.fsf@ds4.des.no> Date: Wed, 16 May 2012 10:31:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <04F10830-664A-4C60-9A85-C5874D2A30F4@bsdimp.com> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <86wr4ctcza.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 16 May 2012 10:31:28 -0600 (MDT) Cc: Doug Barton , Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 16:35:10 -0000 On May 16, 2012, at 8:30 AM, Dag-Erling Sm=F8rgrav wrote: > Warner Losh writes: >> Doug Barton writes: >>> Warner Losh writes: >>>> I hate these messages, which is why I always use halt or reboot to >>>> avoid them.=20 >>> You hate messages? Seriously? >> Seriously. And I'd appreciate it if you didn't mock me on this. It >> is rude and insulting and not constructive to a dialog. >=20 > Sorry, Warner, but what I see here is *you* attacking and insulting > Jilles and Doug. No, I was telling Doug to back off since he's been annoying me lately. = And I haven't been insulting Jiles at all. This came up before, there = was no consensus. It has come up again and we're making progress to a = solution this time. >> The distaste for extra, useless messages, I'll admit, is a = personality >> quirk that I share with many people. >=20 > "The silent majority supports me" is not a valid argument. That's not my argument at all. Please don't twist it into that. Go = check the IRC logs for the folks that chimed in, but really, we're = talking about changing interfaces that people are used to and aren't too = keen on giving up. Have a nice day. Warner From owner-freebsd-arch@FreeBSD.ORG Wed May 16 19:50:32 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9F794106564A for ; Wed, 16 May 2012 19:50:31 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 51A4714DB03; Wed, 16 May 2012 19:50:31 +0000 (UTC) Message-ID: <4FB40506.3000300@FreeBSD.org> Date: Wed, 16 May 2012 12:50:30 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120506 Thunderbird/12.0.1 MIME-Version: 1.0 To: Warner Losh References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> In-Reply-To: <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> X-Enigmail-Version: 1.5pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jilles Tjoelker , freebsd-arch@FreeBSD.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 19:50:32 -0000 On 05/14/2012 07:36, Warner Losh wrote: > > On May 14, 2012, at 3:25 AM, Doug Barton wrote: > >> On 5/13/2012 3:42 PM, Warner Losh wrote: >>> >>> On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >>>> Also, the normal forms of halt and reboot will now call >>>> shutdown so users get a clear message of the event. >>> >>> I hate these messages, which is why I always use halt or reboot >>> to avoid them. >> >> You hate messages? Seriously? > > Seriously. And I'd appreciate it if you didn't mock me on this. It > is rude and insulting and not constructive to a dialog. Just to be clear, I wasn't mocking you. I recently did actually mock someone for something that seemed so totally impossible that I felt it was safe to mock, and it turned out I was wrong. So what I'm trying to get at is what your real concerns are. If you seriously hate messages saying that things are shutting down properly, and that's a key issue for you objecting to the change that Jilles is proposing, we can look at ways to mitigate that. If what you're really saying is, "I want to do it the old way, no matter what," that's a whole different issue. >>> I find the additional delays from doing a shutdown -r to also be >>> annoying, which is why I never use them. >> >> If things are working as they should be, running rc.shutdown won't >> cause any delays at all vs. the brute force method used by >> 'shutdown'. The only time you'll see a delay is if something that's >> being killed actually needs it to cleanly shut down. > > halt and reboot are low level interfaces. shutdown is the higher > level interface that people should use. The problem is that people see the names "halt" and "reboot" and assume that "simpler is better" and use them. The fact that the proper way to reboot a FreeBSD system is 'shutdown -r' is ... just silly. > See my other post for a way forward, sans bogusly scary names. I've read the other messages in the thread, and I'm glad to see we're converging on a way forward. I don't like the names fast{halt|reboot} because they still sound "better" than the proper solutions to an unsophisticated user. My first choice would be something like unsafe, but I'd settle for something like old as the prefix. Then we can make 'reboot' do what 'shutdown -r' does, and 'halt' equivalent to 'shutdown -p'. Doug -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Wed May 16 21:09:37 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 364AE1065670; Wed, 16 May 2012 21:09:37 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EE3B48FC16; Wed, 16 May 2012 21:09:36 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4GL3euF075047 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 15:03:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4FB40506.3000300@FreeBSD.org> Date: Wed, 16 May 2012 15:03:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <4FB40506.3000300@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 16 May 2012 15:03:43 -0600 (MDT) Cc: Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:09:37 -0000 On May 16, 2012, at 1:50 PM, Doug Barton wrote: > On 05/14/2012 07:36, Warner Losh wrote: >>=20 >> On May 14, 2012, at 3:25 AM, Doug Barton wrote: >>=20 >>> On 5/13/2012 3:42 PM, Warner Losh wrote: >>>>=20 >>>> On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >>>>> Also, the normal forms of halt and reboot will now call >>>>> shutdown so users get a clear message of the event. >>>>=20 >>>> I hate these messages, which is why I always use halt or reboot >>>> to avoid them. >>>=20 >>> You hate messages? Seriously? >>=20 >> Seriously. And I'd appreciate it if you didn't mock me on this. It >> is rude and insulting and not constructive to a dialog. >=20 > Just to be clear, I wasn't mocking you. I recently did actually mock > someone for something that seemed so totally impossible that I felt it > was safe to mock, and it turned out I was wrong. So what I'm trying to > get at is what your real concerns are. Yea. I'm having a colorful backstory in my life, so I'm a little more = touchy than normal. Sorry if I needlessly flew off the handle. > If you seriously hate messages saying that things are shutting down > properly, and that's a key issue for you objecting to the change that > Jilles is proposing, we can look at ways to mitigate that. If what > you're really saying is, "I want to do it the old way, no matter = what," > that's a whole different issue. Nah, I'm just expressing concern that existing users, as well as = existing programs, expect things a certain way and to change things for = no better than aesthetics is unwise. In the course of the discussion, = it's clear that there's more to it than that, and some accommodation is = needed... >>>> I find the additional delays from doing a shutdown -r to also be >>>> annoying, which is why I never use them. >>>=20 >>> If things are working as they should be, running rc.shutdown won't >>> cause any delays at all vs. the brute force method used by >>> 'shutdown'. The only time you'll see a delay is if something that's >>> being killed actually needs it to cleanly shut down. >>=20 >> halt and reboot are low level interfaces. shutdown is the higher >> level interface that people should use. >=20 > The problem is that people see the names "halt" and "reboot" and = assume > that "simpler is better" and use them. The fact that the proper way to > reboot a FreeBSD system is 'shutdown -r' is ... just silly. Right, but this is the historical way things have been done, and there = are many existing users who have products that depend on the difference. = So the argument for change needs to be stronger. I think a more proper argument could be made that the times have changed = and that while it would be desirable to retain the old interface, it is = more desirable to file off the rough edges from the crufty old = interfaces to improve the user experience for the hordes that are coming = from the Linux world. Of course, if all reboot is going to do is call shutdown -r now, then = maybe it makes sense to just install a shell script called reboot and = rename the current reboot to fastreboot. >> See my other post for a way forward, sans bogusly scary names. >=20 > I've read the other messages in the thread, and I'm glad to see we're > converging on a way forward. I don't like the names fast{halt|reboot} > because they still sound "better" than the proper solutions to an > unsophisticated user. My first choice would be something like unsafe, > but I'd settle for something like old as the prefix. Then we can make > 'reboot' do what 'shutdown -r' does, and 'halt' equivalent to = 'shutdown > -p'. Well, a simple alias in root's .profile could do that :) Sadly, that's = not a sufficient solution for a number of reasons. However, I think that we can get most of what is needed here by = tightening up the shutdown -r path, and reinventing[*] fasthalt and = fastreboot from SunOS 4.x days. Then reboot/halt could easily be a = simple shell script that invokes shutdown. This would allow the = embedded folks to replace it with fast*, while allowing the enterprise = customers a more uniform experience with their linux and solaris = systems. And the tightening up would likely cause the developer = community to not notice as much the difference, because the artificial = delays have been removed. Or to add to their .profile/.cshrc files = something along the lines of alias reboot fastreboot. Warner [*] I say reinventing here because IIRC fastboot also suppressed the = full fsck of filesystems when the system is coming back up. with zfs, = ufs + suj, the clean flag short-curcuit, etc that functionality is no = longer all that useful.= From owner-freebsd-arch@FreeBSD.ORG Wed May 16 21:37:18 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5ADC1065672 for ; Wed, 16 May 2012 21:37:18 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 2D61C8FC12 for ; Wed, 16 May 2012 21:37:17 +0000 (UTC) Received: from server.rulingia.com (c220-239-254-65.belrs5.nsw.optusnet.com.au [220.239.254.65]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4GLb9Np011650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 May 2012 07:37:10 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q4GLb8NM084390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 May 2012 07:37:08 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q4GLb8Mn084389 for freebsd-arch@freebsd.org; Thu, 17 May 2012 07:37:08 +1000 (EST) (envelope-from peter) Date: Thu, 17 May 2012 07:37:08 +1000 From: Peter Jeremy To: freebsd-arch@freebsd.org Message-ID: <20120516213708.GA84284@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Subject: References to non-existent block devices X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 21:37:18 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've noticed that although block devices were removed from FreeBSD quite some time ago, there are still lots of references to them in man pages and comments. I've raised docs/167832 to basically change these references to "disk devices". I would appreciate a few more eyes having a look over my suggested changes. --=20 Peter Jeremy --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+0HgQACgkQ/opHv/APuIdDzACgqlaz46D1A8GROPUSjNVd36tg nbQAnjhM/7gW24Gtuf3eifXBIgLz2E7y =DLAv -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-arch@FreeBSD.ORG Wed May 16 22:32:43 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07C9B1065675 for ; Wed, 16 May 2012 22:32:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFA38FC1D for ; Wed, 16 May 2012 22:32:42 +0000 (UTC) Received: by lbon10 with SMTP id n10so1232181lbo.13 for ; Wed, 16 May 2012 15:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DdRYwCANa4+kvbGLe35iRsS7tULn7i47kUJeW0YHvbc=; b=CZw6zAk1TZcjp/6Yh9AEO4TsQ6fAm3/fAf6bOSs4vWGoCT/FkrtsBH1gXzUbjVUS8I pA6iXkThP4ZA+txBjl9gJNNHs+xPc8+Etjpwc5U6f2awUAzsJPBaiE56f3vQAUsiN16L gGKuNnpnslc7oTMcuT5t3EIdjsGa4OPy9r7KLmW6X2LGiXSJ40W2rbgDlvWDpzfgxrbK Vooao1NfQTPC6DR7OAdf51UTdnQu3GGbjRlGgu3MrZD29A2IM4/mPaJn5hPRXkR2LfXQ OBnDway0erEC0lBztMPGPwSJIuDbkwyDf4FkTSFgGZV3wD4KiAhkRvmtM70Z3Ic+2Yu0 lB/g== MIME-Version: 1.0 Received: by 10.152.135.105 with SMTP id pr9mr4767202lab.37.1337207561305; Wed, 16 May 2012 15:32:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.112.149.106 with HTTP; Wed, 16 May 2012 15:32:40 -0700 (PDT) In-Reply-To: <861umkurt8.fsf@ds4.des.no> References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> Date: Wed, 16 May 2012 15:32:40 -0700 X-Google-Sender-Auth: X9s8JS6WvgJEsTSRsnDXnJIhxXg Message-ID: From: Adrian Chadd To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Cc: d@delphij.net, freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:32:43 -0000 .. what's to stop a fork() bomb from grabbing all pages? Adrian From owner-freebsd-arch@FreeBSD.ORG Wed May 16 22:36:50 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90401106564A for ; Wed, 16 May 2012 22:36:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 136A98FC08 for ; Wed, 16 May 2012 22:36:49 +0000 (UTC) Received: by werg1 with SMTP id g1so1036046wer.13 for ; Wed, 16 May 2012 15:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=HaVNpt7HtaW9VaFCuTin7sPh0I4xuV0nUaJ9F6mAJG0=; b=f/Cft7PCGu68IpdwgeajnQvpYogvH+HNEdgP+3YbADyXYxmSJs/TNDjB4SM0FQwEy6 n9dpgOzyJfrMo+rf8LfZxQy/+ni1WR+drdgczjBxH6HarV4OeGjCD069A9ouxH1i0MzJ 8wjWOXBwJ+cQRNssvXN3na2lsbSY0KID+rhHA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=HaVNpt7HtaW9VaFCuTin7sPh0I4xuV0nUaJ9F6mAJG0=; b=TgxD0m7BPU76VOJVvSr7fmLHUs1YTWiELsbhHo9+5JNKXnu3pdH+oNNDNZYkbZuL9D /CLScVdwc2T11N0iUHMUKXJx3OBNxUl/rE/bBk4MFt+WCMo0JSxZDGRMmusF1L/evolK CQIVKX4a8rnpNYyhvBDB3Oriuw/p+BxGj9Cogg3mECtWxBy3ZtknYS0plKKQoRuBjc/F SqxJ48wT5V1W50EK4bkDn3Uzlr0MaUzS5zy0J4X+d3ZcVymddrVRY7FOFzEV+T7Kvxe5 OiiHp/Y5wBGGGBPB1FqgcmbeeQQZIn0QvVZMsAErBxCZHoVgB4NLfsNkuE3qnJ3N02Jc 9qGw== Received: by 10.180.24.103 with SMTP id t7mr45054166wif.16.1337207809146; Wed, 16 May 2012 15:36:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.120.6 with HTTP; Wed, 16 May 2012 15:36:18 -0700 (PDT) In-Reply-To: References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> From: Eitan Adler Date: Wed, 16 May 2012 18:36:18 -0400 Message-ID: To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkY6ZZNh9rH8ugrrZgqkpy/dNyx1kL9IfxRJGC9NHEDRYihSo0q0yLJY554BQfqvYwM7kHH Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:36:50 -0000 On 16 May 2012 18:32, Adrian Chadd wrote: > .. what's to stop a fork() bomb from grabbing all pages? + possibly limiting the number of pages per user, =C3=A0 la maxprocperuid. --=20 Eitan Adler From owner-freebsd-arch@FreeBSD.ORG Wed May 16 23:10:35 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82D65106564A; Wed, 16 May 2012 23:10:35 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA56D8FC0A; Wed, 16 May 2012 23:10:34 +0000 (UTC) Received: by laai10 with SMTP id i10so1262230laa.13 for ; Wed, 16 May 2012 16:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1PRutjv3oW7AhL/mY6Trhg63Li+meeo4AdrpX7OeukM=; b=WLNj03WAOsh5KR7nmU2xUqocPftagDzHTgYuB9sP2ZxTxQCoyz0BFWXOoWGyhzbCA3 6ujdv4ffWgzXK19bIRdFY2feR6RShEW+rgs0/F75Gp//lH7Z/pg+WDym6oS63S/UJKYU iTh539mcA8RHbqKx+KSPkCdsrNuZi7P+JdOZebFx4dVSwEUIir2NL1mqj5kVLJ2H6m2F SU5fdmXLDblX0EaF98Rig4el3xy971TQNnXIemD+mh98APGSigT/ptXOtTi4DRM5RDTl SPM/vOGRFGRE5DaicRkHWEd1jZViCEWX78MePGB3ztBQxViuT7nLXNFySWIBNjQg8s4m 8/fQ== MIME-Version: 1.0 Received: by 10.112.88.98 with SMTP id bf2mr2190400lbb.30.1337209827652; Wed, 16 May 2012 16:10:27 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.112.130.4 with HTTP; Wed, 16 May 2012 16:10:27 -0700 (PDT) In-Reply-To: References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> Date: Wed, 16 May 2012 16:10:27 -0700 X-Google-Sender-Auth: oF7d9KZworrDEWEMkDvK6dcx8Ys Message-ID: From: Artem Belevich To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , Adrian Chadd , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:10:35 -0000 On Wed, May 16, 2012 at 3:36 PM, Eitan Adler wrote: > On 16 May 2012 18:32, Adrian Chadd wrote: >> .. what's to stop a fork() bomb from grabbing all pages? > > + possibly limiting the number of pages per user, =E0 la > maxprocperuid. Shouldn't RLIMIT_NPROC already limit the damage? --Artem From owner-freebsd-arch@FreeBSD.ORG Thu May 17 05:28:42 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 854EB1065673 for ; Thu, 17 May 2012 05:28:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 20606153709; Thu, 17 May 2012 05:28:42 +0000 (UTC) Message-ID: <4FB48C89.9010703@FreeBSD.org> Date: Wed, 16 May 2012 22:28:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120506 Thunderbird/12.0.1 MIME-Version: 1.0 To: Warner Losh References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <4FB40506.3000300@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 05:28:42 -0000 On 05/16/2012 14:03, Warner Losh wrote: > > On May 16, 2012, at 1:50 PM, Doug Barton wrote: > >> On 05/14/2012 07:36, Warner Losh wrote: >>> >>> On May 14, 2012, at 3:25 AM, Doug Barton wrote: >>> >>>> On 5/13/2012 3:42 PM, Warner Losh wrote: >>>>> >>>>> On May 13, 2012, at 4:06 PM, Jilles Tjoelker wrote: >>>>>> Also, the normal forms of halt and reboot will now call >>>>>> shutdown so users get a clear message of the event. >>>>> >>>>> I hate these messages, which is why I always use halt or >>>>> reboot to avoid them. >>>> >>>> You hate messages? Seriously? >>> >>> Seriously. And I'd appreciate it if you didn't mock me on this. >>> It is rude and insulting and not constructive to a dialog. >> >> Just to be clear, I wasn't mocking you. I recently did actually >> mock someone for something that seemed so totally impossible that I >> felt it was safe to mock, and it turned out I was wrong. So what >> I'm trying to get at is what your real concerns are. > > Yea. I'm having a colorful backstory in my life, so I'm a little > more touchy than normal. Sorry if I needlessly flew off the handle. No problem. The pop culture version of "seriously?" is not what I intended, but I can certainly see how you could have taken it that way. >> If you seriously hate messages saying that things are shutting >> down properly, and that's a key issue for you objecting to the >> change that Jilles is proposing, we can look at ways to mitigate >> that. If what you're really saying is, "I want to do it the old >> way, no matter what," that's a whole different issue. > > Nah, I'm just expressing concern that existing users, as well as > existing programs, expect things a certain way and to change things > for no better than aesthetics is unwise. In the course of the > discussion, it's clear that there's more to it than that, and some > accommodation is needed... I'm glad that we're converging on something useful. >>>>> I find the additional delays from doing a shutdown -r to also >>>>> be annoying, which is why I never use them. >>>> >>>> If things are working as they should be, running rc.shutdown >>>> won't cause any delays at all vs. the brute force method used >>>> by 'shutdown'. The only time you'll see a delay is if something >>>> that's being killed actually needs it to cleanly shut down. >>> >>> halt and reboot are low level interfaces. shutdown is the >>> higher level interface that people should use. >> >> The problem is that people see the names "halt" and "reboot" and >> assume that "simpler is better" and use them. The fact that the >> proper way to reboot a FreeBSD system is 'shutdown -r' is ... just >> silly. > > Right, but this is the historical way things have been done, and > there are many existing users who have products that depend on the > difference. So the argument for change needs to be stronger. > > I think a more proper argument could be made that the times have > changed and that while it would be desirable to retain the old > interface, it is more desirable to file off the rough edges from the > crufty old interfaces to improve the user experience for the hordes > that are coming from the Linux world. Honestly, people coming over from Linux is on my RADAR. We're in a situation now where the vast majority of our new users are going to be coming from that world because they start their exposure to Unix with a Linux desktop. I'm *not* saying that we need to gratuitously do things the Linux way, but I am saying that we need to think more carefully about being user friendly in a world where most of our users are not historical BSD'ers. > Of course, if all reboot is going to do is call shutdown -r now, then > maybe it makes sense to just install a shell script called reboot and > rename the current reboot to fastreboot. At various times in the past I've proposed this exact solution. To be honest I haven't analyzed Jilles' patches in detail because I didn't want to wast time if there was no way they would go in. I'll give them another look now. >>> See my other post for a way forward, sans bogusly scary names. >> >> I've read the other messages in the thread, and I'm glad to see >> we're converging on a way forward. I don't like the names >> fast{halt|reboot} because they still sound "better" than the proper >> solutions to an unsophisticated user. My first choice would be >> something like unsafe, but I'd settle for something like old as the >> prefix. Then we can make 'reboot' do what 'shutdown -r' does, and >> 'halt' equivalent to 'shutdown -p'. > > Well, a simple alias in root's .profile could do that :) Sadly, > that's not a sufficient solution for a number of reasons. > > However, I think that we can get most of what is needed here by > tightening up the shutdown -r path, and reinventing[*] fasthalt and > fastreboot from SunOS 4.x days. Then reboot/halt could easily be a > simple shell script that invokes shutdown. This would allow the > embedded folks to replace it with fast*, while allowing the > enterprise customers a more uniform experience with their linux and > solaris systems. And the tightening up would likely cause the > developer community to not notice as much the difference, because the > artificial delays have been removed. Or to add to their > .profile/.cshrc files something along the lines of alias reboot > fastreboot. I don't like the alias route as the default solution because it's too easily circumvented, which would lead to even more user confusion. I dig the SunOS vibe you're layin' down on the good old fast* versions, but I remain concerned that by using those names we would create an even brighter flame that will attract more people than just 'halt' and 'reboot' do now. And yes, I think it's more than just aesthetics. The things that 'shutdown -*' do are things that almost all of our users actually need done. For example, I've worked pretty hard to get the shutdown KEYWORD into all of the relevant rc.d scripts in order to make sure that when rc.shutdown is run things get shut down cleanly. This has significantly reduced the number of complaints about things that have interrelated dependencies corrupting each other. Almost all of these complaints nowadays are due to someone typing 'halt' or 'reboot', and mostly in ports (where the relationships can be both more numerous and more complex). I'm have never said that the old tools should be removed, just that they should be renamed. I understand that there is a non-zero cost to this for users who will have to retool scripts and such that use the old names, *and actually need* the old behavior. But I'm confident that the net benefit of having 'halt' and 'reboot' do the right thing by default will more than make up for it. Doug > Warner > > [*] I say reinventing here because IIRC fastboot also suppressed the > full fsck of filesystems when the system is coming back up. with > zfs, ufs + suj, the clean flag short-curcuit, etc that functionality > is no longer all that useful. -- This .signature sanitized for your protection From owner-freebsd-arch@FreeBSD.ORG Thu May 17 05:54:28 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0541106566B; Thu, 17 May 2012 05:54:28 +0000 (UTC) (envelope-from BATV+8d16ce0fe61672f7c110+3189+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:4830:2446:ff00:4687:fcff:fea6:5117]) by mx1.freebsd.org (Postfix) with ESMTP id 65A938FC16; Thu, 17 May 2012 05:54:28 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.76 #1 (Red Hat Linux)) id 1SUtfN-0001Cp-Ew; Thu, 17 May 2012 05:54:25 +0000 Date: Thu, 17 May 2012 01:54:25 -0400 From: Christoph Hellwig To: Eitan Adler Message-ID: <20120517055425.GA802@infradead.org> References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: Dag-Erling Sm??rgrav , Adrian Chadd , d@delphij.net, freebsd-arch@freebsd.org Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 05:54:28 -0000 On Wed, May 16, 2012 at 06:36:18PM -0400, Eitan Adler wrote: > On 16 May 2012 18:32, Adrian Chadd wrote: > > .. what's to stop a fork() bomb from grabbing all pages? > > + possibly limiting the number of pages per user, ?? la > maxprocperuid. Linux has added a RLIMIT_MEMLOCK opcode for setrlimit that allows controlling the amount of memory users can lock down, with a default of a single page for unprivilegued processes. From owner-freebsd-arch@FreeBSD.ORG Thu May 17 09:33:05 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 858F5106566C; Thu, 17 May 2012 09:33:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1506E8FC15; Thu, 17 May 2012 09:33:04 +0000 (UTC) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4H9PUjY026214; Thu, 17 May 2012 19:25:30 +1000 Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4H9PDFq006762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 19:25:14 +1000 Date: Thu, 17 May 2012 19:25:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh In-Reply-To: Message-ID: <20120517183044.U970@besplex.bde.org> References: <20120513220646.GA12826@stack.nl> <4FB0CF88.5010309@FreeBSD.org> <3D895644-0BA5-44F7-AC8F-07323729C1AA@bsdimp.com> <4FB40506.3000300@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Doug Barton , Jilles Tjoelker , freebsd-arch@freebsd.org Subject: Re: [patch] halt/reboot/shutdown cleanup X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 09:33:05 -0000 On Wed, 16 May 2012, Warner Losh wrote: > On May 16, 2012, at 1:50 PM, Doug Barton wrote: >> The problem is that people see the names "halt" and "reboot" and assume >> that "simpler is better" and use them. The fact that the proper way to >> reboot a FreeBSD system is 'shutdown -r' is ... just silly. > > Right, but this is the historical way things have been done, and there are many existing users who have products that depend on the difference. So the argument for change needs to be stronger. Right, they can't be renamed without breaking things. Please use the unix newline character. > I think a more proper argument could be made that the times have changed and that while it would be desirable to retain the old interface, it is more desirable to file off the rough edges from the crufty old interfaces to improve the user experience for the hordes that are coming from the Linux world. Their bevaviour with the same options also can't be changed without breaking things. > Of course, if all reboot is going to do is call shutdown -r now, then maybe it makes sense to just install a shell script called reboot and rename the current reboot to fastreboot. Quick, let's rename cp to COPY and del to DELETE. > However, I think that we can get most of what is needed here by tightening up the shutdown -r path, and reinventing[*] fasthalt and fastreboot from SunOS 4.x days. Then reboot/halt could easily be a simple shell script that invokes shutdown. This would allow the embedded folks to replace it with fast*, while allowing the enterprise customers a more uniform experience with their linux and solaris systems. And the tightening up would likely cause the developer community to not notice as much the difference, because the artificial delays have been removed. Or to add to their .profile/.cshrc files something along the lines of alias reboot fastreboot. Do you mean reinventing them from FreeBSD? fastboot and fasthalt are still standard in FreeBSD, but they have been reduced to hard links to reboot. They don't even change the action of reboot(8). No one knows about them of course (not even to the extent of noticing that they are in reboot's man page), so reboot is used directly. In FreeBSD-1 and 4.4BSD-Lite, they were shell scripts that copied /dev/null to /fastboot and then invoked reboot and halt, respectively. halt(8) has also been reduced to a hard link to reboot, but now it changes the action of reboot. It is misimplemented by making its action depend on the program name but not providing an equivalent option. > [*] I say reinventing here because IIRC fastboot also suppressed the full fsck of filesystems when the system is coming back up. with zfs, ufs + suj, the clean flag short-curcuit, etc that functionality is no longer all that useful._______________________________________________ In FreeBSD, the whole point of fastboot was to suppress fsck. It was otherwise equivalent to reboot (but never to shutdown). Now it is identical with reboot except for its name. Its reason for existence is no longer documented. In 4.4BSD-Lite2, it was: % FASTBOOT(8) FreeBSD System Manager's Manual FASTBOOT(8) % % NAME % fastboot, fasthalt -- reboot/halt the system without checking the disks % % SYNOPSIS % fastboot [boot-options] % fasthalt [halt-options] % % DESCRIPTION % Fastboot and fasthalt are shell scripts which reboot and halt the system % without checking the file systems. This is done by creating a file % /fastboot, then invoking the reboot program. The system startup script, % /etc/rc, looks for this file and, if present, skips the normal invocation % of fsck(8). % % SEE ALSO % halt(8), reboot(8), rc(8) Hmm, shutdown isn't even mentioned. % % HISTORY % The fastboot command appeared in 4.2BSD. Much (?) older than SunOS. % % 4.2 Berkeley Distribution June 5, 1993 4.2 Berkeley Distribution The old shutdown(8) references fastboot but not fasthalt. shutdown -f gave fasthalt (no longer supported) and shutdown -r gave reboot(8) (at the specified type) (it now gives a more direct reboot at the specified time). I now remember why fasthalt and fastboot went away. dg added dirty flag handling, so that a full fsck is not needed in the usual case of a clean reboot, at least for ffs. For a non-clean reboot, you shouldn't tell fsck not to run even if you could, and most non-clearn reboots are for panics which couldn't run fastboot anyway. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu May 17 09:59:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74341065675; Thu, 17 May 2012 09:59:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6488FC08; Thu, 17 May 2012 09:59:55 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4H9xSqD022100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 19:59:29 +1000 Date: Thu, 17 May 2012 19:59:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Artem Belevich In-Reply-To: Message-ID: <20120517193904.X1317@besplex.bde.org> References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-102633144-1337248768=:1317" Cc: Eitan Adler , Adrian Chadd , freebsd-arch@freebsd.org, d@delphij.net, =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 09:59:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-102633144-1337248768=:1317 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 16 May 2012, Artem Belevich wrote: > On Wed, May 16, 2012 at 3:36 PM, Eitan Adler wrote= : >> On 16 May 2012 18:32, Adrian Chadd wrote: >>> .. what's to stop a fork() bomb from grabbing all pages? >> >> + possibly limiting the number of pages per user, =E0 la >> maxprocperuid. > > Shouldn't RLIMIT_NPROC already limit the damage? Products of limits are too large to actually be useful as limits in most cases. RLIMIT_NPROC usually gives the same limit as maxprocperuid. E.g., on 2 very different systems I have handy both are 5547. Then the open file limit is 11095 on the smaller system (1GB RAM) and 3000 on the larger system (2GB RAM). The product of 5507 and 11095 is > 58M. There is no way the data structures for that many files can fit in 1GB RAM. So the limit is enough for normal operation but is useless for defending against fork bombs. Even if you have a small limit on the number of pages per user and a small number of users, the product may be large, and vm needs to reserve this number of pages so that it doesn't run out when doing more-critical operations. It might be able to preserve its reservations (v_free_reserved, v_pageout_fre_min and v_interrupt_free_min) by reducing the limit on the number of locked pages for each user and all users when under pressure, but then unprivileged pages that have already grabbed and locked pages could damage privileged processes later. Bruce --0-102633144-1337248768=:1317-- From owner-freebsd-arch@FreeBSD.ORG Fri May 18 15:24:23 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2EB81065670; Fri, 18 May 2012 15:24:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 8DDC08FC0A; Fri, 18 May 2012 15:24:17 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q4IFO0Hp038306; Fri, 18 May 2012 11:24:00 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q4IFNxJf038305; Fri, 18 May 2012 11:23:59 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 18 May 2012 11:23:59 -0400 From: David Schultz To: Eitan Adler Message-ID: <20120518152359.GA38257@zim.MIT.EDU> Mail-Followup-To: Eitan Adler , Adrian Chadd , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , d@delphij.net, freebsd-arch@freebsd.org References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Adrian Chadd , d@delphij.net, freebsd-arch@FreeBSD.ORG Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 15:24:24 -0000 On Wed, May 16, 2012, Eitan Adler wrote: > On 16 May 2012 18:32, Adrian Chadd wrote: > > .. what's to stop a fork() bomb from grabbing all pages? > > + possibly limiting the number of pages per user, à la > maxprocperuid. Two other points about this: - Each process already requires a number of wired pages in the kernel, so adding a few more in userland shouldn't be a big deal. - There are plenty of ways for an unprivileged user to wedge the system if they really try. ISTR alc commenting on a similar proposal years ago; I think at the time we didn't have appropriate accounting limits or something. From owner-freebsd-arch@FreeBSD.ORG Sat May 19 13:33:09 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCDDE1065670 for ; Sat, 19 May 2012 13:33:09 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2CB8FC17 for ; Sat, 19 May 2012 13:33:09 +0000 (UTC) Received: by ggnm2 with SMTP id m2so4431446ggn.13 for ; Sat, 19 May 2012 06:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=78WQPxzLVOIMABfztwbjQEd+OOoL5wlYJQe0c05MsKw=; b=w5BC4ntIfUYeLHWtvDnAxYb8uR7gNn2BeIExvqL5W0VWceDIVTho7ehe4aOK8c59RC KiUgKSpF4um4W9uugs6VVS20jbYtqofRNQVbkD6vaVdIp2oxukpo4UAyEQZl1CAS+arP ROZjLb5Nw5CAyB+qDxFdrWBfZ0H4/Q3t9o1CFJxmhi4jphWh/jf/NXlajt8GtsURQTYs igv9s5In8IpLQq7lc210mgvliEB080x/P/RDnS1NM9rrceykAnWMimNPz5BczpkcgClg KJBUodAEMSA/Os9J0YjzOpLtoMpwQ7pKBszXbdK/74r0KA8VSjxfCkUZ3JGNgzc+PYSk 6m8g== MIME-Version: 1.0 Received: by 10.50.181.164 with SMTP id dx4mr3184654igc.1.1337434383306; Sat, 19 May 2012 06:33:03 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.202.84 with HTTP; Sat, 19 May 2012 06:33:03 -0700 (PDT) Date: Sat, 19 May 2012 15:33:03 +0200 X-Google-Sender-Auth: fxfRREXNvqvKr-GCqaykrvFtqaA Message-ID: From: Robert Millan To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 13:33:09 -0000 "struct bintime" is enabled only by __BSD_VISIBLE. However, there are a few headers that use "struct bintime" without __BSD_VISIBLE: sys/arm/include/cpu.h sys/dev/iscsi/initiator/iscsivar.h sys/geom/journal/g_journal.h sys/sys/dtrace_bsd.h sys/sys/devicestat.h sys/sys/timeet.h sys/sys/bio.h sys/opencrypto/cryptodev.h Should the definitions that use "struct bintime" be __BSD_VISIBLE too? Or maybe "struct bintime" be defined unconditionally? Or perhaps we could have "struct __bintime" and use that for system headers? -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Sat May 19 13:40:10 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6591C106564A; Sat, 19 May 2012 13:40:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BCE878FC12; Sat, 19 May 2012 13:40:09 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q4JDe628092431; Sat, 19 May 2012 16:40:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q4JDe5X9099174; Sat, 19 May 2012 16:40:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q4JDe5WI099173; Sat, 19 May 2012 16:40:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 May 2012 16:40:05 +0300 From: Konstantin Belousov To: Robert Millan Message-ID: <20120519134005.GJ2358@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A/JKaSqKPqQLCbw0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 13:40:10 -0000 --A/JKaSqKPqQLCbw0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 19, 2012 at 03:33:03PM +0200, Robert Millan wrote: > "struct bintime" is enabled only by __BSD_VISIBLE. However, there are > a few headers that use "struct bintime" without __BSD_VISIBLE: >=20 > sys/arm/include/cpu.h > sys/dev/iscsi/initiator/iscsivar.h > sys/geom/journal/g_journal.h > sys/sys/dtrace_bsd.h > sys/sys/devicestat.h > sys/sys/timeet.h > sys/sys/bio.h > sys/opencrypto/cryptodev.h >=20 > Should the definitions that use "struct bintime" be __BSD_VISIBLE too? > Or maybe "struct bintime" be defined unconditionally? >=20 > Or perhaps we could have "struct __bintime" and use that for system heade= rs? Note that all headers you listed are kernel headers, and kernel is exposed to the whole namespace. I suspect that no headers are supposed to be used by usermode among the list. --A/JKaSqKPqQLCbw0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+3orUACgkQC3+MBN1Mb4htWwCeJV9AuH/VdC4OzaZlZSxg8cx8 vAkAnRG0joEKCMYHhJpai0ROGv79nXUQ =5ZIi -----END PGP SIGNATURE----- --A/JKaSqKPqQLCbw0-- From owner-freebsd-arch@FreeBSD.ORG Sat May 19 13:52:44 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2CD31065670; Sat, 19 May 2012 13:52:44 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id ACEA08FC1B; Sat, 19 May 2012 13:52:44 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 9B04D13F43; Sat, 19 May 2012 13:52:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q4JDqa7P014165; Sat, 19 May 2012 13:52:36 GMT (envelope-from phk@phk.freebsd.dk) To: Konstantin Belousov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 19 May 2012 16:40:05 +0300." <20120519134005.GJ2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 19 May 2012 13:52:36 +0000 Message-ID: <14164.1337435556@critter.freebsd.dk> Cc: freebsd-arch@freebsd.org, Robert Millan Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 13:52:45 -0000 In message <20120519134005.GJ2358@deviant.kiev.zoral.com.ua>, Konstantin Belous ov writes: >> Or maybe "struct bintime" be defined unconditionally? I think this is the best/right way to go. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat May 19 15:39:57 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08E41065670; Sat, 19 May 2012 15:39:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id E9F5E8FC0C; Sat, 19 May 2012 15:39:56 +0000 (UTC) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4JFdnU0029284; Sun, 20 May 2012 01:39:49 +1000 Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4JFdd79012859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 May 2012 01:39:42 +1000 Date: Sun, 20 May 2012 01:39:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp In-Reply-To: <14164.1337435556@critter.freebsd.dk> Message-ID: <20120520004236.D1313@besplex.bde.org> References: <14164.1337435556@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , Robert Millan , freebsd-arch@freebsd.org Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 15:39:57 -0000 On Sat, 19 May 2012, Poul-Henning Kamp wrote: > In message <20120519134005.GJ2358@deviant.kiev.zoral.com.ua>, Konstantin Belous > ov writes: > >>> Or maybe "struct bintime" be defined unconditionally? > > I think this is the best/right way to go. Not permitted. Exposing struct bintime also exposes its internal pollution (see below). sys/time.h is still massively polluted in other ways: % #ifndef _SYS_TIME_H_ % #define _SYS_TIME_H_ % % #include % #include Not permitted in POSIX.1, at least in the 2001 version (except all _t names from here are permitted). Only (all of the) pollution from including is permitted. % #include This only gives the undocumented pollution TIMESPEC_TO_TIMEVAL() and TIMEVAL_TO_TIMESPEC() (only under __BSD_VISIBLE). % % struct timezone { % int tz_minuteswest; /* minutes west of Greenwich */ % int tz_dsttime; /* type of dst correction */ % }; % #define DST_NONE 0 /* not on dst */ % #define DST_USA 1 /* USA style dst */ % #define DST_AUST 2 /* Australian style dst */ % #define DST_WET 3 /* Western European dst */ % #define DST_MET 4 /* Middle European dst */ % #define DST_EET 5 /* Eastern European dst */ % #define DST_CAN 6 /* Canada */ This compatibility cruft isn't even under __BSD_VISIBLE. % % #if __BSD_VISIBLE % struct bintime { % time_t sec; % uint64_t frac; % }; __BSD_VISIBLE exposes bintime and thus necessarily the namespace pollution in its API: field names 'sec' and 'frac'. % % static __inline void % bintime_addx(struct bintime *bt, uint64_t x) % { % uint64_t u; __BSD_VISIBLE exposes bintime and thus unnecessarily the namespace pollution in its implementation: parameter names 'bt' and 'x', and local variable name 'u'. 'x' and 'u' are vey popular application names. Though applications shouldn't use them in the global namespace in a way they would conflict with these, they might. % % u = bt->frac; % bt->frac += x; % if (u > bt->frac) % bt->sec++; % } % % static __inline void % bintime_add(struct bintime *bt, const struct bintime *bt2) % { % uint64_t u; % % u = bt->frac; % bt->frac += bt2->frac; % if (u > bt->frac) % bt->sec++; % bt->sec += bt2->sec; % } % % static __inline void % bintime_sub(struct bintime *bt, const struct bintime *bt2) % { % uint64_t u; % % u = bt->frac; % bt->frac -= bt2->frac; % if (u < bt->frac) % bt->sec--; % bt->sec -= bt2->sec; % } % % static __inline void % bintime_mul(struct bintime *bt, u_int x) % { % uint64_t p1, p2; % % p1 = (bt->frac & 0xffffffffull) * x; % p2 = (bt->frac >> 32) * x + (p1 >> 32); % bt->sec *= x; % bt->sec += (p2 >> 32); % bt->frac = (p2 << 32) | (p1 & 0xffffffffull); % } Just a few more polluting parameter and variable names. % % #define bintime_clear(a) ((a)->sec = (a)->frac = 0) % #define bintime_isset(a) ((a)->sec || (a)->frac) % #define bintime_cmp(a, b, cmp) \ % (((a)->sec == (b)->sec) ? \ % ((a)->frac cmp (b)->frac) : \ % ((a)->sec cmp (b)->sec)) This can be made to blow up more confusingly than the inlines by user definitions of frac and sec. % % /*- % * Background information: % * % * When converting between timestamps on parallel timescales of differing % * resolutions it is historical and scientific practice to round down rather % * than doing 4/5 rounding. % * % * The date changes at midnight, not at noon. % * % * Even at 15:59:59.999999999 it's not four'o'clock. % * % * time_second ticks after N.999999999 not after N.4999999999 % */ No comment. % % static __inline void % bintime2timespec(const struct bintime *bt, struct timespec *ts) % { % % ts->tv_sec = bt->sec; % ts->tv_nsec = ((uint64_t)1000000000 * (uint32_t)(bt->frac >> 32)) >> 32; % } % % static __inline void % timespec2bintime(const struct timespec *ts, struct bintime *bt) % { % % bt->sec = ts->tv_sec; % /* 18446744073 = int(2^64 / 1000000000) */ % bt->frac = ts->tv_nsec * (uint64_t)18446744073LL; % } % % static __inline void % bintime2timeval(const struct bintime *bt, struct timeval *tv) % { % % tv->tv_sec = bt->sec; % tv->tv_usec = ((uint64_t)1000000 * (uint32_t)(bt->frac >> 32)) >> 32; % } % % static __inline void % timeval2bintime(const struct timeval *tv, struct bintime *bt) % { % % bt->sec = tv->tv_sec; % /* 18446744073709 = int(2^64 / 1000000) */ % bt->frac = tv->tv_usec * (uint64_t)18446744073709LL; % } Yet more parameter names in the application namespace. % #endif /* __BSD_VISIBLE */ % % #ifdef _KERNEL % ... [few problems since this is private] % #endif /* _KERNEL */ % % #ifndef _KERNEL /* NetBSD/OpenBSD compatible interfaces */ This was intentionally left out of the kernel. % % #define timerclear(tvp) ((tvp)->tv_sec = (tvp)->tv_usec = 0) % #define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec) % #define timercmp(tvp, uvp, cmp) \ % (((tvp)->tv_sec == (uvp)->tv_sec) ? \ % ((tvp)->tv_usec cmp (uvp)->tv_usec) : \ % ((tvp)->tv_sec cmp (uvp)->tv_sec)) % #define timeradd(tvp, uvp, vvp) \ % do { \ % (vvp)->tv_sec = (tvp)->tv_sec + (uvp)->tv_sec; \ % (vvp)->tv_usec = (tvp)->tv_usec + (uvp)->tv_usec; \ % if ((vvp)->tv_usec >= 1000000) { \ % (vvp)->tv_sec++; \ % (vvp)->tv_usec -= 1000000; \ % } \ % } while (0) % #define timersub(tvp, uvp, vvp) \ % do { \ % (vvp)->tv_sec = (tvp)->tv_sec - (uvp)->tv_sec; \ % (vvp)->tv_usec = (tvp)->tv_usec - (uvp)->tv_usec; \ % if ((vvp)->tv_usec < 0) { \ % (vvp)->tv_sec--; \ % (vvp)->tv_usec += 1000000; \ % } \ % } while (0) % #endif Now it's massive sideways compatibility cruft. % % /* % * Names of the interval timers, and structure % * defining a timer setting. % */ % #define ITIMER_REAL 0 % #define ITIMER_VIRTUAL 1 % #define ITIMER_PROF 2 % % struct itimerval { % struct timeval it_interval; /* timer interval */ % struct timeval it_value; /* current value */ % }; Now standard in POSIX, but missing ifdefs for old-POSIX. % % /* % * Getkerninfo clock information structure % */ % struct clockinfo { % int hz; /* clock frequency */ % int tick; /* micro-seconds per hz tick */ % int spare; % int stathz; /* statistics clock frequency */ % int profhz; /* profiling clock frequency */ % }; More FreeBSD features not under __BSD_VISIBLE. % % /* These macros are also in time.h. */ % #ifndef CLOCK_REALTIME % #define CLOCK_REALTIME 0 % #define CLOCK_VIRTUAL 1 % #define CLOCK_PROF 2 % #define CLOCK_MONOTONIC 4 % #define CLOCK_UPTIME 5 /* FreeBSD-specific. */ % #define CLOCK_UPTIME_PRECISE 7 /* FreeBSD-specific. */ % #define CLOCK_UPTIME_FAST 8 /* FreeBSD-specific. */ % #define CLOCK_REALTIME_PRECISE 9 /* FreeBSD-specific. */ % #define CLOCK_REALTIME_FAST 10 /* FreeBSD-specific. */ % #define CLOCK_MONOTONIC_PRECISE 11 /* FreeBSD-specific. */ % #define CLOCK_MONOTONIC_FAST 12 /* FreeBSD-specific. */ % #define CLOCK_SECOND 13 /* FreeBSD-specific. */ % #define CLOCK_THREAD_CPUTIME_ID 14 % #endif % % #ifndef TIMER_ABSTIME % #define TIMER_RELTIME 0x0 /* relative timer */ % #define TIMER_ABSTIME 0x1 /* absolute timer */ % #endif Not permitted here in POSIX I think. Only permitted in in POSIX. Part of the bad layering of time.h and sys/time.h in FreeBSD. Of course the kernel needs these too, but it can't get them from sys/time.h according to POSIX, so it should put them in a smaller common header. FreeBSD uses 2-3 layers of timespec.h and timeval.h headers to do much less. The FreeBSD extensions could be ifdefed like the signal macros are, but this is not required. % % #ifdef _KERNEL % ... % #else /* !_KERNEL */ % #include Gross pollution. The worst part of the bad layering. % % #include Really silly to include this again, after including it already about 20 times counting nesting. % #include Most of this is required by POSIX and all of it is allowed (assuming that select.h doesn't have any pollution, and it has no obvious pollution, unlike the above). % % __BEGIN_DECLS % int setitimer(int, const struct itimerval *, struct itimerval *); % int utimes(const char *, const struct timeval *); % % #if __BSD_VISIBLE % int adjtime(const struct timeval *, struct timeval *); % int futimes(int, const struct timeval *); % int futimesat(int, const char *, const struct timeval [2]); % int lutimes(const char *, const struct timeval *); % int settimeofday(const struct timeval *, const struct timezone *); % #endif % % #if __XSI_VISIBLE % int getitimer(int, struct itimerval *); % int gettimeofday(struct timeval *, struct timezone *); % #endif At least setitimer() and gettimeofday() in the above aren't actually XSI compatible, since the XSI version has some restrict qualifiers in it. Exposing bintime and other pollution bogotifiles the careful ifdefs in some parts of the file. % % __END_DECLS % % #endif /* !_KERNEL */ % % #endif /* !_SYS_TIME_H_ */ Bruce From owner-freebsd-arch@FreeBSD.ORG Sat May 19 18:30:53 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33B8A106564A; Sat, 19 May 2012 18:30:53 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E13338FC08; Sat, 19 May 2012 18:30:52 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DCE8213E71; Sat, 19 May 2012 18:30:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q4JIUngI015088; Sat, 19 May 2012 18:30:50 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 20 May 2012 01:39:39 +1000." <20120520004236.D1313@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 19 May 2012 18:30:49 +0000 Message-ID: <15087.1337452249@critter.freebsd.dk> Cc: Konstantin Belousov , freebsd-arch@freebsd.org, Robert Millan Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:30:53 -0000 In message <20120520004236.D1313@besplex.bde.org>, Bruce Evans writes: >On Sat, 19 May 2012, Poul-Henning Kamp wrote: >>>> Or maybe "struct bintime" be defined unconditionally? >> >> I think this is the best/right way to go. > >Not permitted. >sys/time.h is still massively polluted in other ways: > [...] >Not permitted in POSIX.1, [...] I think at this time, we can either religiously stick to POSIX and become irellevant with it, or we can develop our APIs to become useful and desirable, and have a chance to survive. Strictly 1980-compatible APIs will not gain FreeBSD 10+ any new users. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat May 19 18:53:48 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D09110656B9; Sat, 19 May 2012 18:53:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1088FC18; Sat, 19 May 2012 18:53:48 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4JIoOkc006929 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 19 May 2012 12:50:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <15087.1337452249@critter.freebsd.dk> Date: Sat, 19 May 2012 12:50:24 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <15087.1337452249@critter.freebsd.dk> To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 19 May 2012 12:50:26 -0600 (MDT) Cc: Konstantin Belousov , Robert Millan , freebsd-arch@FreeBSD.org Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:53:48 -0000 On May 19, 2012, at 12:30 PM, Poul-Henning Kamp wrote: > In message <20120520004236.D1313@besplex.bde.org>, Bruce Evans writes: >> On Sat, 19 May 2012, Poul-Henning Kamp wrote: > >>>>> Or maybe "struct bintime" be defined unconditionally? >>> >>> I think this is the best/right way to go. >> >> Not permitted. > >> sys/time.h is still massively polluted in other ways: >> [...] >> Not permitted in POSIX.1, [...] > > I think at this time, we can either religiously stick to POSIX > and become irellevant with it, or we can develop our APIs to > become useful and desirable, and have a chance to survive. Doesn't __BSD_VISIBLE do just that? Warner > Strictly 1980-compatible APIs will not gain FreeBSD 10+ any > new users. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Sat May 19 18:56:08 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25B53106564A; Sat, 19 May 2012 18:56:08 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D2E9A8FC0C; Sat, 19 May 2012 18:56:07 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 8A6CD13E71; Sat, 19 May 2012 18:56:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id q4JIu51R015188; Sat, 19 May 2012 18:56:06 GMT (envelope-from phk@phk.freebsd.dk) To: Warner Losh From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 19 May 2012 12:50:24 CST." Content-Type: text/plain; charset=ISO-8859-1 Date: Sat, 19 May 2012 18:56:05 +0000 Message-ID: <15187.1337453765@critter.freebsd.dk> Cc: Konstantin Belousov , freebsd-arch@FreeBSD.org, Robert Millan Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 18:56:08 -0000 In message , Warner Losh write s: >> I think at this time, we can either religiously stick to POSIX >> and become irellevant with it, or we can develop our APIs to >> become useful and desirable, and have a chance to survive. > >Doesn't __BSD_VISIBLE do just that? That was not my impression, but I may be wrong on that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sat May 19 22:15:38 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C26BB106566C; Sat, 19 May 2012 22:15:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3858FC0A; Sat, 19 May 2012 22:15:37 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4JMFMw9018504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 May 2012 08:15:24 +1000 Date: Sun, 20 May 2012 08:15:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh In-Reply-To: Message-ID: <20120520072600.R2693@besplex.bde.org> References: <15087.1337452249@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , Poul-Henning Kamp , Robert Millan , freebsd-arch@FreeBSD.org Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 22:15:38 -0000 On Sat, 19 May 2012, Warner Losh wrote: > On May 19, 2012, at 12:30 PM, Poul-Henning Kamp wrote: > >> In message <20120520004236.D1313@besplex.bde.org>, Bruce Evans writes: >>> On Sat, 19 May 2012, Poul-Henning Kamp wrote: >> >>>>>> Or maybe "struct bintime" be defined unconditionally? >>>> >>>> I think this is the best/right way to go. >>> >>> Not permitted. >> >>> sys/time.h is still massively polluted in other ways: >>> [...] >>> Not permitted in POSIX.1, [...] >> >> I think at this time, we can either religiously stick to POSIX >> and become irellevant with it, or we can develop our APIs to >> become useful and desirable, and have a chance to survive. > > Doesn't __BSD_VISIBLE do just that? Not when it is not even used. >> Strictly 1980-compatible APIs will not gain FreeBSD 10+ any >> new users. The POSIX.1-1990 support may be unimportant, but is the easiest part of visibility limiting, since POSIX.1-1990 is a subset of everything (except pure STDC (C90) which is even smaller). __BSD_VISIBLE ifdefs support it automatically for all FreeBSD extensions that are not in any version of POSIX. It's the ifdefs for later POSIX versions that are more complicated, or would be if they all existed. now has - only 195 lines matching _VISIBLE - 33 of these are in cdefs.h just to define all the visibility macros - 117 of the remaining the others match __BSD_VISIBLE - only 45 others (mainly with __POSIX_VISIBLE and __XSI_VISIBLE - a whole 7 of these 45 match 1993 and a whole 14 of the 45 match 2001. POSIX grew from ~356 pages in 1990 to 3600 pages in 2001 (d7.pdf draft; it now covers utilities). The new and changed interfaces can't be expressed by 7+14 ifdefs. After 2001, it only grew to 3790 pages in a 2007 draft. FreeBSD doesn't have any ifdefs to express the 2001-2007 changes (I think there were no POSIX.1 standards releases in this period), but it have a whole 5 new ifdefs for the 2008 version. Functions like futimes() are newer still (not in any POSIX.1 released standard) but are under a __BSD_VISIBLE ifdef. Bruce