Charles,
You are a genius! Don't know why I didn't google "socket permission
denied" before reading this response. But I did it just now and found
this post
<https://stackoverflow.com/questions/36451444/what-can-cause-a-socket-permission-denied-error>
which was right on target. I did a "groups nut" and discovered that the
nut user was not in the group aid_inet (and saw that the root user was a
member) which is required for socket access. So I added nut to that
group and fired up upsmon in debug mode. I can not see both server and
client sides of the socket using "netstat | grep nut". Not sure if the
problem was client or server side without this (seems likely both, I
guess) but no more problems! This even survives a system restart. So I
think I am good to move on. Thanks so much for everyone's time and
effort in helping me. I can now start pulling the UPS plug out of the
wall and see what happens!
Cheers
On 7/15/2019 8:04 PM, Charles Lepple wrote:
On Jul 15, 2019, at 11:15 AM, David White wrote:
2. When I check the results from "netstat -t -n" I am NOT finding anything on 3493. Hmmm. I then
tried "netstat -l" since there should be a server socket listening on 3494, right? There is nothing
of 3493. But I do see an entry with local address = localhost:nut. When I "cat /etc/services" I
find nut listed on 3493.
Mistake on my end; I was thinking "netstat -tln" or "netstat -atn". Without the "-n", it
looks up "3493" in /etc/services, as you mentioned.
3. So I run "netstat -l | grep nut" and I see the socket and I see an entry for
what looks like a stream listener tied to /var/run/nut/blazer_usb-belkinusb.
This should be there, but it's the Unix-domain socket (not TCP) between the
driver and upsd, so not relevant at the moment.
4. I did not know of the -DD option on upsmon and likely would not have thought
of this anyhow. In the output I almost immediately see a connection failure to
belkinusb@localhost for the socket saying permission denied. That doesn't look
right. But not exactly what that means or how to fix it.
I am still confused as to why upsc works, but maybe this is related?
"Android adds a "paranoid network" option to the Linux kernel, which restricts
access to some networking features depending on the group of the calling
process. This option should not be set in any other OS not using Android
security model - because it requires 4 groups with specific UIDs (3001-3005)
to exist, and all relevant users to be added to them - which in our case would
be all users anyways, as that's the "traditional" behavior."
https://github.com/AsteroidOS/meta-bass-hybris/commit/b819096ed5a5ef12828c63b1f2f0b8e962fd1e81
More info:
*
https://wiki.postmarketos.org/wiki/Kernel_configuration#CONFIG_ANDROID_PARANOID_NETWORK
* https://elinux.org/Android_Security#Paranoid_network-ing
If you can get to the kernel config for the Android side of things, you can
check for that CONFIG_... option. If it is enabled, then maybe there is
something different about the user ID that upsmon is running under versus upsc.
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
