Re: Nut and RAID on FreeBSD 7.0
On Jan 11, 2008 7:19 AM, Derek Ragona <[EMAIL PROTECTED]> wrote: > > > At 01:43 AM 1/11/2008, Derrick Ryalls wrote: > > On Jan 10, 2008 3:52 PM, Kurt Buff <[EMAIL PROTECTED]> wrote: > > > > On Jan 10, 2008 3:14 PM, Bob Johnson <[EMAIL PROTECTED]> wrote: > > > On 1/10/08, Derrick Ryalls <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Perhaps I need to re-evaluate my line of thinking. Light sometime > > > > flicker, but power almost never goes out. When it does it is either > > > > back on in less than 1 minute, or out for hours. If the UPS detects > > > > critical correctly and gives me at least a minute before death, then > > > > that should be plenty of time for the system to auto-shutdown. Guess > > > > I will have to do some experimentation tonight. > > > > > > While you experiment, keep in mind the following sequence of events: > > > > > > -- Power fails > > > -- UPS signals low battery > > > -- System shuts down > > > -- Power returns before UPS shuts itself down > > > --> System never reboots, because it never lost power. > > > > > > Getting around this is the tricky part. I haven't used NUT in about > > > seven years, but back then the recommendation was to shut down to > > > single user mode and run a script that delayed for some time longer > > > than the remaining battery life of the UPS, then rebooted the system. > > > There didn't seem to be an easy hook for running a script after > > > shutting down to single user mode (maybe there is now). > > > > > > I haven't looked at NUT recently, but I expect the various flags that > > > you are supposed to test are another way around this problem. > > > > Trying to test out the scripts, I ran into a road block. I see that > upsmon is working and detecting the events I wanted to detect from > these sorts of entries in /var/log/messages: > > Jan 10 23:28:57 frodo upsmon[80983]: UPS [EMAIL PROTECTED] on line power > > Plus a similar message for going to battery power. However, the > notify executable is having issues and is dumping dozens of lines like > this in /var/log/messages: > > Jan 10 23:28:09 frodo kernel: pid 81029 (upssched), uid 1005: exited > on signal 11 > Jan 10 23:28:09 frodo kernel: pid 81031 (upssched), uid 1005: exited > on signal 11 > Jan 10 23:28:10 frodo kernel: pid 81032 (upssched), uid 1005: exited > on signal 11 > Jan 10 23:28:10 frodo kernel: pid 81033 (upssched), uid 1005: exited > on signal 11 > Jan 10 23:28:11 frodo kernel: pid 81034 (upssched), uid 1005: exited > on signal 11 > Jan 10 23:28:11 frodo kernel: pid 81035 (upssched), uid 1005: exited > on signal 11 > > I tried giving the user the user in question (nutmon) a shell of > /bin/sh instead of /sbin/nologin but that didn't help. Any clues on > how to fix this? Executing upssched from the command line it tells me > not to execute directly (similar to what the man page states), and > manually executing the upsched-cmd shell script does work and the > script itself uses full paths for commands. > > What is in your notify command? > > I set my NOTIFYCMD in upsmon.conf to a simple shell script I created to > send the message via sendmail, here is my script if that helps: > > > #!/usr/local/bin/ksh > #set -x > SENDMAIL=/usr/sbin/sendmail > MAIL=/usr/bin/mail > HOSTNAME=/bin/hostname > > MYHOSTNAME=`$HOSTNAME -s` > > echo $* | $MAIL -s "UPS Alert from $MYHOSTNAME" > [EMAIL PROTECTED] > > > > -Derek > I was previously pointing it at the provided upssched process which is supposed to handle timers and such and fire off upsshed-cmd which is a provided shell script that I had modified. This is the 'documented' way of doing it and gives the extra benefit of being able to add timers so if the power goes out for 3 seconds, I won't be notified. Using your script directly did work for lost/gained power events so I guess I can go that route. I won't be able to do timers or anything, but I will at least be notified when the power goes out. I'll be checking the safe power down this weekend. Thanks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nut and RAID on FreeBSD 7.0
At 01:43 AM 1/11/2008, Derrick Ryalls wrote: On Jan 10, 2008 3:52 PM, Kurt Buff <[EMAIL PROTECTED]> wrote: > > On Jan 10, 2008 3:14 PM, Bob Johnson <[EMAIL PROTECTED]> wrote: > > On 1/10/08, Derrick Ryalls <[EMAIL PROTECTED]> wrote: > > > > > > > > Perhaps I need to re-evaluate my line of thinking. Light sometime > > > flicker, but power almost never goes out. When it does it is either > > > back on in less than 1 minute, or out for hours. If the UPS detects > > > critical correctly and gives me at least a minute before death, then > > > that should be plenty of time for the system to auto-shutdown. Guess > > > I will have to do some experimentation tonight. > > > > While you experiment, keep in mind the following sequence of events: > > > > -- Power fails > > -- UPS signals low battery > > -- System shuts down > > -- Power returns before UPS shuts itself down > > --> System never reboots, because it never lost power. > > > > Getting around this is the tricky part. I haven't used NUT in about > > seven years, but back then the recommendation was to shut down to > > single user mode and run a script that delayed for some time longer > > than the remaining battery life of the UPS, then rebooted the system. > > There didn't seem to be an easy hook for running a script after > > shutting down to single user mode (maybe there is now). > > > > I haven't looked at NUT recently, but I expect the various flags that > > you are supposed to test are another way around this problem. > Trying to test out the scripts, I ran into a road block. I see that upsmon is working and detecting the events I wanted to detect from these sorts of entries in /var/log/messages: Jan 10 23:28:57 frodo upsmon[80983]: UPS [EMAIL PROTECTED] on line power Plus a similar message for going to battery power. However, the notify executable is having issues and is dumping dozens of lines like this in /var/log/messages: Jan 10 23:28:09 frodo kernel: pid 81029 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:09 frodo kernel: pid 81031 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:10 frodo kernel: pid 81032 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:10 frodo kernel: pid 81033 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:11 frodo kernel: pid 81034 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:11 frodo kernel: pid 81035 (upssched), uid 1005: exited on signal 11 I tried giving the user the user in question (nutmon) a shell of /bin/sh instead of /sbin/nologin but that didn't help. Any clues on how to fix this? Executing upssched from the command line it tells me not to execute directly (similar to what the man page states), and manually executing the upsched-cmd shell script does work and the script itself uses full paths for commands. What is in your notify command? I set my NOTIFYCMD in upsmon.conf to a simple shell script I created to send the message via sendmail, here is my script if that helps: #!/usr/local/bin/ksh #set -x SENDMAIL=/usr/sbin/sendmail MAIL=/usr/bin/mail HOSTNAME=/bin/hostname MYHOSTNAME=`$HOSTNAME -s` echo $* | $MAIL -s "UPS Alert from $MYHOSTNAME" [EMAIL PROTECTED] -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nut and RAID on FreeBSD 7.0
On Jan 10, 2008 3:52 PM, Kurt Buff <[EMAIL PROTECTED]> wrote: > > On Jan 10, 2008 3:14 PM, Bob Johnson <[EMAIL PROTECTED]> wrote: > > On 1/10/08, Derrick Ryalls <[EMAIL PROTECTED]> wrote: > > > > > > > > Perhaps I need to re-evaluate my line of thinking. Light sometime > > > flicker, but power almost never goes out. When it does it is either > > > back on in less than 1 minute, or out for hours. If the UPS detects > > > critical correctly and gives me at least a minute before death, then > > > that should be plenty of time for the system to auto-shutdown. Guess > > > I will have to do some experimentation tonight. > > > > While you experiment, keep in mind the following sequence of events: > > > > -- Power fails > > -- UPS signals low battery > > -- System shuts down > > -- Power returns before UPS shuts itself down > > --> System never reboots, because it never lost power. > > > > Getting around this is the tricky part. I haven't used NUT in about > > seven years, but back then the recommendation was to shut down to > > single user mode and run a script that delayed for some time longer > > than the remaining battery life of the UPS, then rebooted the system. > > There didn't seem to be an easy hook for running a script after > > shutting down to single user mode (maybe there is now). > > > > I haven't looked at NUT recently, but I expect the various flags that > > you are supposed to test are another way around this problem. > Trying to test out the scripts, I ran into a road block. I see that upsmon is working and detecting the events I wanted to detect from these sorts of entries in /var/log/messages: Jan 10 23:28:57 frodo upsmon[80983]: UPS [EMAIL PROTECTED] on line power Plus a similar message for going to battery power. However, the notify executable is having issues and is dumping dozens of lines like this in /var/log/messages: Jan 10 23:28:09 frodo kernel: pid 81029 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:09 frodo kernel: pid 81031 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:10 frodo kernel: pid 81032 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:10 frodo kernel: pid 81033 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:11 frodo kernel: pid 81034 (upssched), uid 1005: exited on signal 11 Jan 10 23:28:11 frodo kernel: pid 81035 (upssched), uid 1005: exited on signal 11 I tried giving the user the user in question (nutmon) a shell of /bin/sh instead of /sbin/nologin but that didn't help. Any clues on how to fix this? Executing upssched from the command line it tells me not to execute directly (similar to what the man page states), and manually executing the upsched-cmd shell script does work and the script itself uses full paths for commands. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nut and RAID on FreeBSD 7.0
On Jan 10, 2008 3:14 PM, Bob Johnson <[EMAIL PROTECTED]> wrote: > On 1/10/08, Derrick Ryalls <[EMAIL PROTECTED]> wrote: > > > > > Perhaps I need to re-evaluate my line of thinking. Light sometime > > flicker, but power almost never goes out. When it does it is either > > back on in less than 1 minute, or out for hours. If the UPS detects > > critical correctly and gives me at least a minute before death, then > > that should be plenty of time for the system to auto-shutdown. Guess > > I will have to do some experimentation tonight. > > While you experiment, keep in mind the following sequence of events: > > -- Power fails > -- UPS signals low battery > -- System shuts down > -- Power returns before UPS shuts itself down > --> System never reboots, because it never lost power. > > Getting around this is the tricky part. I haven't used NUT in about > seven years, but back then the recommendation was to shut down to > single user mode and run a script that delayed for some time longer > than the remaining battery life of the UPS, then rebooted the system. > There didn't seem to be an easy hook for running a script after > shutting down to single user mode (maybe there is now). > > I haven't looked at NUT recently, but I expect the various flags that > you are supposed to test are another way around this problem. At which point, you either hit the power button manually, or you telnet/ssh/web to your contollable PDU and tell it to remove power from the outlet(s) for 10 seconds. Kurt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nut and RAID on FreeBSD 7.0
On 1/10/08, Derrick Ryalls <[EMAIL PROTECTED]> wrote: > > Perhaps I need to re-evaluate my line of thinking. Light sometime > flicker, but power almost never goes out. When it does it is either > back on in less than 1 minute, or out for hours. If the UPS detects > critical correctly and gives me at least a minute before death, then > that should be plenty of time for the system to auto-shutdown. Guess > I will have to do some experimentation tonight. While you experiment, keep in mind the following sequence of events: -- Power fails -- UPS signals low battery -- System shuts down -- Power returns before UPS shuts itself down --> System never reboots, because it never lost power. Getting around this is the tricky part. I haven't used NUT in about seven years, but back then the recommendation was to shut down to single user mode and run a script that delayed for some time longer than the remaining battery life of the UPS, then rebooted the system. There didn't seem to be an easy hook for running a script after shutting down to single user mode (maybe there is now). I haven't looked at NUT recently, but I expect the various flags that you are supposed to test are another way around this problem. - Bob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nut and RAID on FreeBSD 7.0
At 04:43 PM 1/10/2008, Derrick Ryalls wrote: > > > > 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? > You are reading the old documentation. The current nut, 2.2, has complete > rc scripts that are installed in /usr/local/etc/rc.d > > You need only define the flag file you want to use in upsmon.conf > > Also define what actions you want in that file as well. You need to use > the sample files installed in /usr/local/etc/nut and be sure to read the > comments. > I have 2.2 installed and am using the existing scripts. In the comments in uspmon.conf, there is this part: # -- # POWERDOWNFLAG - Flag file for forcing UPS shutdown on the master system # # upsmon will create a file with this name in master mode when it's time # to shut down the load. You should check for this file's existence in # your shutdown scripts and run 'upsdrvctl shutdown' if it exists. # # See the shutdown.txt file in the docs subdirectory for more information. POWERDOWNFLAG /etc/killpower Which in the related documentation means I need the custom shutdown script mentioned above which checks for the existence of the /etc/killpower file before doing the upsdrvctl shutdown command to kill the UPS before the battery is completely dead. I suppose in you
Re: Nut and RAID on FreeBSD 7.0
> > > > 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? > You are reading the old documentation. The current nut, 2.2, has complete > rc scripts that are installed in /usr/local/etc/rc.d > > You need only define the flag file you want to use in upsmon.conf > > Also define what actions you want in that file as well. You need to use > the sample files installed in /usr/local/etc/nut and be sure to read the > comments. > I have 2.2 installed and am using the existing scripts. In the comments in uspmon.conf, there is this part: # -- # POWERDOWNFLAG - Flag file for forcing UPS shutdown on the master system # # upsmon will create a file with this name in master mode when it's time # to shut down the load. You should check for this file's existence in # your shutdown scripts and run 'upsdrvctl shutdown' if it exists. # # See the shutdown.txt file in the docs subdirectory for more information. POWERDOWNFLAG /etc/killpower Which in the related documentation means I need the custom shutdown script mentioned above which checks for the existence of the /etc/killpower file before doing the upsdrvctl shutdown command to kill the UPS before the battery is completely dead. I suppose in your situation you won't need this extra script as you r
Re: Nut and RAID on FreeBSD 7.0
At 01:40 PM 1/10/2008, Derrick Ryalls wrote: > > 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? You are reading the old documentation. The current nut, 2.2, has complete rc scripts that are installed in /usr/local/etc/rc.d You need only define the flag file you want to use in upsmon.conf Also define what actions you want in that file as well. You need to use the sample files installed in /usr/local/etc/nut and be sure to read the comments. -Derek > 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner
Re: Nut and RAID on FreeBSD 7.0
> > 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nut and RAID on FreeBSD 7.0
At 06:51 PM 1/9/2008, Derrick Ryalls wrote: 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. 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. Also you should employ other monitoring systems and scripts, should a system not reboot correctly, you do want to know that quickly. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
