On Mon, Jun 14, 2004 at 09:35:24AM -0700, Justin Walker scratched on the wall:
On Jun 14, 2004, at 8:11, Jay A. Kreibich wrote:
On Jun 7, 2004, at 21:56, Jay A. Kreibich wrote:
I have a fairly simple question, but I need a very sure answer.
If close(2) is called on the last file descriptor that references
a standard file, are dirty pages associated with that file's buffers
automatically queued for writing, in a similar manor to sync(2)?
As I re-read the question, I realize it might not be clear, but my
question is explicitly about the behavior of close(2). I can't
depend on update(8), as it is killed by init when it drops the system
into single user mode. Yes, I know the docs imply it shouldn't be,
but it is. So I need to depend on the close(2) call to queue the
dirty pages for writing.
The point of being in single-user mode is that nothing happens
without your executing it directly. There should be no 'background'
jobs running, including 'update'.
But the way you get into single user mode is that init issues a kill(2) with a PID of -1. According to the kill(2) man page this causes "the signal is sent to all processes excluding system processes and the process sending the signal." In truth, it kills EVERYTHING except init (the process sending the signal). That includes somewhat useful processes like mach_init (PID=2), without which the OS is, shall we say, somewhat limited. The "single user mode" you get on boot, and the "single user mode" you get via a SIGTERM to init(1) are two different things.
I also can't sync(1) manually after the system is in single user
mode because init will kill my script, as well as everything else.
Can you make your process sensitive to the shutdown protocol (catch
SIGTERM) and do the close at that point?
Yes. init(2) sends SIGHUPs, SIGTERMs, and finally SIGKILLs to each process before the transition, but it does not call sync(2) itself. I'm assuming the stuff running is written well enough to catch the HUP or TERM correctly and shut themselves down. Even if they aren't, the kernel should clean up after the processes and close(2) all the active file descriptors for each process. Reacting to the SIGHUP is likely to generate dirty buffer pages that need to be written to disk, however, only now update(8) isn't running. For example, if the software is smart enough to check-point, it is very likley to generate I/O, which will dirty pages that need to get written out before I remove power. Hence, the quesiton on if close(2) will take care of the dirty work. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. <http://www.uiuc.edu/~jak> | University of Illinois at U/C _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.