From owner-freebsd-hackers Mon Jul 27 13:04:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA26373 for freebsd-hackers-outgoing; Mon, 27 Jul 1998 13:04:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA26327 for ; Mon, 27 Jul 1998 13:04:18 -0700 (PDT) (envelope-from ian@gamespot.com) Received: from localhost (ian@localhost) by mail.gamespot.com (8.9.0/8.9.0) with SMTP id NAA07147; Mon, 27 Jul 1998 13:03:11 -0700 (PDT) Date: Mon, 27 Jul 1998 13:03:11 -0700 (PDT) From: Ian Kallen 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 While it might indeed be useful to fetch the last reboot's dmesg output (stuff it into /var/log/dmesg.reboot or something), you can get the physical ram from "sysctl hw.physmem" -Ian On Mon, 27 Jul 1998, David Wolfskill wrote: :>> 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? -- We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message