2011/4/18 Virus <753...@bugs.launchpad.net>
> It`s working great! Many thanks!
>
excellent, thanks for the feedback.
I've just committed it upstream (r2972)
the changeset will be available on the NUT Trac mirror (just give it some
minutes to sync):
http://trac.networkupstools.org/projects/nut/ch
2011/4/18 Virus <753...@bugs.launchpad.net>
> yes, it 100 % reproducible.
>
I also managed to reproduce it using dummy-ups (the simulation driver) and
injecting the error on the same variable:
adding a newline (ie "\n") results in a broken pipe on upsc side.
> i am ready to test svn version.
>
so what if you issue again an "upsc powercom"?
does it still broke the pipe?
is your issue 100 % reproducible?
my guess, is ATM, that the faulty end-of-line marker in battery.type is
causing parseconf to close prematurely the connexion, while upsd is still
sending data.
which explains why unit req
2011/4/16 Virus <753...@bugs.launchpad.net>
> $ upsc battery.type
> Error: Unknown UPS
> $ upsc ups.status
> Error: Unknown UPS
>
damn, I missed a bit (ie the "device name"):
$ upsc powercom battery.type
Error: Unknown UPS
$ upsc powercom ups.status
Error: Unknown UPS
don't forget to run upsd in
2011/4/16 Virus <753...@bugs.launchpad.net>
> Seems driver respond correctly, but upsd return "Broken pipe" after:
> 25.768861 write: [destfd=6] [len=35] [VAR powercom battery.type "PbAc
> "]
>
> Two lines?
>
>
yup, but upsd sends everything. and upsc brokes the pipe.
the driver is still ther
