> On Thu, 13 Dec 2007, Richard L. Hamilton wrote: > > > Sometimes a large system, despite precautions (or > in the absence of them), > > runs out of resources (VM, mainly) to the degree > that no useful progress > > is being made: that is, one can't even log in and > kill the hogging processes. > > > > (At least on SPARC) the usual workaround would be > to break to the boot PROM > > and sync; however, this invariably causes a crash > dump to be taken. In the > > Workaround: > > If you have "obpdebug" defined, you can do: > > dumpvp 0 x!; sync > at the ok prompt to force skipping the dump.
Thanks - _that's_ the sort of thing I was looking for; although it presupposes that obpdebug support is loaded, which I suppose it usually isn't by default. > You could also force it to "don't do it" via > /etc/system: > > set dump_timeout=0 > There are probably a few more undocumented variables > to achieve similar. That doesn't help me - most of the time, I may want a kernel crash dump; heck, most of the time I may want one even from a OpenBoot "sync". Just those times that I already know (a) what the likely cause of the problem was and (b) that it's going to take a long time to take the dump - _those_ are the times I want to supress it, and since interacting with the OS is impossible at that point, the choice necessarily has to be communicated from the OpenBoot prompt. > It's really a question of preference. A "sync > --nodump" would only benefit > SPARC; one could argue that SPARC-only features are > so last millenium. And > one could ask "why don't you just 'boot' instead of > 'sync' then". Because I'd really rather the buffers got flushed, to minimize data loss? Great if everything was on zfs (and great to ignore SPARC-specific features if you live your life only on x86, I guess). But guess what? Installed base tends to _be_ mostly last millenium. Maybe cheap x86 boxes get replaced every 5 years or less, but big iron tends to stick around a little longer... This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
