LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (http://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   apcupsd - apctest (http://www.linuxquestions.org/questions/linux-hardware-18/apcupsd-apctest-421353/)

eyt 03-03-2006 04:35 PM

apcupsd - apctest
 
Hi all,

I installed apcupsd on Mandrake machine. The UPS is APC Back-UPS XS 1000.

when I do the test apctest on the command line, error messages display

> apctest

2006-03-03 11:16:02 apctest 3.12.1 (06 January 2006) mandrake
Checking configuration ...
Attached to driver: usb
sharenet.type = DISABLE
cable.type = USB_CABLE

You are using a USB cable type, so I'm entering USB test mode
mode.type = USB_UPS
Setting up the port ...
apctest FATAL ERROR in device.c at line 68
Unable to create UPS lock file.
apctest FATAL ERROR in device.c at line 68
Unable to create UPS lock file.
apctest error termination completed


> tail /var/log/messages
apctest: Valid lock file for pid=1475, but not ours pid=2415

Any idea what is the problem?

gilead 03-03-2006 04:43 PM

On my system, I have to stop apcupsd before I can run the test suite. Can you try stopping apcupsd and re-running apctest to see if that works? You should get some diagnostics and then a menu:
Code:

/sbin/apctest
2006-03-04 07:41:45 apctest 3.10.18 (21 July 2005) slackware
Checking configuration ...
Attached to driver: dumb
sharenet.type = DISABLE
cable.type = APC_940_0020B (simple)
mode.type = BK
Setting up the port ...
Creating the device lock file ...
Doing prep_device() ...
Hello, this is the apcupsd Cable Test program.

We are beginning testing for dumb UPSes, which
use signaling rather than commands.
Most tests enter a loop polling every second for 10 seconds.

1) Test 1 - normal mode
2) Test 2 - no cable
3) Test 3 - no power
4) Test 4 - low battery (requires test 3 first)
5) Test 5 - battery exhausted
6) Test 6 - kill UPS power
7) Test 7 - run tests 1 through 5
8) Guess which is the appropriate cable
9) Quit

Select test number:


eyt 03-06-2006 09:13 AM

Hi gilead,

Sorry for the late reply. I shutdown apcupsd and rerun apctest and it works fine. It do some diagnosis and display the menu.

I start up apcupsd again and run apcaccess status, it takes a long time to display the message:
> apaccess status

FATAL ERROR in apcaccess.c at line 252
tcp_open: cannot connect to server localhost on port 3551.
ERR=Connection timed out


I read from the web that the problem is that the Network Information Server is not enabled. I then checked the apcupsd.conf and find the Network Information Server is already enabled with the following setting:

NETSERVER on
NISPORT 3551

Any idea what is the problem.

gilead 03-06-2006 02:15 PM

I haven't seen that problem - in my apcupsd.conf I have the following:
Code:

NETSERVER on
NISIP 192.168.1.1
NISPORT 3551

I only specify the NISIP because the PC has multiple NICs and I didn't want connection attempts from the internet.

Do you use ethereal? You should be able to run it and have it listen to your loopback interface (lo) while you run the apcaccess command. Mine shows the command being issued and the status data being returned. If your netserver isn't running and the port isn't blocked you'll probably see the connection being reset. This means that it didn't start properly - ther may be some info in /var/log/messages or /var/log/apcupsd.events.

If the port is blocked, you should just see SYN packets going to port 3551 and nothing returning (if your firewall drops packets). The firewall thing is unlikely, not many people block localhost.

eyt 03-08-2006 11:49 AM

Hi Gilead,

The problem is in the firewall setting. I have a rule to kill all connection to the local interface from the outside world.

iptables -A INPUT -j REJECT -d 127.0.0.0/8

When I remove this rule and run apcaccess status, it displays the information of the UPS.

Is it insecure to remove this rule.

To test whether the apcupsd shut down the machine when power is off, I unplug the UPS. The linux system process the shutdown. After all the process are killed, it display the following message and the machine just freeze and the machine still remains power on. The machine fails to power off:

Sending all processes the TERM signal..
Su(pam-unix)[2412]: session closed for user root[ok]

INIT: no more processes left in this runlevel

gilead 03-08-2006 02:15 PM

I'd also specify the interface that the traffic is arriving on. For example:
Code:

iptables -A INPUT -i eth0 -d 127.0.0.0/8 -j REJECT
This way, it's not going to stop the legitimate packets travelling on lo, but it will stop spoofed (or at least dodgy) packets arriving from the LAN.

I haven't seen that 'no processes left' message for a while - it sounds like you don't have power management support compiled into the kernel. All of the processes have shut down and the PC is waiting for you to manually power it off. If you compiled your kernel from sources can you check that the .config file has CONFIG_ACPI=y or CONFIG_APM=y set please?

eyt 03-08-2006 03:54 PM

Which .confi file to check whether the power management support is compiled into the kernel

gilead 03-08-2006 05:17 PM

Usually, it's under /usr/src/linux-2.x.x (x.x is your kernel version number). The file is called .config. If you've never compiled a kernel before, it may be worth checking whether any of the Mandriva updates include those options (I'm not a Mandriva user, so I can't help much with that). Try the following:
Code:

egrep '^CONFIG_(ACPI|APM)' /usr/src/linux-`uname -r`/.config

eyt 03-09-2006 12:16 PM

When I run egrep '^CONFIG_(ACPI|APM)' /usr/src/linux-`uname -r`/.config, I got the following result and found CONFIG_ACPI is not set:

CONFIG_APM=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_RTC_IS_GMT=y

Do I need to recompile the kernel to enable the power management?

gilead 03-09-2006 02:02 PM

This is one of those 'give it a try' situations. I'd have thought APM would be OK, but maybe it does need to use ACPI. Sorry I can't be more helpful...

eyt 03-09-2006 02:16 PM

Thanks Steve. You are very helpful.


All times are GMT -5. The time now is 11:45 PM.