[Nut-upsuser] Tripp Lite OMNI1000 LCD issues

[John Darrah]

On Sun, Mar 30, 2008 at 10:14:03AM +0200, Arjen de Korte wrote:
> 
> > The only reference to "/var/run/nut" in the strace is a
> > chdir("/var/run/nut").
> 
> That's where the driver has just dropped priviledges (line 537 in
> drivers/main.c) and just before it sets up the signals (line 540).
> 
> > Does it create the socket after this this chdir?
> 
> Yes, but *way* after that in dstate_init (line 562).
> 
> > What would the strace show upon executing the socket creation?
> 
> Unless you know what your looking for, strace isn't particularly useful.
> We prefer debug output over strace most of the time, unless the debug
> output is inconclusive. The debug output has the advantage that it shows
> context in a meaningful way, at least for developers like me that deal
> with this almost in a daily basis.
> 
> The call to 'dstate_init(progname, upsname)' will create a socket that is
> named 'usbhid-ups-trippy', most likely in /var/run/nut, where you should
> also see a PID file (line 573) named 'usbhid-ups-trippy.pid'. Again, make
> sure that the user running the driver is allowed sufficient access to the
> /var/run/nut directory. Setting the permissions bits right is just one way
> that access might be limited. I don't know if Debian has something similar
> like AppArmor for instance, which might prevent a process (rather than a
> user) access to certain resources.
>

I have determined that the socket is not being created. Even 
with -DDDD the following is never executed:

upsdebugx(2, "dstate_init: sock %s open on fd %d", sockname, sockfd)

With the driver running if did a "find /var /usr /lib /tmp -type s" and
no sockets were found with the appropriate name you noted above.

I should be able to see the string 'dstate_init' in both the 
debug output and the strace. It's just not there. Looking at 
the source, I can't see how it could be skipped.

So... I've downloaded the debian source package and required 
build packages. It seems to build OK, so I am going to be
inserting my own debugging using "upsdebugx" at each point 
around where the socket is created and try to figure this out.

As for the issue of driver ignoring all signals except 
SIGKILL, I can see in the strace that the following signals 
are setup right after the chdir:

.
.
setgroups32(1, [0])                     = 0
setgid32(0)                             = 0
setuid32(0)                             = 0
chdir("/var/run/nut")                   = 0
rt_sigaction(SIGTERM, {0x8050440, [], 0}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x8050440, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x8050440, [], 0}, NULL, 8) = 0
rt_sigaction(SIGHUP, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
.
.

I'll try to sort this whole thing out, but I may have some 
more questions.


Thanks

-- 
john