Date: Sat, 28 Sep 2002 23:33:21 +0200 (CEST) From: Oliver Fromme <olli@secnetix.de> To: freebsd-questions@FreeBSD.ORG Subject: Re: How to shut down cleanly by killing power Message-ID: <200209282133.g8SLXLKu098478@lurza.secnetix.de> In-Reply-To: <a05111b0bb9ba664541e1@[192.168.0.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
Petri Riihikallio <Petri.Riihikallio@metis.fi> wrote: > > "sync" is pretty much useless, it doesn't buy you anything. > > Particularly, it won't mark your filesystems clean (so fsck > > will still have to run on the next boot), and it does not > > guarantee that there's no unwritten data left in memory. > > Yes, this I found out by testing. Still many shutdown scripts include > "sync ; sync ; sync" as a mantra. That should not have any effect. At least on FreeBSD. Maybe people are used to the sync command if they come from Linux, where it might be more important because of the fragile filesystems (ext2 async by default). > 'man rc' says just: "The scripts within each directory are executed > in lexicographical order." I know the source IS the doc, but it is so > slow way to find something, when you don't know what your looking for. The manpage seems to be a bit lacking in that case. The scripts are indeed executed in _reverse_ lexico- graphical order during shutdown (which makes sense, I think). Another important thing which is not clearly documented (as far as I know) is the fact that the scripts will NOT be executed when you use halt(8) or reboot(8). They will only be executed when you use shutdown(8) (without the -o option) or init(8), or when sending a signal to the running instance of init(8) to bring down the system. > > umount -f -A > > mount -u -o ro / > > mount -o ro /usr > > OK. Any need for 'mount -f -u -o ro /' ? (The -f forces the switch to > ro even if files are open for writing) Yes indeed. I suggest the following: mount -u -o ro / || mount -f -u -o ro / So it will first try to re-mount it normally, and only if that fails, retry it "the hard way". > Is there any reason to signal the system daemon processes (syslog, > sshd, adjkrntz & co)? Good question. They will be killed anyway during shutdown. On the other hand, some daemons might want to do some clean-up work which requires writing someting somewhere, so it's probably a good idea to give them a chance to do that. This is what init does when terminating multi-user operation. Something like this: trap "" 15 kill -TERM -1 sleep 10 # give them some time to finish cleaning up There is no need to send a SIGKILL (-9) afterwards, because the processes will die anyway, later in the game. And since it is not possible to trap SIGKILL, they cannot bind any clean-up actions to that signal anyway. > The Linux scripts do this with killall5. It sends a signal to all > processes except the processes in its own session, so it won't > kill the shell that is running the script it was called from. If you put the above at the end of /etc/rc.shutdown, the "trap" command will protect the shell. The parent of the shell is init(8) itself, which is never affected by a kill of -1, as well as processes which are marked as "system" processes (e.g. swapper, pagedaemon, vinum). > > That's documented in /usr/src/sbin/init/init.c. > > :-] "The source IS the doc" > > I studied /usr/src/sys/kern/kern_shutdown.c but I couldn't find where > the scripts were called. It is init calling the scripts and then > calling kern_shutdown. To be more exact: When init(8) receives a shutdown signal, it runs the /etc/rc.shutdown script, which in turn executes all the local start/stop scripts as explained above. When the scripts are done (I think up to a maximum of 120 seconds), init kills all processes -- first with SIGTERM, and if there are still some left after some time, with SIGKILL. Afterwards, init(8) either enters single-user mode or gives control to the reboot(2) system call, depending on which signal it got in the first place. At this point, it does not care anymore if any reluctant processes are still left, because they will never be scheduled again, because the kernel will never return from the reboot(2) system call. It finally syncs and unmounts all remaining file systems and brings the hardware down. Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209282133.g8SLXLKu098478>