Date: Mon, 27 Jul 1998 15:09:08 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: David Wolfskill <dhw@whistle.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM Message-ID: <Pine.BSF.3.96.980727150834.14161C-100000@bright.ny.otec.com> In-Reply-To: <199807271745.KAA25470@pau-amma.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
/var/run/dmesg.boot (this is on -current dunno about -stable) -Alfred On Mon, 27 Jul 1998, David Wolfskill wrote: > [Original exchange from -questions; I think what I'm going on about is > rather more -hackerish, so that's where this is. dhw] > > >Date: Mon, 27 Jul 1998 15:36:56 +0100 > >From: Adam Nealis <adamn@criterion.canon.co.uk> > > >> Could someone tell me how you can check the amount of RAM both available > >> and in use at a given time on FreeBSD 2.2.6 ? > > >Try > > >dmesg | more > > >soon after a reboot. Should tell you how much RAM was found on the way up. > > Well, re-booting a production server that's been up for several months > just to find out how much real memory the kernel saw may not be a viable > option. :-} Granted, someone else suggested "top", which is fine for > this particular resource.... > > However, as a follow-on to a discussion I was having with someone else > (where I was doing a bunch of whining about the challenges I was having > in "automatically" being able to determine the configuration of a given > FreeBSD box), the random idea came up that *IF* the kernel could stash > away the results of its probing in some way that might be amenable to > access by suitably-privileged processes at times arbitrarily distant > from re-boot (i.e, scannning logs & output of dmesg won't do the job), > this *might* be sufficiently useful to warrant some effort. > > I suppose that one way to do a hack that could be adequate for a trial > run would be to have /etc/rc run a script that would run "dmesg" & parse > it, then stuff the results of this parsing into a file that could be > read by a process running under effective GID "operator". > > The objective would be to record enough information that given the > (properly-interpreted) content of the file in question, it would be > possible to specify the components to re-construct the machine in > question. > > In turn, the reason for this is for "disaster recovery preparedness". > > Does this seem as if it might possibly be of use to anyone else? > > Thanks, > david > -- > David Wolfskill UNIX System Administrator > dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980727150834.14161C-100000>