[Nut-upsuser] Tripp Lite OMNI1000 LCD issues

[Arjen de Korte]

John Darrah wrote:

> 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.

That is bad news. The code that deals with the creation of the listening 
socket hasn't essentially changed in at least three years time. So the 
chances that we're dealing with a regression in the NUT code are slim. 
Before trying anything else, I suggest to try out an older version of 
NUT (one that you *know* once worked on your system) and see if it still 
does in your current environment. My bet is, that it won't and that you 
should be looking elsewhere for the cause of the problems you're seeing now.

[...]

> 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

See lines 416-435 in 'drivers/main.c' where we setup the signal handler 
for these signals. Basically all that happens, is that we set a flag 
that tells the driver to break from a loop. There is nothing wrong here 
and similar like the socket code mentioned above, this hasn't changed in 
at least three years.

Best regards, Arjen