From owner-freebsd-hackers Mon Jul 27 10:47:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA29233 for freebsd-hackers-outgoing; Mon, 27 Jul 1998 10:47:51 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA29210 for ; Mon, 27 Jul 1998 10:47:39 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.8/8.8.7) id KAA25470 for freebsd-hackers@freebsd.org; Mon, 27 Jul 1998 10:45:50 -0700 (PDT) (envelope-from dhw) Date: Mon, 27 Jul 1998 10:45:50 -0700 (PDT) From: David Wolfskill Message-Id: <199807271745.KAA25470@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM In-Reply-To: <35BC9088.D189FAEF@csl.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [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