From owner-freebsd-hackers Mon Jul 27 12:09:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17415 for freebsd-hackers-outgoing; Mon, 27 Jul 1998 12:09:34 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.ny.otec.com (bright.ny.otec.com [209.3.16.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA17280 for ; Mon, 27 Jul 1998 12:08:51 -0700 (PDT) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.ny.otec.com (8.8.8/8.8.8) with SMTP id PAA18623; Mon, 27 Jul 1998 15:09:08 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.ny.otec.com: bright owned process doing -bs Date: Mon, 27 Jul 1998 15:09:08 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.ny.otec.com To: David Wolfskill cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM In-Reply-To: <199807271745.KAA25470@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /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 > > >> 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