Thanks for your reply. I tried to update nut to 2.0.2, but upsc print
out the same informations:
# upsc [EMAIL PROTECTED]
driver.name: apcsmart
driver.version: 2.0.2
driver.version.internal: 1.99.7
ups.mfr: APC
ups.status: OL
Two things you might check:
1) What cable are you using?
2)
Hello all,
Rebooted my server by mistake (don't ask...) - everything was working OK
before the reboot, but after the reboot, NUT stopped working - so had a
look and I found I couldn't track the exact problem - I'm quite stumped
as there's nothing indicating that there's a problem, but it
The reason for Success is that the code calls
fatal(getpwnam(%s), user);
and not
fatalx(getpwnam(%s), user);
While this fact is not widely documented, the only difference between
the (badly named) procedures fatal() and fatalx() is that fatal()
prints an error message based on errno,
Clay Barnes wrote:
I am running a home box (600watt total load, may expand to 800-900) and
I need a UPS that can sustain power to that for at least 20 min, but
I want as much time as I can get.
Is that rated load, or actual load? That seems like an awful lot of
Hm... It's the max draw of my
Brian Read wrote:
I am sorry if this is an FAQ, but there doesn't seem to be searchable
archives, and the supported manufacturer's list doesn't include surge
master. Google was also not much help.
I have just put a Linux box and the customer has a surge max UPS.
Anyone any ideas what
I just got myself a new everpower-1000va.
according to the compatibility list, the 'safenet' driver supposed to
support it,
That depends. The hardware this driver is written for is usually OEM
equipment and vendors tend to shop for the lowest bidder. So quite often
they change the internals
Run the driver in debug mode, I already suggested this in the previous
message. The driver will be more verbose about what the cause is that it
won't run.
how do I run it in debug mode?
Run (as root)
path to driver/safenet -a everpower1000 -D
I think that the problem is that the
Omry Yadan wrote:
Here is my output:
# /lib/nut/safenet -a everpower1000 -D
Network UPS Tools - Generic SafeNet UPS driver 0.03 (2.0.2)
debug level is '5'
C : ZCADLIOPERJD
S : [empty]
C : ZCADLIOPERJD
S : [empty]
C : ZCADLIOPERJD
S : [empty]
C : ZCADLIOPERJD
S :
Rich Osman wrote:
Okay, I'm still trying to get nut running.
[...]
The system is a SUSE 10.1 install.
Did you install the SuSE provided RPM? As far as I know, this will
pretty much do all what is necessary with regard to port handling and
such (it does for me).
Regards,
Arjen
freebsd 540$ /usr/local/etc/rc.d/nut restart
nut not running? (check /var/db/nut/upsd.pid).
Network UPS Tools - UPS driver controller 2.0.4
Network UPS Tools - Generic UPS driver 1.32 (2.0.4)
UPS type: APC Back-UPS (940-0023A cable)
Unable to open /dev/cuad0: Device busy
Stopping a driver
I'm trying to get a sweex ups working with nut on debian sarge.
Good luck! Sweex is notorious for changing their products internally,
without telling you. Have you noticed that their online documentation
still mentions the SafeNet software? And that they even have the guts to
mention that their
radius1:/etc/nut# /lib/nut/genericups -a ups_name
Network UPS Tools - Generic UPS driver 1.30 (2.0.1)
No upstype set - see help text / man page!
The last line should ring a bell, don't you think so?
radius1:/etc/nut# /lib/nut/genericups upstype=7 -a ups_name
Network UPS Tools - Generic UPS
[ups_name]
driver = genericups
upstype = 7
port = /dev/ttyS0
desc = Sweex 1000VA UPS
Ok, I tried this.
The driver was loaded and. the server shutdown immediately.
Lesson #1: Always first test whether the driver is producing good results
(you must be able to read the
YvesDM wrote:
Are you absolutely sure that the UPS is connected to /dev/ttyS0? For
'upstype=7' the signals for 'on battery' and 'low battery' are -CTS and
-DCD (both zero). I wouldn't be surprized at all if this is the same as
nothing connected to the port you're monitoring
Disconnecting a UPS from a live server and testing it at a separate
workstation is a MUST if you're not absolutely sure the configuration is
correct. I would never use an UPS on a production system without double
checking that monitoring works. Otherwise your investment gives you a
false
YvesDM wrote:
Ok, I think it's working.
The problem was the serial cable.
That why I recommended to try it under Windows with the bundled
software, to rule out a problem like this.
I had 2, one came with the ups, the other came with another ups.
During my tests I changed the original cable
Adding a 20 second sleep between starting upsd and starting upsmon
seems to solve the problem so I guess this happens because upsmon is
started right away when upsd hasn't started communicating with the UPS
but is already accepting connections.
Did you also try adding a 5 second sleep
! /sbin/upsdrvctl start /dev/null 21 echo -n (upsdrvctl failed)
start-stop-daemon -S -q -p $upsd_pid -x $upsd /dev/null 21
start-stop-daemon -S -q -p $upsmon_pid -x $upsmon /dev/null 21
Can you add '-D' as a parameter to the startup of upsmon and post
the output of all three of these
Mike Hill wrote:
I have installed the NUT 2.0.3 RPM for Fedora Core 4 and I have it working
with an MGE Pulsar Evolution 500, but I cannot get the USB interface to
work.
When I plug in the USB cable I get the following message in my system log:
kernel: usbhid: probe of 2-1:1.0 failed
Yes, this was what I tried first and it made no difference. upsdrvctl
seems to wait until the driver is fully initialized and only then goes
into the background.
Looks like I hadn't tried it with a 30 second sleep. Putting a sleep
30 between upsdrvctl and upsd also works so I guess the
I guess the problem is that Synchronizing... step.
Indeed. Either the driver needs more time to dump all the data than is
allowed for in upsd or it could also be that the first connection to the
driver always fails. Since we first declare a driver stale before
(re)connecting, this will show
I've just received a mail from Pedro Côrte Real telling me that waiting
before launching upsd could solve the problem.
I've tried, but no luck. newhidups was launched 2 hours ago, and I tried
to launch upsd 15 minutes ago.
upsd output is :
[EMAIL PROTECTED]:~ sudo upsd - -u root
Eric Masson wrote:
If I launch newhidups via :
[EMAIL PROTECTED]:~# /usr/local/libexec/nut/upsdrvctl start mge
Network UPS Tools - UPS driver controller 2.0.4
Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4)
Detected a UPS: MGE UPS SYSTEMS/ELLIPSE
Using subdriver: MGE HID 0.9
In my setup, upsd has never succeeded in connecting to newhidups.
Could you try with the dummy-ups driver from SVN? Please add the following
two lines to your ups.conf file:
[dummy]
driver = dummy-ups
If upsd is not able to monitor this dummy UPS, there is something very
wrong in your
Only if you do something like broadcasting server status via UDP and don't
listen for replies, it might make a difference. In that case, one might
place the UPS master on the internal network and forward the broadcast
packets to the DMZ. There would be no communication from DMZ to internal
Charles Lepple wrote:
However, if you are installing from source, you can still use the
startup/shutdown scripts as a guide. I forgot to mention earlier that
you will need to link /etc/init.d/nut into the appropriate shutdown
directory (probably /etc/rc0.d; my Ubuntu box is not on at the
Really? Silly me then; Megatec looked like a fairly evolved protocol so I
was afraid that, since no RTS/CTS signaling was in place into the
manufacturer supplied cable, maybe plain RX/TX/GND won't do. For example
Minicom showed Offline all the time during the tests.
Most (if not all) smart
Ciprian Vizitiu wrote:
Ok, most likely it's me but I'm out of ideas right now; last night my very
first attempt was to use NOTIFYCMD with
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
... and the very simple script for sending
Ciprian Vizitiu wrote:
Another thing: am I supposed to be able to see some activity in the
PIPEFN/LOCKFN folder during the declared AT timings? 'coz there is none!
:-o And upssched.conf has the same perms like all other files in /etc/ups/
You should see some activity there (the PIPEFN is
The cpsups driver has some flow control issues... my cyberpower 1200AVR
is kinda dumb.
The cpsups driver is rightfully flagged 'experimental'. There has been no
active maintenance on this driver for at least two years. We have tried to
fix some obvious errors in it, but if we can't find a
Doug Reynolds wrote:
After during some extreme testing of my CPS1200AVR, the trouble isn't
100% with the driver. The driver itself works the way it should.
I beg to differ. If the UPS shuts down without warning, which it doesn't
when you're using the genericups driver or Windows software, the
It looks like the connection between driver and upsd is continuously
dropping. This could be a driver problem or an upsd problem. Since the
driver is not reporting anything out of the ordinary, I suggest to
checkout the latest version from SVN. There were a couple of problems
with the
In essence, if you're worried this doesn't work (and you should be), the
only way to be sure is to try it out. Power your PC directly from the
mains and load the UPS with a lightbulb of about 100 Watt. Pull the plug
on your UPS and wait. If your PC shuts down before the lamp goes out,
you're
bug fixes are definitely welcome for the final 2.0.5...
so don't hesitate to backport theses change.
I already did. :-)
More generally, I'll start a discussion about the driver polling rate
(2 sec) which was accurate with the dumb and old smart units, but
which is really too high for
Kory Hamzeh wrote:
Thanks for the info. I will give it a try. It has both a USB and a
serial port. Eventually, I'd like to use the USB interface instead of
the serial.
We have not tested the USB connection, but based on other drivers, this
likely is not going to work. Unless the serial-to-USB
I've been following through the instructions on how to connect an APC
BackUPS 650 ES to USB, and have it monitored with NUT...
[...]
[EMAIL PROTECTED]:/usr/src/nut-2.0.4# ./drivers/newhidups -a apc -u root
Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4)
No matching USB/HID UPS found
Is there a Make/Config option that would build JUST the client binaries,
upsmon and upsc?...
Right after installing the sources, the answer is no. You need to compile
some common stuff too, for which we have no separate options available.
The question is, why do you want to do that in the
Richard Whittaker wrote:
Well, for a UPS connected client system with network ties to upsd,
there's no reason to build any of the driver stuff, the only items I'm
looking for would be upsmon, and possibly upsc, so I thought there might
be a configure --client-only option or something.
That's
Any idea when those committed powercom specs will be incorporated?
From the FAQ:
Any time there is a gap in features, it's usually because the
group of people who own that hardware and the group of people who
write code don't overlap. The fix is to make them overlap -
turn an owner into a
Somewhat off topic here.
E, right. That was my mistake, I accidentally typed in the 'wrong'
mailing list (the development list is where I hangout most of the time).
I'll reply to your message in the 'right' one.
Best regards, Arjen
--
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03
Well, thing is, I don't want it to wait until the battery is about
dead. That is not good for the batteries either. My UPS will last
about a hour but I don't want it to run that long. I mostly got the UPS
because of the blinking our lights do sometimes. As in previous post,
if it is out
Hope nut-upsuser is an appropriate place to post additional info about
the smartups protocol, please tell me if not.
We would prefer nut-devel I think, since that's more about the development
of drivers and such.
[...]
Using car batteries
===
[...]
I'm a bit concerned
When I disconnect my UPS from the wall, I have to wait 15-30 seconds
before the USB drier 'polls' this information and tells me that the UPS is
on battery power (via knutclient or syslog via nut):
[EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007
With a serial connection, I
As I'm currently porting the HP PowerTrust driver from nut-1.4.3, I have
a question regarding ups.delay.*.
The PTs can delay the Shutdown/Restart and Kill commands by an arbitrary
number of seconds, i.e. they wait for n seconds and then shutdown or
kill. The delay for the restart after the
Peter Selinger wrote:
If I understood Markus correctly, the problem is not that the data
goes stale (it should do that when disconnecting the UPS
communications line), but that it goes unstale immediately afterwards
(even when the UPS is still disconnected).
That's entirely possible if he's
After I disconnect the UPS the upsd write Data for UPS [apc] is stale -
check driver in /var/log/messages. In the same second it tells UPS [apc]
data is no longer stale. This repeats all the time the ups is
disconnected:
Jan 25 14:45:03 degpn026w226 kernel: usb 4-1: USB disconnect, address
Herman wrote:
I have a question regarding a sweex product. Its bundled with UPSmart v
2.12.
I installed nut accordingly to the user manual included in the software.
A quick check of data/drivers.list revealed to me i should use the:
Sweex 500/1000 contact closure - shipped with
Peter Selinger wrote:
If I understood Markus correctly, the problem is not that the data
goes stale (it should do that when disconnecting the UPS
communications line), but that it goes unstale immediately afterwards
(even when the UPS is still disconnected).
This shouldn't really happen.
That's not giving up, you found the right driver. Can you list the output
of 'upsc' (see 'man upsc') to see what variables are supported and if the
output looks right to you? Preferably with the contents of 'ups.conf' too,
to see if any parameters need to be passed there?
OK, we already saw
PS: why isn't reply-to set for NUT's lists? I keep forgetting and
replying only to the original poster instead of the list.
Whether or not it is a good idea to setup the 'reply-to' address to that
of a mailinglist has been discussed to death on many lists already. Don't
ask. :-)
Best regards,
Herman wrote:
The UPS itself has a blank Model.: number on the bottom and a little
sticker on its back stating:
0761106
UF-01V2EJX
KE11064267
Made In China
That is quite similar to a model I have here, but which runs with
totally different software (safenet). Probably the people from
I've tried with GenericUPS, had no luck (didn't get any response from the
driver at all indicating it was online (or that serial comms were
happening at all). I'll double check this more in the coming week, it's
possible I have a wrong cable or something.
There will be no feedback, other
I guess. You'll *have* to connect a UPS, otherwise there is nothing to
verify. We already know the genericups driver works with other UPS'es,
so
there is no need to check that. You need to check if it works with
*your*
UPS.
I have a UPS connected, I meant running the driver manually
[...]
I think this output doesn't help very much.
This is very helpful. The problem is not in the connection to the driver,
upd-data_ok switches between 0 and 1. Only the driver can change this
value by repetitively switching between DATASTALE and DATAOK. There is
nothing upsd can do about
[...]
I hope this small part of the log helps.
Maybe someone with more experience with the 'usbhid-ups' driver is able to
decipher what is going on. I'm still waiting for someone to send me a
USB-HID UPS so that I can debug things like this myself.
Best regards, Arjen
here the output of upsd -D when starting upsc [EMAIL PROTECTED]
ups.status (and stopping after 20-30 sec with an ctrl+c)
Ah, you have a problem with 'upsc' rather than with 'upscmd' like you
stated before. That changes things.
Connection from 127.0.0.1
acl_check: localhost: match 1
ACL
I've configured upsd.conf with
[rack1ups]
driver = apcsmart
cable = 940-0024C
port = auto
This won't work. You need to specify a serial port for this driver (see
'man 5 ups.conf' and 'man 8 apcsmart'). Only the 'newhidups' driver
accepts 'auto' (anything
From your tip I did check that - it is indeed a script but as you say,
running it gave no reference to the driver starting. So I found
/etc/init.d/upsdrv and went directly to /usr/sbin/upsdrvctl start
which gave this output:
Network UPS Tools - UPS driver controller 2.0.4
Network UPS Tools
I am using the upscode2 driver with an old powerware ups.
The driver seems slow to start and to spite the message of giving up it
does work. Any thoughts on why it is having trouble synchronizing?
Upgrade to nut-2.0.5. Older versions sometimes suffer from this problem
when starting up the
./upsd -DDD -u root
Network UPS Tools upsd 2.1.0
/usr/local/ups/etc/upsd.conf is world readable
That is bad, fix it.
listen_add: added 0.0.0.0:3493
listening on 0.0.0.0 port 3493
Connected to UPS [mge-nova]: mge-nova
/usr/local/ups/etc/upsd.users is world readable
This is *really* bad,
sstate_dead: didn't hear from driver for UPS [mge-nova] for 0 seconds
Oops! For some reason you decided to set MAXAGE to 0 seconds. Please
read the appropriate section from 'man 5 upsd.conf' again. Do not set
MAXAGE to anything *lower* than the 15 second default.
I included my upsd.conf in
Unfortunately it didn't seem to have any effect. I have taken a debug
of usbhid-ups starting up in case there is some info you need in
there. It's too long to include here so I put it on pastebin:
http://pastebin.com/882071
The startup of usbhid-ups seems to be OK. Could you startup upsd
I'm working with svn trunk rev 815, testing tripplite_usb with this model.
I
haven't gotten far in my testing, but thought I'd notify the list of this
error
message. Is this message of any consequence, and is it worthwhile for me
to
continue testing prior to resolving this? I am happy
Charles Lepple wrote:
Can you send the output of 'upsc [EMAIL PROTECTED]'?
The '@localhost' part is optional for the version in the trunk. So
upsc name-of-ups
will behave the same as
upsc [EMAIL PROTECTED]
Might save you some typing... :-)
Best regards, Arjen
[...]
Also your comment (so the driver only polls the UPS) - does this
mean the UPS will not be able to notify NUT of a power failure as it
occurs, but we'll pick it up next time NUT polls?
As Arnaud already answered, yes. You may want to reduce the interval
between polls by setting 'pollfreq
Apologies, allowfrom is in upsd.users.
What does this mean?
Feb 19 07:58:11 apophis upsmon[533]: [ID 702911 daemon.alert] Master
privileges unavailable on UPS [EMAIL PROTECTED]
Feb 19 07:58:11 apophis upsmon[533]: [ID 702911 daemon.alert] Reason:
Access denied
You need to specify in
as far as I am aware everything is as it should be. Kindly have a look at
my conf files and let me know.
upsd.conf
ACL all 0.0.0.0/0
ACL fileserver 172.16.20.100
This is wrong, you need to add either /255.255.255.255 or /32 (the mask is
not optional). Up to (and including)
I have attached a section of my syslog. It seems to say that newhidups
had a problem on the shutdown part of a restart. But before that upsd is
still running after newhidups has exited.
That is bad. It looks a lot like neither upsd, nor the driver have been
properly stopped before receiving
I looked through the faq, but couldn't find an answer to this.
I'm trying to configure nut-2.0.4-26 on SuSE linux 10.2.
In ups.conf, I have
[myups]
driver = belkinunv
This is the wrong driver. You appear to have an UPS with a USB connection,
while belkinunv is for a serial connected
I tried building nut 2.0.5 pre2 from source using the user=nut and make
usb options, and got the same results.
That's an old version, please don't use that anymore. The latest stable
version is nut-2.0.5. Furthermore, you should specify the same '-u user'
for both upsdrvctl and upsd.
It
The latest version available packaged for Debian that I can find on the
Debian site is 2.0.5-3, the one I've previously had trouble with.
The problems you have don't seem to be related to the anything wrong with
the code, but rather with the configuration. So I'd go with the packaged
version
A.Lizard wrote:
Basically, you need to pass the same system user to -u on both the
driver and upsd.
How?
See 'man 3 upsd'.
Best regards, Arjen
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
Peter Selinger wrote:
Basically, you need to pass the same system user to -u on both the
driver and upsd.
How?
See 'man 3 upsd'.
Or perhaps 'man 8 upsd'.
I really need to go to bed... :-)
Best regards, Arjen
___
Nut-upsuser mailing list
When my kernel oopses (not ups/nut related) nut is somewhat upset and
keeps complaining that power is gone, and restored, etc, etc, etc.
How can I fix this?
Which NUT version? UPS connected through serial or USB? Operating system?
What is the reason the kernel oopes? Is this a one time
When my kernel oopses (not ups/nut related) nut is somewhat upset and
keeps complaining that power is gone, and restored, etc, etc, etc.
How can I fix this?
Which NUT version? UPS connected through serial or USB? Operating
system?
What is the reason the kernel oopes? Is this a one time
Please start by providing some information. What NUT version are you
using, what driver?
The FC6 binary for 2.0.3-2.1.
I use the Mustek PowerMust driver with a Sweex UPS.
Before trying anything else, upgrade to nut-2.0.5. There have been many
bugfixes since nut-2.0.3, including problems with
Udo van den Heuvel wrote:
If I start the daemons manually, following the info at
http://www.networkupstools.org/doc/2.0.1/INSTALL.html The programs start
OK, no error there.
How can I automate this? Why don't the scripts work OK?
Which script did you use? I can only guess that the script is
If I start the daemons manually, following the info at
http://www.networkupstools.org/doc/2.0.1/INSTALL.html The programs
start
OK, no error there.
How can I automate this? Why don't the scripts work OK?
Which script did you use?
The standard scripts that come with the rpm.
We, the NUT
Kevin DeGraaf wrote:
# newhidups -DD -u root -a tl6000
Checking device (09AE/4002) (001/003)
- VendorID: 09ae
- ProductID: 4002
- Manufacturer: Tripp Lite
- Product: TRIPP LITE UPS
- Serial Number: 9533alcps585700043
- Bus: 001
It looks like your UPS is using a different product ID than
Is it possible/advisable to put NUT into production with newhidups
running in exploratory mode?
I'm probably not the most knowledgable person with regard to the newhidups
driver, but I think something in the line of
newhidups -u root -x productid=4002 -x vendorid=09ae -a tl6000
might
Done. If you pull the latest version from the SVN trunk, the usbhid-ups
driver should detect your UPS. Could you let us know if everything works
as expected, so that we can add this UPS to the list of supported
devices?
# ./bin/upsc [EMAIL PROTECTED]
battery.charge: 100
Do you have a chance to switch off the mains to the UPS for a while
(without causing too much grief to the systems it is powering)
I'll be glad to test this (and post the upsc data) when I return to
work tomorrow.
These problems may actually be caused by the driver. It contains logic to
ups.conf is:
[EMAIL PROTECTED] rules.d]# cat /etc/ups/ups.conf
# UPS Conf for NUT
[pulsar]
driver=newhidups
port=auto
desc=Pulsar M2200 RT3U
# vendorid=0463
# offdelay = 180 s
offdelay=180
# ondelay = 30 x 10 = 300 s
Marc Rechté wrote:
I checked the ups.conf and newhidups man pages and could not locate the
pollfreq parameter. Do you mean pollinterval ?
I meant just what I said. For 'newhidups' this is an undocumented
feature, while it has been documented for it's successor, 'usbhid-ups'.
Best regards,
Does the problem occur frequently? The more details, the better.
from there, 3 possibilities (need more details to audit):
- if the problem occurred only once, then you've seen a battery test,
- else you have some electrical problems upstream,
- else the UPS has some internal problem.
A
[EMAIL PROTECTED] wrote:
I can confirm that there is no problem with the UPS and the power line is
stable. I have attached the relevant log file for a run.
Please try if adding the following lines to 'ups.conf' make any
difference (you'd need to restart the driver in order to make these
Charles Lepple wrote:
Arjen, could you please take a look at this?
from 'svn blame' on server/access.c:73:
737 adkorte-guestreturn (IN6_IS_ADDR_V4MAPPED(ip6)
737 adkorte-guestconst u_int32_t *)ip6)[3]
prefix) == net-s_addr));
Is there a more
Charles Lepple wrote:
I thought the error that Zoltan saw might have been due to the next
line (the const u_int32_t bit), but I don't have a Solaris box to
test.
This could also be the case. We don't use 'u_int32_t' anywhere else in
the sources, so this probably should be replaced by
Charles Lepple wrote:
Therefore, you might need to go to the source of the upsc output,
which involves printing the debug information from the driver (adding
-DD to the command line). You may need to wait for more specific help
from Peter or Arjen, but in the mean time, you might want to look
Hello,
I have two SAIS connected to one linux box. I want to monitorize the two
sais, but the NUT only can monitorize ONE. I configure the port in auto
in ups.conf but it only see one.
[MGE1]
driver = newhidups
port = auto
[MGE2]
driver = newhidups
port
Hello,
I installed NUT and configured it for 2 MGE UPS's connected via USB.
Debian etch NUT package:
# dpkg -l nut*|grep ^ii
ii nut 2.0.4-3The core system of the nut - Network UPS Tools
ii nut-usb 2.0.4-4USB Drivers subsystem for the nut - Network UP
Before anything else,
There is a memory leak in newhidups. After 23 days uptime it used 138M
memory. Apart from the memory leak, the system works ok.
Is there anything I can do to help fix this problem?
Sure. Please upgrade to the latest version and see if the problem still
exists. The version you're using now is
Theo G. Kanter wrote:
Thank you Arjen for pointing this out. After reading up on the man pages,
I also fixed the MONITOR line in upsmon.conf to pointing to [powerware] as
defined in ups.conf.
Ooops. I missed that one, but you've found that out yourself already. Good!
So I redid this having
Tor Sjøwall wrote:
After updating from NUT 2.0.3 to 2.0.5 I got this error from upsd
during startup:
Can't connect to UPS [myups] (myups): No such file or directory
The problem was that newhidups created a pipe on
/var/run/nut/newhidups-auto while upsd was looking for
/var/run/nut/myups.
This list is for the Network UPS Tools (NUT) software, but this log
looks like it is from something else entirely.
The RPMs listed on rpmfind.net for RH9 seem very old, so you will
probably need to compile from source:
http://www.networkupstools.org/source.html
Then, since your UPS is not
THANKS, but the 'megatec' driver only works whith windows OS via USB,
and i need it for red hat OS with USB-serial connection...
No need to be upset, what Arjen de Korte was referring to was that the
ups use the megatec protocol.
Yes. And since you appear to be using a USB-to-serial
I notice from the hardware compatibility list that the XR model is
supported - what are the chances that the older R3000h models are too?
Apparently, this is a rackmount Powerware 5119 which is supported by
'genericups upstype=15' in dumb mode. Google tells that in smart mode,
this UPS speaks
The compatibility list in the SVN repository trunk mentions that the
T1500h needs the use_pre_lf option. Did you find that this was
necessary for your UPS?
No, I didn't use that option. Mind you, I have not yet fully tested
everything - I still have a few things to configure, do a complete
upsc:
battery.charge: 97.47
battery.runtime: 600.000
battery.voltage: 0055.20
battery.voltage.nominal: 0048.00
driver.name: upscode2
driver.parameter.port: /dev/ttyS0
driver.version: 2.0.5
driver.version.internal: 0.84
input.voltage: 0230.20
input.voltage.maximum: 0276.00
I've got a setup with NUT, where we've got two UPSes,
ups1 and ups2. UPS1 supports our servers, while UPS2
supports our desktop boxes. We monitor both of them
via USB on a box now called upsmon.
The interesting point comes here. We monitor both
UPSes on the upsmon box, but if UPS2 fails,
1 - 100 of 770 matches
Mail list logo
