At Mon, 1 Feb 2021 19:30:47 -0700, Warner Losh wrote: Subject: Re: [TUHS] reboot(2) system call > > Would be nice to know which one so I can go check. I've not seen leaked > xenix code though, so it may be possible. Well the first versions I used were on 286 machines, and then 386. I think there may be binaries available in the darker corners (maybe even on archive.org) if one wanted to test empirically on either emulation or real hardware. Maybe someday I could do that, but not soon. On a related note, one of the weird things about Unix System V, from the beginning more or less, and right up to and including the last SysVr4, the shutdown scripts use "sync; sync; sync" all on one line like that (on r4 they use the full path to "/sbin/sync", but still three times). I think on some versions the subsequent call will block briefly while the first call finishes scheduling buffer writes (i.e. the call will wait instead of just returning if another process is in the critical section), they all still just schedule async writes. If I'm not mistaken though calling "sync" in any way at all shouldn't normally be necessary during a proper shutdown as all filesystems, including the root fs, will be unmounted during the process, thus forcing all dirty buffers to be flushed first, and this is in fact the case from SysVr3 and on (i.e. after uadmin(2) with A_SHUTDOWN was introduced). Also, on SysVr4 the fsflush daemon runs as a kernel daemon process, so if I understand correctly it isn't killed during shutdown or in single user mode, thus it'll still be doing the equivalent of sync(2) right up to the end. On the other hand in the particular SysVr4-i386 version I have the code that would actually wait for all async buffer writes during umounts, i.e. in bdwait(), is commented out and replaced by a "delay(200)". I can't imagine why, nor can I imagine trying to debug that without source! -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms