From owner-freebsd-questions@FreeBSD.ORG Thu Jan 10 19:40:48 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6EB16A418 for ; Thu, 10 Jan 2008 19:40:48 +0000 (UTC) (envelope-from ryallsd@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id B2C8D13C44B for ; Thu, 10 Jan 2008 19:40:48 +0000 (UTC) (envelope-from ryallsd@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1373488waf.3 for ; Thu, 10 Jan 2008 11:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bhlGamixGx6lXwTHZbp5hRcbB+05NmtTrie3WHr3wcM=; b=Adl4CzonTkI62T/FSFRfoWPGpJnnGXinbAGxQ6YSU/NkfwWsv2TBIyE/Cu53frvs1XRo0eCb3HE80Gt1vowwW89nL7pr72IqUSUL4dt7bMFjvkwNBlkrG7g/cfc1nVELtF42Py9kUM/0oPgmCGWYuCXuOwtMlvRpJOG6lm6neuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GzY1J23in/eCeAk1YUovJbjzJYvSuuEr9yCH92stjyPL0zAKHpY+v+17Oujxb53GQcNv+ExN30lTrTVGrpI2RK0/cuWwr+YsIefFFxO+ZHaem/x2f7xTkfctjbqcyslSFtjTv3q2YqUrrXQhDVsuyJlnTVTFJBNtsB/1bXb0GEU= Received: by 10.114.156.1 with SMTP id d1mr2668669wae.68.1199994047992; Thu, 10 Jan 2008 11:40:47 -0800 (PST) Received: by 10.115.76.18 with HTTP; Thu, 10 Jan 2008 11:40:47 -0800 (PST) Message-ID: Date: Thu, 10 Jan 2008 11:40:47 -0800 From: "Derrick Ryalls" To: "Derek Ragona" In-Reply-To: <6.0.0.22.2.20080110025841.023a9bb8@mail.computinginnovations.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6.0.0.22.2.20080110025841.023a9bb8@mail.computinginnovations.com> Cc: FreeBSD Questions Subject: Re: Nut and RAID on FreeBSD 7.0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 19:40:49 -0000 > > Greetings, > > I have a RAID fileserver plugged into a UPS and nut is able to > communicate with it successfully. With the winds making the lights > flicker, I started looking into having the computer shut down when > power goes out for more than say 5 minutes or so. Looking at the > documentation, I found that the 'true' solution is more like the > system goes into a safe state when the battery gets low, then the ups > eventually dies. When power is restored, the UPS and computer are > supposed to both come back to life. This would be a great system to > have in place, but it does sound a bit risky and so may not be worth > doing just to save my home fileserver. > > The instructions and the conf file have the shutdown command of > 'shutdown -h +0' which will halt the system. The man page for halt > says the the disk cache will be flushed, but doesn't mention anything > about going to read-only or anything. I suppose my first question is > whether or not flushing the cache is sufficient to save the RAID (5) > array, or if I need to find a way to get the file systems into read > only mode? > > The second question has to do with a rc.d script that nut recommends > creating. The script does a 'upsdrvctl shutdown' and then a sleep > 120, basically waiting for the machine to die while in the script. > Won't this block the other rc.d scripts? Also, is this the magic part > that enables the machine to auto power up when power is restored? > > Changing the shutdown command in nut to 'shutdown -p +0' looks like > the sure fire way to get the system down clean before the power is > lost, but if my concerns are not valid, then I could be missing out on > some nice functionality for no reason. > > Does anyone have experience with this? > I have my servers all using nut to safely shutdown. My configuration is > the servers are set up with one as master for nut, that master connected to > the UPS. The other servers are slaves and get their nut information from > the master. > > My setup has the servers wait until the UPS is on low battery, then they > all shutdown. > > As a separate part of the setup, the servers are set in their BIOS to power > on, after a power failure. This is in the BIOS power setup. > > So if there is a minor power problem, the servers run from battery. In a > larger power outage, they are shutdown cleanly once the battery level is > low, and power up automatically once power is restored. > > In my upsmon.conf file I have this: > SHUTDOWNCMD "/sbin/shutdown -h +0" > > If you want more specifics, I can look through the configuration files and > email you relevant settings. > After doing more reading, I am confident that a shutdown -h would be sufficient, but am a bit concern on the order of operations. The nut documentation has a recommendation to add a kill script as such: #!/bin/sh if [ "$1" == "stop" ] then if [ -f /etc/killpower ] then echo "Killing the power, bye!" /usr/local/libexec/nut/upsdrvctl shutdown sleep 120 fi fi Even if I name this zz_killpower.sh to make it run last, depending on how long it takes FreeBSD to flush the cash after all rc.d scripts are run, I could end up doing a dirty power down, right? Without this, if the power does come back while before the battery finally dies, the system won't restart since the power was never fully interrupted at the computer side? > As far as my experiences using nut with RAID and different setups if the > shutdown command works from a command line, it will work the same from nut. > > I would also suggest you test your setup. Pull the plug on your UPS and > watch what happens. I absolutely will do a full test as such before I put full faith in the setup, but I want to first minimize the chance of me destroying the file system during the test. > > Also you should employ other monitoring systems and scripts, should a > system not reboot correctly, you do want to know that quickly. > > -Derek