Peter Selinger wrote:
I am not saying that you are wrong; only that this particular behavior
should be reconsidered. You are right that when you changed the
default to 20 seconds, you only followed what was written on the
usbhid-ups man page all along. However, browsing the man pages, I
there are definitely wrong (at least fallback) declarations in mge-hid.c
as an example, we should try to map the below 2nd one as a fallback
since it's really the nominal *output* voltage, not the battery one:
{ battery.voltage.nominal, 0, 0, UPS.BatterySystem.ConfigVoltage,
NULL, %.0f,
Can you post a full listing of the driver running in debug level 2?
I think that's here... should I do something different than what was
in the 2nd attachment in the message below?
Ooops. I forgot that you already did. Never mind. From the HID paths that
indicate a voltage, only the following
as you already know, Flow.[4] is the output one (and Flow.[1] the input).
Both are *always* available.
This is what I expected. That means that we can rely on this for setting
'(input|output).voltage(.nominal)' and don't need fallbacks here.
Which is not the case of the battery voltage.
I
Charles Lepple wrote:
Could this be related to the Evolution 650 bug mentioned in
mge-hid.c? (On the other hand, I suspect that if I added my model to
that function, it would only fix the battery.voltage.nominal)
I checked with Arnaud. The 'Pulsar Evolution' series doesn't support
measurement
Arnaud Quette wrote:
The only cosmetic remark I have (and I don't recall if it was prev.
there) is the non sorted list of commands that upscmd outputs...
The commands are put into a linked list, where the first command in the
list will be shown first by NUT. The 'usbhid-ups' driver will
btw, would you be interested in working on the configuration?
Not at the moment. There is still a lot of work to do in the clients, main
driver body and the server (in this order). I'll work my way through all
these, but this is going to take a fair amount of my time.
It's nice to see the
I think that is the best thing to do. So I'll just remove the alarm()
mechanism from the clients, since that's become obsolete now that we
have non-blocking read/write that provides a much cleaner interface.
ok
I'm preparing -pre2. Is it ok for you?
Yes. I found that the only client that is
What is going on here? I'm trying to commit a change, but it
(repeatedly) fails, so apparently there is something wrong:
Commit failed (details follow):
Base checksum mismatch on '/branches/Testing/packaging/opensuse/nut.spec.in':
expected: c7ab1364e6e2f7263633c3fc4847619c
actual:
I guess this means we won't have access to SVN, right? Is there a timeline
available when this will be fixed? Sadly enough, my keys were generated on
an openSUSE system and are probably not affected by this vulnerability
anyway.
Best regards, Arjen
--
Eindhoven - The Netherlands
Key fingerprint
Password-based authentication is where the SSH client (used by SVN)
prompts you for a password, instead of using your keypair.
The only other hitch is that because they changed the alioth SSH host
key as well, you will probably see messages like this:
IT IS POSSIBLE THAT SOMEONE IS DOING
I've just noticed that cpsups isn't listed anymore in driver.list.
Indeed.
Any reason not have removed it from the source too?
No. Amnesia?
Still on the way to 2.4; any update on your confidence level to remove
nitram and cyberpower too?
The 'powerpanel' driver is supposed to replace
The tripplite driver was developed on a machine with a reliable serial
connection, and inherited the assumption that the serial line connection
would not drop, reorder, or fail character read and writes. This patch
adds significantly improved failure mode handling and also does basic
checks
On a test shutdown of an APC Back-UPS RS1500 upsc was run periodically
to follow the UPS discharge, it showed these values:
battery.low 120
battery.charge.low 10
As it turned out, the battery.charge.low was encountered first and the
system shut down there. However, considering the rate
Is that normal behavior? At what point does the UPS get shut off to
protect the battery from total discharge? I'll confess I am fairly
ignorant about what's supposed to happen here, but I understand you
don't want to let these batteries go completely dead.
I suggest that you first read the
I thought they might measure it fairly accurately in order to calculate
time remaining on the battery.
Usually the time remaining on battery is either based on the battery
voltage (cheap) or by counting coulombs (expensive). Both are measured on
the *input* of the inverter. In retrospect,
I saw your email here
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-October/000243.html
about the Liebert UPS protocol and I was wondering if it actually got
in the NUT tree?
Maybe. I couldn't find a conclusive answer in the thread you mentioned.
I had a look in the 2.2.2 tree
[...]
I see a lot of kernel warnings because there are two processes that
access the device like this:
usbfs: process 19727 (usbhid-ups) did not claim interface 0 before use
usbfs: process 19862 (hald-addon-usbh) did not claim interface 0 before
use
My question: is this due to my kernel
You are correct, I have let myself be totally misled by the Fedora
packaging, which I followed. It not only packages the hal-addons in
one package with all the other drivers.
That is bad... :-(
In addition, if an appropriate
UPS is present, the proper hal-addon will automatically be
I just went back to look at the nut-2.2.2/packaging directory, and
found that the redhat subdirectory has not been updated since nut-2.0.5.
This is incorrect, I updated it a little over a year ago to fix another
packaging error.
This is of course before the introduction of the hal-addon's.
[EMAIL PROTECTED] wrote:
[...]
Is there a document that takes me thru the parsing of the text data
from the UPS and what is done with it. I can't find anything in
cpsups.d that indicates where process death occurs. In fact, the
Driver exited abnormally. is coming from upsdrvctl. This
As a second layer of defense, how do you all feel about the TCP
wrappers functionality in libwrap? As I understand it, the
hosts.allow and hosts.deny files offer the same level of granularity
that the NUT ACL functionality provided, but with the advantage of a
more well-known (and hopefully
Citeren James Harper [EMAIL PROTECTED]:
I got a chance to quickly test this. upsc output is:
[...]
input.voltage: 248.1
input.voltage.nominal: 230
[...]
output.voltage: 218.0
output.voltage.nominal: 230
[...]
ups.status: OL TRIM
all the numbers seem reasonable. In Australia we run
Citeren ng-sup01 [EMAIL PROTECTED]:
I am trying to get an Atlantis-Land 1501 UPS to work under OpenBSD.
The UPS works OK under Linux + megatec_usb driver+nut_2.2.2.
[...]
And, finally, here's a clip of my ups.conf file:
[...]
[atlantisland]
driver = usbhid_ups
port =
Citeren Charles Lepple [EMAIL PROTECTED]:
You could probably change this through 'upsrw', if the subdriver would
allow it (which it currently doesn't). I'll volunteer to do this, if
you can send me the first 30 seconds worth of output when running the
driver with '-DD' (debug level two, *not*
Citeren Ric Anderson [EMAIL PROTECTED]:
Log generated by
/usr/local/ups/bin/usbhid-ups -DD -x explore -a su700 21 | tee sua750.log
is attached as a gzip file.
Checkout the latest version from the trunk (r1528). Although this
board seems to have two ambient probe inputs, this currently only
Could you please send the output you send before in a different
character set? Preferably US-ASCII of UTF-8. Somehow I can't seem to
open them.
Best regards, Arjen
--
Please keep list traffic on the list
___
Nut-upsdev mailing list
Citeren Arjen de Korte [EMAIL PROTECTED]:
Could you please send the output you send before in a different
character set? Preferably US-ASCII of UTF-8. Somehow I can't seem to
open them.
Never mind, I didn't properly unpack them. All is well.
Best regards, Arjen
--
Please keep list traffic
Citeren Arjen de Korte [EMAIL PROTECTED]:
do you want to create the new subdriver, then? (I probably wouldn't
have time to do it until early next week, anyway.)
Yes. I just remembered that we already have a debug log for this
device (at debug level 10, so I'll have to weed out the excess
Citeren Arjen de Korte [EMAIL PROTECTED]:
OK, it's in the trunk now. It would be nice if James could check if it
works and if he's able to change the nominal output voltage through
'upsrw'. I took the liberty to assume this would work in a similar
manner as my MGE Evolution (I have quite
Citeren Charles Lepple [EMAIL PROTECTED]:
In retrospect you were absolutely right with your observation that this
looks like a Tripplite device. Looking at the similarities (manuals,
pictures) there is little doubt that this is a re-branded Tripplite
SMART2200RMXL2U. Therefor we should
Citeren James Harper [EMAIL PROTECTED]:
What is the command I should use to try and set the output? What will
the interaction be with the dip switches on the back of the device which
set the expected input voltage?
None. I missed the fact that this is set by dipswitches on this device
and
Citeren Charles Lepple [EMAIL PROTECTED]:
On Wed, Sep 24, 2008 at 2:27 PM, Arjen de Korte
[EMAIL PROTECTED] wrote:
- /* Server side variables */
- { driver.version.internal, ST_FLAG_STRING,
sizeof(DRIVER_VERSION), NULL, NULL, DRIVER_VERSION, HU_FLAG_ABSENT,
NULL
Citeren Jim Paris [EMAIL PROTECTED]:
I got a new Cyberpower 1500AVR UPS and nut wouldn't work. It failed
to detect the UPS and a strace showed that all writes to the serial
port were failing with -EAGAIN. The attached patch disabled
nonblocking mode on the serial port and now it works fine.
Citeren [EMAIL PROTECTED]:
Adding the -x productid=3014 as you suggested did not work. Here's what
the driver dumps out.
[EMAIL PROTECTED] ups]# bin/usbhid-ups -a ups01 -DD -x productid=3014
Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2)
debug level is '2'
Citeren Arnaud Quette [EMAIL PROTECTED]:
Attached is a patch adding support for tripplite's avr750u UPS.
Issues:
* productid still needs to be specified in ups.conf
you missed to add an entry in drivers/tripplite-hid.c
-tripplite_claim() for that ;-)
And beware that you need to put it in
Citeren Raphael Geissert [EMAIL PROTECTED]:
Attaching the output of usbhid-ups -.
That sucks... :-(
This device doesn't seem to report any measured voltage value, so I
wouldn't be surprised if the battery charge would something like an
online/onbatt flag too (100% @ online and 0% @
Citeren Arjen de Korte [EMAIL PROTECTED]:
- We could manage a full power chain of UPSs and RPCs, and add some
smarter/advanced features (like subscribing clients (nut slaves
installed on computers) on a specific outlet, and have these shutdown
earlier than others before putting the outlet off
Citeren Carlos Rodrigues [EMAIL PROTECTED]:
So the actual problem is the nominal battery value being used to scale
the graphics?
Yes. If 'battery.voltage.nominal' is not provided by the driver, it
attempts to guess this based on the 'battery.voltage'. But the latter
doesn't work for higher
Citeren Luiz Angelo Daros de Luca [EMAIL PROTECTED]:
However, as the nominal battery is 240V, NUT battery graphic is not very
useful. I uses an scale up to 240V and
2.27V (AC on) or 2.0xV (AC off) is not visible. If I divide the nominal
voltage (hack) by 120, NUT avoids to generate a graphic.
Charles,
It looks like the buildbot no longer builds (if it ever did, I don
remember) the HAL addons, even if the requirements are met:
configure:9680: checking for libhal version via pkg-config (0.5.8
minimum required)
configure:9690: result: 0.5.11 found
configure:9694: checking for libhal
Citeren Carlos Rodrigues [EMAIL PROTECTED]:
BTW, the patch has a small typo in one of the comments: applied to
battery.volage :)
I'll leave that up to you to correct. Since it is only a comment, it
won't be visible to innocent users anyway. :-)
What we might want to do, is to change the
Citeren Arnaud Quette [EMAIL PROTECTED]:
I thought buildbot was using distcheck... so --with-all which results
in also building hal support code.
Isn't it the case?
It is, I was looking at the config.log and should have looked at the
log file of the compile stage. HAL is being build there.
Citeren Carlos Rodrigues [EMAIL PROTECTED]:
The attached patch adds a battvoltmult parameter to the megatec
driver in the trunk.
It should work, but I'm away from a development environment, so it is
totally untested (it wasn't even compiled to check for syntax errors).
The changes are
Citeren Arnaud Quette [EMAIL PROTECTED]:
that's 1 of the 2 main use cases here.
the other being that upsmon could monitor
outlet.X.autoswitch.charge.low (where X is the outlet on which we
subscribed the slave) against battery.charge to launch the shutdown
without the need of upssched.
I'm
Citeren Charles Lepple [EMAIL PROTECTED]:
Is there a specific piece of code I
should try hacking? tripplite_usb? Or, something higher up?
[...]
Things specific to the Tripp Lite PDC UPSes are in tripplite-hid.c,
and there are some more generic parts in usbhid-ups.c, libhid.c/h and
Citeren Sergiy Yegorov [EMAIL PROTECTED]:
just to be sure, for other users: what is the name of the port you've
indicated in ups.conf (my guess is ttyUSB0 since the powercom driver
has no real USB support)?
Sure, it is /dev/ttyUSB0 via cypress_m8 kernel driver.
That's something that's hardly
Citeren Zeljko Baralic [EMAIL PROTECTED]:
This gets me to megatec driver and how it see battery voltage. I
think that this is job for someone to improve megatec driver in
order to look at some table to see battery charged value or to
create it with parameters to driver.
Thanks for this
Citeren Zeljko Baralic [EMAIL PROTECTED]:
You can't calculate battery charge of a
UPS by looking at the battery voltage alone
It physically just isn't possible.
But we may get some very close values with accuracy of maybe 90%.
Read the above remark again. Not by looking at the
I would like to rename the following variables in docs/new-names.txt:
ambient.temperature.alarm.maximum
ambient.temperature.alarm.minimum
ambient.humidity.alarm.maximum
ambient.humidity.alarm.minimum
to
ambient.temperature.high
ambient.temperature.low
Citeren Arnaud Quette [EMAIL PROTECTED]:
can somebody recall me with we have a such entry in the HAL .fdi,
hotplug and udev files?
Probably because of the following threads:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-September/000150.html
Citeren Charles Lepple [EMAIL PROTECTED]:
I haven't looked into this much, but do we want to remove some of the
generated files from SVN, and have the build process generate them
every time? This would ensure that they are always up-to-date.
I think we should, this is as far as I can see the
Citeren David C. Rankin [EMAIL PROTECTED]:
I went ahead and installed the 2.2.2 rpm even though it doesn't have the
/etc/init.d/upsd file so I could get the information you needed.
You'll need to install
Citeren Royce Williams [EMAIL PROTECTED]:
Externally, the G1000U looks much like the SMART1000LCD: an amber
LCD, jacks for coax and telephone, four protected receptacles and
four non-protected, and a USB-only interface. Internally, it's
product 2007, vendor 09ae.
That combination is indeed
Citeren David C. Rankin [EMAIL PROTECTED]:
I have the fully charged voltage for the ups battery:
Voltage (full charge): 13.72 Volts
And what was 'upsc' reporting at the same time? Without that, this
doesn't help much. In order to correct the reported value, we need
both the reported and
Citeren Charles Lepple [EMAIL PROTECTED]:
Another thing, loosely related to this, is how we are going to deal with the
'generic' VID:PID combinations in some of the USB drivers, for example the
megatec_usb and (new) blazer_usb drivers. At present, in the megatec_usb
driver we have several
Citeren Charles Lepple [EMAIL PROTECTED]:
I meant to add that I, too, am against supporting bogus VID:PID
combinations in the HAL drivers.
Not only that, but we also shouldn't support (though HAL addons)
legitimate VID:PID combinations if these do not uniquely identify a
supported UPS. For
Citeren David C. Rankin [EMAIL PROTECTED]:
Discharged battery.voltage:
17.4 Volts - (indicated on shutdown, discharging battery.charge 77%)
16.9 Volts - (indicated on shutdown, discharging battery.charge 51%%)
16.6 Volts - (indicated on shutdown, discharging battery.charge
Citeren Arjen de Korte [EMAIL PROTECTED]:
[...]
Please try if changing line 426 in drivers/megatec.c from
ser_send_pace(upsfd, SEND_PACE, Q1%c, ENDCHAR);
to
ser_send_pace(upsfd, SEND_PACE, D%c, ENDCHAR);
[...]
Best regards, Arjen
--
Please keep list traffic on the list
Citeren Adrian Czerniak [EMAIL PROTECTED]:
1) The UPS is implementing a *very* old version of the Megatec
protocol and uses the 'D' command to query for status information
(this was obsolete back in 1996 already). Please try if changing
line 426 from
ser_send_pace(upsfd, SEND_PACE,
Citeren Tom Cassimon [EMAIL PROTECTED]:
[...]
Checking device (0925/1234) (007/002)
- VendorID: 0925
- ProductID: 1234
- Manufacturer: ?
- Product: UPS USB MON V1.4
- Serial Number: unknown
- Bus: 007
Trying to match device
Device
Citeren Charles Lepple [EMAIL PROTECTED]:
And what about suggestion #2? I'm starting to doubt that this device
speaks Megatec...
shouldn't the log have references to the D command instead of Q1?
No. The debug messages are hardcoded and I only asked to modify the
command that is send to the
Citeren Stanislav Brabec sbra...@suse.cz:
On the other hand, I'm hearing a number of don't do that replies, so
instead, what should we put into the SUSE-specific portion of our
documentation to point people to your SRPMS (as Arjen suggested in
another reply)?
I agree with that don't do that
Citeren Charles Lepple clep...@gmail.com:
Since we do not have many developers who use the *.spec files
(although Arjen keeps the openSUSE directory up-to-date), I am not
sure if we are doing the packagers a disservice by shipping old
package descriptions. We try to keep the version numbers
Citeren David C. Rankin drankina...@suddenlinkmail.com:
I did it. With the battery half-way out, still connected, and with the
multi-meter leads securely in the connectors, I got the right data this time.
As before, when you get time for a patch, I'm more than happy to
test. The data is:
Citeren Arnaud Quette aquette@gmail.com:
I'm not too much in favor of directing people to SRPM/websites in the
sources. This is something that is much too volatile so I think we'd
better keep this on the website (and make sure we update them
regularly). What we distribute should be static
Citeren Peter van Valderen dosper...@gmail.com:
I was not aware that it had been imported into the trunk. Last time I
looked noone seemed to have done anything with the driver or have any
interest, so I figured there was no point. If there's any real
interest in keeping it in the trunk, I can
Citeren Peter van Valderen dosper...@gmail.com:
Depending on the amount of work that needs doing, I'll probably do it.
May be useful to know which of the things you posted earlier still
need doing after what you did earlier today.
Well, r1648 in branches/Experimental should fix almost all of
Citeren Charles Lepple clep...@gmail.com:
Also (and this is mostly for Arjen), should we build
branches/Experimental in Buildbot? Would it make sense to have two
boxes per platform - one for the trunk, and one for experimental?
I would prefer not to.
Now that trunk is being used to extract
Citeren David C. Rankin drankina...@suddenlinkmail.com:
I know you are busy, but I was curious if you have had the chance to install
11.1 yet and see if you could confirm whether this problem was with
me or with the package permissions? No hurry, I was just curious.
I just finished
Citeren Kirill Smelkov k...@mns.spb.ru:
[...]
Yes, All the world is not an x86 Linux box, and I've tried to make all the
world happy.
I raised several other issues as well, of which the most important one
isn't addressed. The driver still uses 'alloca' which isn't portable
(it is not in
Citeren Tom Cassimon t...@cassimon.mine.nu:
No problem, i've tried the new version from the trunk
and it compiles without a problem.
Good. Could you post the 'config.log' here, so that we can verify that
this part works as intended? Did you also verify the 'richcomm_usb'
driver?
Best
Citeren Tom Cassimon t...@cassimon.mine.nu:
I've tried the newest version from the trunk, compiled it, installed it. And
using the richcomm_usb driver with my Sweex 1000VA UPS works perfect.
Good to hear that. In that case, we'll leave it in the trunk so that
it will be part of the next
Citeren Fr3ddie fr3d...@fr3ddie.it:
Sorry for that, I have seen that option right after I sent the mail.
So the question now is: can I set only the upper limit for the battery
voltage, something as battvolts=:13.60?
No. See also the comments about BATTERY CHARGE in 'man 8 blazer' (the
Citeren Arnaud Quette aquette@gmail.com:
it then depends on what you want to follow, and possibly if you want to help
more (ie by providing a buildbot, contributing, ...)
Since we already found something that worked on all of the active
buildbots, but failed on your system, adding your
Charles,
When running autoreconf in the trunk, I get a couple of additional
files since I upgraded to openSUSE 11.1. Most likely, this is due to a
newer version of the auto(whatever) tools that are used. Or I never
looked at this more closely before.
libtoolize: putting macros in
Citeren Charles Lepple clep...@gmail.com:
Interesting, I hadn't noticed that. I wonder if it's just because
packagers tend to enable almost everything?
It probably has to do when these are evaluated. WITH_FOO is set
through AM_CONDITIONAL and is used in Makefile.am files. In contrast,
Citeren Charles Lepple clep...@gmail.com:
I will commit this in the next few days, but I wanted to give the
driver authors a chance to comment.
[...]
* Small wording and punctuation changes to man/blazer.8
I'm good with these changes.
Happy New Year,
Arjen
--
Please keep list traffic on
Citeren David C. Rankin drankina...@suddenlinkmail.com:
# Package provides driver for USB HID UPSes, but people can live
with hal addon:
Enhances: %(set -x ; echo %{QUOTE}%{USBDRIVERS}%{QUOTE} | sed -n
s/^HALD-ADDON-USBHID-UPS=//p | tr '%{BACKSLASH}n' ' ')
# Package provides the only
Citeren David C. Rankin drankina...@suddenlinkmail.com:
snip
Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x0a,
Offset: 0, Size:
8, Value: 20.30
Looks like the fix in r1627 didn't stay fixed :-(
Not at all. What you're seeing is a debug line that tells us what the
UPS
Citeren Arjen de Korte adkorte-gu...@alioth.debian.org:
Author: adkorte-guest
Date: Thu Jan 15 11:54:05 2009
New Revision: 1728
Log:
Another stab at this.
Modified:
trunk/tools/Makefile.am
And failing miserably... :-(
Can someone more fluent in 'autotoolish' fix this problem
Citeren Arjen de Korte adkorte-gu...@alioth.debian.org:
Author: adkorte-guest
Date: Thu Jan 15 20:02:22 2009
New Revision: 1734
Log:
Freshly generated USB helper files
Modified:
trunk/scripts/hal/ups-nut-device.fdi.in
trunk/scripts/hotplug/libhid.usermap
trunk/scripts/udev/nut
Citeren Arnaud Quette aquette@gmail.com:
Ethernet interfaces are similarly cheap ( $3). Unfortunately, the
products weren't initially designed with them in mind, so what you
get for your $100-$300 is a computer on a card that has an ethernet
port on the back.
the problem here is that
Citeren Arnaud Quette aquette@gmail.com:
about the filtering, I thought Arjen already applied the 2nd macro over
USB_DEVICE...
Not yet, since I don't think we already reached a consensus on which
devices should go into which script. Basically, there are three
categories:
1) valid
Citeren Marian Ciobanu ci...@inbox.com:
1) I was hoping for upsc to show more values, e.g. battery charge, or
input/output current. I understand this is not a top-of-the-line UPS,
but I wonder if the values currently returned by upsc are all that one
could get, or maybe some fiddling with the
Citeren Marian Ciobanu ci...@inbox.com:
Arjen, I did look at blazer's man before my first post, but my question
was not really answered there. Since this UPS got supported so recently,
and no Mustek appears in the man page, it seems possible to me that MAYBE
it would report the charge status,
Citeren Marian Ciobanu ci...@inbox.com:
The blazer manual warns that using a linear approximation based on
voltage is quite inaccurate. So I think it is improvable.
Indeed. It also explains the reason why you can't use battery voltage
in that calculation. Although you efforts to improve this
Citeren Elio Corbolante elio...@microdowell.com:
629 dstate_setinfo(ups.realpower, %d,
(int)((float)(p[4]*256 + p[5]) * 0.6)) ;
This suggests a fixed relationship between apparent and active power.
This might be the case for the nominal values, but this is not true in
Citeren Arnaud Quette aquette@gmail.com:
Kjell,
have you taken a look at that one?
-- Arnaud
I (attempted) to fix this in r1763. Since I don't own (or have access
to) a compatible UPS, I couldn't test this. But as far as I can see,
it should work again.
Best regards, Arjen
--
Citeren Kjell Claesson kjell.claes...@epost.tidanet.se:
I have the same problem as Arjen. I only have bcmxcp compatible ups.
But the r1763 commit look's OK. Calling the upsc_commandlist() function
should set the can_upsd and can_upsc.
I had mixed feelings with this and also considered
Citeren Des Dougan d...@douganconsulting.com:
A client of mine has an APC Back-UPS 350 model (USB connected). His
office had a power incident yesterday, where there was an interruption
of about 30 seconds. During that time, the server shut down. As soon
as it went on battery, the daemon
Citeren Arnaud Quette aque...@alioth.debian.org:
Modified: trunk/drivers/tripplite-hid.c
==
--- trunk/drivers/tripplite-hid.c (original)
+++ trunk/drivers/tripplite-hid.c Sun Mar 1 19:56:31 2009
@@ -84,6
Citeren Arnaud Quette aquette@gmail.com:
I can't remember, were we moving towards or away from UTF-8?
I can't recall any such move, but toward UTF-8 would be a better bet for the
future!
The latter is probably true for the documentation, but I'm reluctant
to state so for the C sources.
Citeren Kjell Claesson keyson-gu...@alioth.debian.org:
Author: keyson-guest
Date: Mon Mar 23 17:37:37 2009
New Revision: 1817
Log:
data/driver.list, add Eaton Powerware 9130 compatibility with bcmxcp
and usbhid-ups.
1) Is this really true? I would have expected that this device would
Citeren Daniel O'Connor docon...@gsoft.com.au:
I have had a long standing problem with NUT talking to 110V MGE UPSs on
FreeBSD, I was recently investigating again and noticed that upsd seems
overly noisy, eg..
May 5 03:50:36 egbert upsd[96662]: UPS [ups1] data is no longer stale
May 5
Citeren Charles Lepple clep...@gmail.com:
I think I would really prefer that upslog didn't keep the log file open,
that way it doesn't matter if the log file is rotated.
I'm starting to come around to this idea. For some reason, I thought
the upslog program went into the background for a log
Citeren Daniel O'Connor docon...@gsoft.com.au:
Even over NFS it would be trivial.
If you have flash and you're worried about excess writes it won't make a
difference.
How can you be so sure? NUT runs on many different configurations and
platforms.
I think it's more likely someone will
Citeren Daniel O'Connor docon...@gsoft.com.au:
Obviously I can't prove a negative, but I find it extremely unlikely it
could possibly be an issue on ANY platform, embedded or otherwise.
Well, one thing is that it *will* cause existing installations to
break, where upslog is started as
Citeren Daniel O'Connor docon...@gsoft.com.au:
Well, one thing is that it *will* cause existing installations to
break, where upslog is started as 'root' and the NUT user doesn't
have write permissions to the log file. Obviously, send upslog a
SIGHUP in such case would effectively kill it
Citeren Charles Lepple clep...@gmail.com:
I'm btw wondering if we should pass the debug flags to the driver
in such a case...
comments?
Agreed - we have been telling people to use upsdrvctl and enable
debugging, and the two messages conflict with each other somewhat.
I'm slightly
1 - 100 of 353 matches
Mail list logo
