Sophie

Sophie

distrib > Mandriva > 9.1 > ppc > by-pkgid > 37e222326095a93978d54b1564dd9954 > files > 91

apcupsd-3.10.5-1mdk.ppc.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
  <TITLE>APC UPS Power Management under Linux, Unix, and Windows</TITLE>
   <meta name="Author" content="Kern Sibbald">
  <META NAME="DESCRIPTION" CONTENT="Apcupsd a Linux/Win32 daemon for controlling APC UPSes">
  <META NAME="KEYWORDS" CONTENT="apcupsd, UPS, APC, Power Mangement, American Power Corporation, Uninterruptable Power Supplies">
        <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
        <STYLE>
        <!--
                H1 { color: #000000 }
                TD P { color: #000000 }
                H2 { color: #000000 }
                H3 { color: #000000 }
                H4 { color: #000000 }
                P { color: #000000 }
                DT { margin-top: 0.2in; color: #000000; font-weight: bold }
                DD { color: #000000; font-weight: medium }
                A:link { color: #0000ff }
                A:visited { color: #000080 }
                                P.indent { margin-left: 0.39in }
        -->
        </STYLE>
</HEAD>
<BODY TEXT="#000000" LINK="#0000ff" VLINK="#800080" BGCOLOR="#ffffff">
<P ALIGN=CENTER><IMG SRC="apcupsd.gif" ALT="[APCUPSD DOCUMENTATION]" ALIGN=BOTTOM WIDTH=584 HEIGHT=64 BORDER=0>
</P>

<H1 ALIGN=CENTER>Apcupsd Bugs</H1>
<h1>Apcupsd Version 3.9.8 Bugs</h1>
Since the software has major modifications, there are probably
quite a few bugs, many of which are simply unfinished implementations.
For example, the EEPROM programming feature is disabled in this
version while we are deciding how to do it the <b>right</b> way.
<p>
The 3.8.5 Slackware bug reported below for version 3.8.5 does
not apply to version 3.9.8.

<h2>The killpower Feature Does Not Work On USB UPSes</h2>
We have not yet been able to make a USB UPS
shut off the power. This applies both to the BackUPS CS  
models as well as the SmartUPS models. Though this means
the implementation is incomplete, it should not be a 
major issue if after performing a system halt, your
computer does not power off (this is the normal behavior).
In that case, the computer will continue to drain the
UPS batteries and generally within 2 minutes the UPS
will shutoff. If this happens, you computer will 
automatically reboot when the mains power returns.
Unfortunately, leaves a 2 minute (or longer) window
where the mains power can return and your computer will be
left in a halted state.

<h2>Battery Voltages Are Not Correct</h2>
On all USB UPSes, the battery voltage is incorrectly
scaled in STATUS output.
In addition, on Back-UPS CSes,
the BATTV value is not reported in STATUS output.
Though annoying, this 
causes no harm as the battery voltages are
used for display only.  

<h1>Apcupsd Version 3.8.5 Bugs</h1>
All previous bugs reported against <b>apcupsd</b> have
been fixed in this version.
<h2>Slackware -- After a Power Failure, It Reboots</h2>
This bug concerns the Slackware platform only. When
power is lost and then restored, <b>apcupsd</b> will
cause the system to reboot. This is due to an
omission (error) in the file <b>distributions/slackware/apccontrol.sh.in</b>.
The patch is as follows:
<pre>
--- apccontrol.sh.in.orig             Wed Mar 13 17:51:05 2002
+++ apccontrol.sh.in                  Wed Mar 13 17:53:40 2002
@@ -82,9 +82,11 @@
         ;;
         mainsback)
                 printf "Power has returned..." | wall
-                printf "Attempting to cancel shutdown." | wall
-                ${SHUTDOWN} -c
-                ${SHUTDOWN} -r now "apcupsd initiated reboot"
+                if [ -f @PWRFAILDIR@/powerfail ] ; then
+                   printf "Attempting to cancel shutdown." | wall
+                   ${SHUTDOWN} -c
+                   ${SHUTDOWN} -r now "apcupsd initiated reboot"
+                fi
         ;;
         annoyme)
                 printf "Power problems please logoff." | wall
</pre>
After applying this patch, you must either do:
<pre>
make Makefiles
make install
</pre>
or simply rerun the whole build process starting
from <b>./configure</b>


<h1>Apcupsd Version 3.8.4 Bugs</h1>
Version 3.8.4 is a bug fix version to 3.8.3 that corrects
improper placement of the subsystem lock file that crept in
between 3.8.2 and 3.8.3.  It also corrects an oversight in
the multimoncss.c code that didn't include the temperature
and humidity columns in the <b>Normal</b> class.
   
<h1>Apcupsd Version 3.8.3 Bugs</h1>
All known bugs in version 3.8.2 have been fixed with the exception
of the following two:
<h2>Networking may not work in a mixed vendor setup</h2>
Bug: In a mixed vendor setup (RedHat, Debian, ...), the default networking
(master/slave or Network Information Server) port assignments are different.
Reason: Due to port conflicts on some machines, we set the default port
numbers on each distribution to the values recommended by our experts. 
This solves a lot of problems, but results in incompatibilities if you
use the <b>apcupsd</b> defaults.
Fix: If you run a mixed vendor setup, either add a port specification
<b>:&lt;port&gt;</b> to the machine name in <b>hosts.conf</b> or use the
<b>--with-nis-port=nn</b>
and <b>--with-net-port=nn</b> options on your <b>./configure</b> command
and ensure that all your machines use the same port numbers. After the
<b>./configure</b>, you will need to redo your <b>make</b> and <b>make install</b>.
The default values for most systems are:
<p class="tty">./configure --with-nis-port=7000 --with-net-port=6666</p>
<p></p>

<h2>Unusual Case of Apcupsd Hanging during Boot</h2>
On some systems (kernel version 2.4.5-acxx), <b>apcupsd</b> may hang 
during the boot process. This appears to be a probably of invoking 
<b>apcupsd</b> before the network is initialized. The simplest solution
is to ensure that <b>apcupsd</b> is started after the network functions,
or to put an explicit background (ampersand) request in the <b>apcupsd</b>
startup script.
<p></p>If this occurs and your <b>apcupsd</b> is a master, the problem 
can be because you master/slave networking port is used by another program
on the slave machine. The master/slave networking code has been modified
to timeout in 10 seconds in this case.

<h1>Apcupsd Version 3.8.2 Bugs</h1>
All version 3.8.0 and 3.8.1 bugs have been corrected in version 3.8.2.
<h2>The Lock Directory in the Solaris is Incorrect</h2>
Bug: The apcupsd script is using /var/lock as the directory for lock
 files even though the configure script figures out that it is
 supposed to be /var/spool/locks (/var/lock does not exist).
<p></p>
Fix: Apply the following patch then re-run your ./configure:
<pre>
--- distributions/sun/old.apcupsd.in    Sat Jul  7 10:20:30 2001
+++ distributions/sun/apcupsd.in        Sat Jul  7 10:18:59 2001
@@ -17,7 +17,7 @@
         rm -f @PWRFAILDIR@/powerfail
         echo "Starting apcupsd power management ...\c"
         @sbindir@/apcupsd || return="  Failed."
-        touch /var/lock/apcupsd
+        touch @LOCKDIR@/apcupsd
         echo "$return"
     ;;
     stop)
@@ -29,7 +29,7 @@
         else
                 return=" Failed."
         fi
-        rm -f /var/lock/apcupsd
+        rm -f @LOCKDIR@/apcupsd
         echo "$return"
     ;;
     restart)
</pre>

<h2>Solaris doesn't Shutdown</h2>
Bug: Solaris detects power failures and seems to work fine, but the machine is
not shutdown.
<p></p>
Reason: You probably executed the ./configure for <b>apcupsd</b> with <b>/usr/ucb</b>
on your path before <b>/usr/sbin</b>. Thus <b>apcupsd</b> is using the Berkeley
shutdown program but with SysV arguments.  
<p></p>
Fix: remove <b>/usr/ucb</b>
from your path and rerun your ./configure, make, and make install. <b></b>Alternative:
edit <b>/etc/apcupsd/apccontrol</b> and set the correct path for the SysV
shutdown. We are working on a permanent solution.

<h2>examples/safe.apccontrol has bad wall command</h2>
Bug: On non-Linux systems, the examples/safe.apccontrol doesn't work
because it uses <b>wall "message"</b> whereas on other systems <b>wall</b>
only accepts the message from stdin.
<p></p>
Fix: We have modified <b>examples/safe.apccontrol</b> to use <b>wall &lt;&lt;EOF</b>
input, which should work fine on all systems. 
You can download the new version of safe.apccontrol from 
<a href="http://www.sibbald.com/apcupsd/download/safe.apccontrol.tar.gz">safe.apccontrol.tar.gz</a>,
but you may want to edit the paths to correspond to your system.
<p></p>
Future: For the next version of <b>apcupsd</b>,
we have also created a <b>examples/safe.apccontrol.in</b> 
so that all the paths will be
correctly set by configure for your system.<p></p>

<h2>Networking does not work in a mixed vendor setup</h2>
Bug: In a mix vendor setup (RedHat, Debian, ...), the default networking
(master/slave or Network Information Server) port assignments are different.
Reason: Due to port conflicts on some machines, we set the default port
numbers on each distribution to the values recommended by our experts. 
This solves a lot of problems, but results in incompatibilities if you
use the <b>apcupsd</b> defaults.
Fix: If you run a mixed vendor setup, use the <b>--with-nis-port=nn</b>
and <b>--with-net-port=nn</b> options on your <b>./configure</b> command
and ensure that all your machines use the same port numbers. After the
<b>./configure</b>, you will need to redo your <b>make</b> and <b>make install</b>.
The default values for most systems are:
<p class="tty">./configure --with-nis-port=7000 --with-net-port=6666</p>
<p></p>

<h2>Unusual Case of Apcupsd Hanging during Boot</h2>
On some systems (kernel version 2.4.5-acxx), <b>apcupsd</b> may hang 
during the boot process. This appears to be a probably of invoking 
<b>apcupsd</b> before the network is initialized. The simplest solution
is to ensure that <b>apcupsd</b> is started after the network functions,
or to put an explicit background (ampersand) request in the <b>apcupsd</b>
startup script.

<h1>Apcupsd Version 3.8.1 Bugs</h1>
Unfortunately, it seems that every program has some bugs. We do our best
to keep the bugs to a minimum by extensive testing. However, because of
our inherent nature to occasionally overlook things and the fact that we don't have
all the UPS models nor the APC documentation on those models, apcupsd will
have some bug.
<p>As the bugs become known to us, we will post them here with any possible
fixes or workarounds that we have.

<h2>Apcupsd may Hang when Attempting to Initialize the Serial Port</h2>
This problem has been reported on NetBSD systems and on a
Solaris8 (64bit) UltraSparc60 system. The problem is that the open() of
the serial port does not return. The solution is to use the O_NDELAY
flag when opening the port.  The open() at 85 of apcserial.c should
be replaced with the following:
<pre>
       if ((ups->fd = open(ups->device, O_RDWR | O_NOCTTY | O_NDELAY)) < 0) {
                Error_abort2(_("Cannot open UPS tty %s: %s\n"),
                                        ups->device, strerror(errno));
        }
        /* Cancel the no delay we just set */
        cmd = fcntl(ups->fd, F_GETFL, 0);
        fcntl(ups->fd, F_SETFL, cmd & ~O_NDELAY);

</pre>
Please note the addition of the two fcntl() calls to remove the O_NDELAY
so that <b>apcupsd</b> will function properly. The patch relative to 
apcupsd-3.8.1 is:
<pre>
@@ -77,18 +81,21 @@
                 Error_abort0(_("Serial port already initialized.\n"));
        }
 
-       /* Open the the device */
-       if ((ups->fd = open(ups->device ,O_RDWR | O_NOCTTY )) < 0) {
+       /* Open the serial port device */
+       if ((ups->fd = open(ups->device, O_RDWR | O_NOCTTY | O_NDELAY)) < 0) {
                 Error_abort2(_("Cannot open UPS tty %s: %s\n"),
                                        ups->device, strerror(errno));
        }
+       /* Cancel the no delay we just set */
+       cmd = fcntl(ups->fd, F_GETFL, 0);
+       fcntl(ups->fd, F_SETFL, cmd & ~O_NDELAY);

</pre>

<h2>Version 3.8.1 May Cause Networking Problems on Win95</h2>
We have a report by a user that installing version 3.8.1 on a
Windows 95 machine caused the loss of all networking capabilities
on that machine. Re-installation of version 3.8.0 restored the
networking capabilities. It should be noted that the major difference
between the two versions was addition of support on Win32 for simple
signaling UPSes (no change for Smart UPSes or networking) and upgrading from
version 1.1.2 to version 1.1.5 of CYGWIN. We would appreciate hearing of your
experiences with Win95 and <b>apcupsd</b>.

<h2>STATUS Output for BackUPS Pro and SmartUPS VS Incorrect</h2>
The STATUS Output for the BackUPS Pro and SmartUPS VS was unfortunately
truncated due to a misplaced "break" statement.  To fix this problem
and restore the full STATUS output, for version 3.8.1, delete line
161 of apcstatus.c, which should be "break;"
<pre>
            } else {
                      s_write("LINEFAIL : DOWN\n");
                      if (ups->BattLow == 0) {
                              s_write("BATTSTAT : RUNNING\n");
                              ups->Status = UPS_ONBATT;
                      } else {
                              s_write("BATTSTAT : FAILING\n");
                              ups->Status = UPS_BATTLOW;
                      }
              }
              s_write("STATFLAG : 0x%02X Status Flag\n", ups->Status);
              break;                                       &lt;=========== delete this line
           case NBKPRO:
           case SMART:
           case SHARESMART:
           case MATRIX:
              if (ups->UPS_Cap[CI_IDEN]) {
                      s_write("UPSNAME  : %s\n", ups->name);
              } else {
                      s_write("UPSNAME  : N/A\n");
              }

</pre>
Thanks to Joe Acosta for reporting this bug and testing the fix.  The patch relative
to apcupsd-3.8.1 is:
<pre>
@@ -158,7 +158,7 @@
                      }
              }
               s_write("STATFLAG : 0x%02X Status Flag\n", ups->Status);
-             break;
+             /* Note! Fall through is wanted */
           case NBKPRO:
           case SMART:
           case SHARESMART:
</pre>

<h2>Automatic Self Test is Reported as Power failure</h2>
Depending on your EEPROM setting, the UPS will enter an automatic self test
mode for approximately 30 seconds every two weeks (the default). The self test
involves a switch to battery power, and <b>apcupsd</b> reports this as a
power failure. We hope to correct this in a future version.

<h2>Improper Shutdown of Apcupsd on WinNT Systems</h2>
If you attempt to shutdown <b>apcpusd</b> on a WinNT system either through
the system tray icon or via the Services Manager, two of the three <b>apcupsd</b>
processes may become stuck in the computer. One of this processes may consume
all available CPU time. Even as the system administrator, you will be unable
to kill these processes (that's Microsoft for you!). Normally, there should be
no need to stop <b>apcupsd</b>. However, should you want to do so, for example,
to make an upgrade, go to the Services dialog from the Control Panel, and
deactivate <b>apcupsd</b> then reboot your computer.

<h2>Name Resolution Does Not Work on Win32 Systems</h2>
In a master/slave configuration, normally one uses the master and slave machine
names as a qualified domain name in apcupsd.conf. Unfortunately, on Win32 systems,
<b>apcupsd</b> is unable to resolve these names to an IP address needed to communicate
with the other end. To resolve the problem, please use an explicit IP address written
as a dotted quadruple (e.g.  192.168.1.100) instead of the machine name.

<h2>The apccontrol Script Doesn't Work with All User Scripts</h2>
<b>apcupsd</b> allows customization of the actions taken during <b>events</b>
(e.g. onbattery, mainsback, etc). One method is to modify the /etc/apcupsd/apccontrol
script directly. However, this makes it more difficult to upgrade to a new
version of <b>apcupsd</b>. An alternate method is to place your own script in the 
/etc/apcupsd directory with the name of the event that you wish to control. For example,
you may want to shutdown an Oracle database prior to issuing the system shutdown
command. If the script you create is a shell script, everything is OK. However, if
you use a Perl script the script may not run. To correct this problem, change the
following line in apccontrol:
<pre>
      ${SCRIPTSHELL} ${SCRIPTDIR}/${1}
</pre>
at line 38 of apccontrol (depending on your version), to:
<pre>
      ${SCRIPTDIR}/${1}
</pre>
For this to work, your script file must have the executable bit set. 

<h2>Denial of Service Security Problem</h2>
One of our users emailed us with the following information
(with which, we agree):

<blockquote>
<p>I noticed that its (apcupsd's) handling of temp files during e-mail notification was
prone to denial-of-service attacks.  
I found this vulnerability within
these scripts found in the /etc/apcupsd directory in the above RPM:
<pre>
        changeme
        commfailure
        commok
        mainsback
        onbattery
</pre>
Since the notification scripts blindly write to a $$-selected /tmp
filename, any user on the box could cause root to overwrite any file on
the system (/etc/passwd, /boot/vmlinuz) with the UPS error message by
making lots and lots of /tmp/apcupsd.onbattery.##### symlinks which point
to the victim file and waiting.  (Yes, it's fairly unlikely, but a hole's
a hole.)
<p>
As work-arounds, I'd recommend either moving the temp file to within
/etc/apcupsd (which is writable only by root or else the sysadmin has
bigger problems than temp file creation) or piping from a subshell like
this:
<pre>
        (
                echo "$MSG"
                echo " "
                /sbin/apcaccess status
        ) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN
</pre>
</blockquote>

<h1>Apcupsd version 3.8.0 Bugs</h1>
In addition to the bugs reported above, version 3.8.0 has
the following problems. Please note that all of these 
bugs have been corrected in version 3.8.1.

<h2>Win32 apcupsd Does Not Work with Simple Signaling UPSes</h2>
The Win32 version of apcupsd will not support simple signaling
UPSes (sometimes called dumb UPSes) such as the Back-UPS. Please do not
attempt to use it as if there is a power failure, it will most likely 
cause the UPS to suddenly shut off the power to your computer. This
is due to the fact that CYGWIN does not support serial line signal
level IOCTL calls. We hope to rectify this situation in the not
so distant future (no promises because of the inadequacies of the
Windows API in this area, which is probably why CYGWIN does not support
the signal level IOCTLs).

<h2>Bad Path to Shutdown in apccontrol Script</h2>
A Japanese user has reported that the call to /usr/bin/shutdown in the
apccontrol script must be changed to /sbin/shutdown on his
RedHat 6.2J system (/usr/bin/shutdown is valid on my English
RedHat 5.2, 6.0, 6.1, and 7.0 systems). 
This kind of problem underscores the necessity to test
the installation, as this user wisely did.

<h2>CGI Programs May Error When Called Directly</h2>
If instead of calling the CGI program multimon.cgi, the user calls one of the
helper programs directly, that program may detect bad arguments and error. This
causes Apache to report an "Internal Error" to the user. This is a bit unpleasant
for some users but it causes no harm. All the CGI programs have been reworked
to provide less dramatic error messages, and they will be posted to this site
as updates shortly.

<h2>Alpha Tru64 32/64 Bit Bug</h2>
On Alpha machines, one instance of a 32/64 bit problem escaped our
notice during the port. It apparently only affects the CGI programs, and
causes <b>apcupsd</b> to be unable to resolve names. A fix to this problem
will be posted.
<hr>

<a href="apcnisd.html" target="_self"><img src="back.gif" border=0 alt="Back"></a>
<a href="cgiprogs.html" target="_self"><img src="next.gif" border=0 alt="Next"></a>
<a href="index.html"><img src="home.gif" border=0 alt="Home"></a>
</BODY>
</HTML>