myDevices.log shows nonstop "access denied"

Bugs / Issues Resolved
1

2016-12-06 18:55:37 - myDevices - ERROR - Exception on pid:52
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/myDevices-0.1.20741-py3.4.egg/myDevices/os/services.py”, line 83, in Run
processInfo.Exe = p.exe
File “/usr/local/lib/python3.4/dist-packages/psutil-0.5.0-py3.4-linux-armv7l.egg/psutil/_common.py”, line 75, in get
res = instance.dict[self.func.name] = self.func(instance)
File “/usr/local/lib/python3.4/dist-packages/psutil-0.5.0-py3.4-linux-armv7l.egg/psutil/init.py”, line 236, in exe
raise AccessDenied(self.pid, self._platform_impl._process_name)
psutil.error.AccessDenied: (pid=52, name=‘bioset’)
2016-12-06 18:55:37 - myDevices - ERROR - Exception on pid:53
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/myDevices-0.1.20741-py3.4.egg/myDevices/os/services.py”, line 83, in Run
processInfo.Exe = p.exe
File “/usr/local/lib/python3.4/dist-packages/psutil-0.5.0-py3.4-linux-armv7l.egg/psutil/_common.py”, line 75, in get
res = instance.dict[self.func.name] = self.func(instance)
File “/usr/local/lib/python3.4/dist-packages/psutil-0.5.0-py3.4-linux-armv7l.egg/psutil/init.py”, line 236, in exe
raise AccessDenied(self.pid, self._platform_impl._process_name)
psutil.error.AccessDenied: (pid=53, name=‘bioset’)
2016-12-06 18:55:37 - myDevices - ERROR - Exception on pid:54
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/myDevices-0.1.20741-py3.4.egg/myDevices/os/services.py”, line 83, in Run
processInfo.Exe = p.exe
File “/usr/local/lib/python3.4/dist-packages/psutil-0.5.0-py3.4-linux-armv7l.egg/psutil/_common.py”, line 75, in get
res = instance.dict[self.func.name] = self.func(instance)
File “/usr/local/lib/python3.4/dist-packages/psutil-0.5.0-py3.4-linux-armv7l.egg/psutil/init.py”, line 236, in exe
raise AccessDenied(self.pid, self._platform_impl._process_name)
psutil.error.AccessDenied: (pid=54, name=‘bioset’)
2016-12-06 18:55:37 - myDevices - ERROR - Exception on pid:55

etc etc

each new block has a new pid, the process is essentially flopping, RAPIDLY. New proc about every second or so, my log is several gigs. Help! Where to even begin?? Googling parts of the error has gotten me nowhere :frowning:

Symptoms @ control/pi:

Pi RUNS very well, though noticeably slower. GPIO connectivity is 100% on the pi itself. The only additional package I have installed is pigpio, which is installed on another pi in my same environment and GPIO works fine there.

But via Cayenne, my 1wire bus is inaccessible, I can select the device when adding buttons/etc but cannot select a GPIO pin/port. For other pi’s in my same environment, the GPIO is fine, not having the same problem.

I know webpio (or similar?) is problematic, but i’d need something specific - i don’t use it, so I’m fine stripping it out, even if it has to be manually, but I thought I’d done that. This seems like a permissions issue, but I don’t even know where to begin. Linux level is network administrator, so I’m very capable but I’m a couple steps below a sysadmin. Electronics experience 30 years, no amateur.

All I need is a place to go and even basic steps to perform to rip out whatever’s causing this issue and get back to work. puhleeeeeze :slight_smile:

2

Hey @cayenne5,

Yikes, thats no good, we should be pruning that log well before it reaches that size, no matter what’s causing the errors.

I’m tagging @tdeleanu here who understand this log better than I currently do. He’s in Europe so will hopefully be able to speak to this before I return tomorrow morning. If not I’ll investigate with our US team at that time.

3

There’s quite a bit more log-meat to share, too, depending on what’s relevant. I’m not about to throw up a couple dozen pages of fluff that won’t mean anything.

I did just go through and forcefully rip out everything called webiopi on that unit,

and i went into the cayenne interface and did a ‘remove’ on that device which is supposed to ‘uninstall’

i’m hoping i can dig up a manually ‘get out!’ command to rid the pi of the rest, and then i’d like to do a fresh cayenne install.

I see a lot of suggestions to “just reflash the card” – I’ve customized the bejesus out of this thing with additional packages, permissions for apache, etc… I’d LOOOOOVE if we could avoid the nuke-and-start-over step! :smiley:

Just let me know whatever I can provide. I’m an active coder and debugger, so I’m eager to assist in any way.

4

It’s… probably something related to a customization or package we weren’t expecting, and I totally understand you don’t want to jump from zero to “nuke from orbit”

Since you’ve already started poking at webiopi which is part of Cayenne, I feel like I should at least provide the two commands you’ll need to uninstall Cayenne via script so at least you can play tech support’s next favorite game, “uninstall then reinstall” :slight_smile:

sudo /etc/myDevices/uninstall/./uninstall.sh

then

sudo /etc/webiopi/uninstall/./uninstall.sh

As far as your system, could you post the output of cat /etc/os-release just to confirm we’re on supported OS (Jessie or Jessie Lite) at least?

Outside of that, my last ‘sanity’ troubleshooting step would be to run

sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade sudo apt-get install python3.4 sudo apt-get -f install

In that order to make sure things are up to date and then re-installing Cayenne.

5

okay, so I’ll start off with an immediate and hearty thanks for the replies, so quickly and eager to help. I’ve seen a lot of junky forums, and this is not one of them. I genuinely appreciate that - especially as I’m looking to dramatically scale all this up once the proof of concept is demonstrated solidly and reliably.

anyway.

apparently, by ripping out the webiopi stuff explicitly ( sudo find / |grep -i webiopi ), and then using the uninstall/remove button in the web UI, the software uninstalled cleanly, which impressed me. I then reinstalled via ssh, which took less time than before. Immediately now I can add buttons, I was able to throw a relay successfully, so we’re definitely on the right track.

I had recently done a full dist upgrade and python updates for coding prep, so happily none of that was needed tonight as it takes forever. Just the ripping-out of webiopi and the uninstall/reinstall of myDevices was enough to do it.

The only remaining oddity at the moment is the lack of 1wire pickup. They’re supposed to autodetect, and I’m loathe to add sensors manually, lest they somehow overlap/etc with some auto detection later.

So is that a “be patient” kind of thing, or a buggy-add-manually kind of thing, or a i should be kicking you log files so we can figure out why it didn’t auto find my two DS18B20’s :wink: LMK!

6

Killin’ me!!!
About 24 hours later and after an extended ~12hr internet-down period while I was at work (damnable!), I restarted my python daemon controller and happened to check on cayenne’s dash.

lo and behold, there’re my 1-wire sensors. magic.

apparently I’m just ridiculously impatient!!

How does one go about “closing this ticket” ??

Do you guys get awards for being awesome even though you didn’t have to do anything??

1 Like
7

Haha, @rsiegel and I get to change Bugs/Issues topics to a Resolved category, which we take GREAT pleasure in doing :slight_smile:

We could use some experienced coders patrolling the Cayenne community too…seems like if you’re familiar with WebIOPi you’d be pretty familiar with Cayenne, since Cayenne uses a modified version of WebIOPi.

Have you checked out our MQTT API? Might be something that interests you…should allow you to bring on any board you have at your disposal into Cayenne. Which, if you end up getting a board connected an submit the code to our Github page I’ll give you a ‘board reward’.

Hope to see you around!

-B

1 Like
8

I’m ALWAYS thrilled to contribute something that turns out to be a non-bug to the we-fixed-a-bug list!

Impressed with Cayenne’s efforts, very much looking for ways to become more involved in the community and development. I will look into the MQTT API. I work primarily with NodeMCU arduinos and Pi3B’s at the moment :slight_smile:

9

Dear @cayenne5,

I have same issue about nonstop “access denied”, when I read your sentence please explain this:

“ripping out the webiopi stuff explicitly ( sudo find / |grep -i webiopi )” → do you meant delete all files displayed (using awk)?
“and then using the uninstall/remove button in the web UI” → can you explain a bit furhter? I cannot find uninstall webiopi in my desktop.
“I then reinstalled via ssh” → you mean download the tar.gz file in the web Download last release?

here is my os-release:
cat /etc/os-release
PRETTY_NAME=“Raspbian GNU/Linux 8 (jessie)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“8”
VERSION=“8 (jessie)”
ID=raspbian
ID_LIKE=debian
HOME_URL=“http://www.raspbian.org/”
SUPPORT_URL=“RaspbianForums - Raspbian”
BUG_REPORT_URL=“RaspbianBugs - Raspbian”

Have you solved the problem about the error log which contain a lot of access denied?
For the moment I am using a cron job to delete it, I know this is not a right way, but at least I can keep my cayenne working (If your disk full, schedule does not work trust me). Looking for another best way to make my cayenne running smooth without error.

Thanks.

10

yep that’s what i did; the uninstall via the web ui is the “remove cayenne” action from within cayenne. there is no useful user feedback, but if you are watching logs and activity on the device, you will see the software begin to rip itself out at that point. When it runs into finals I deleted manually, it simply warned and kept going

1 Like
11

in answer to your final question, what the actual resolution for the “access denied” error – ironically and disappointingly, the only thing that resolves this in the end it was a hardware reset of the device. The pi has some quirky behavior when it comes to hardware glitches, as rare as they are- with certain components, rebooting the operating system is not sufficient, it requires an actual power cut. In this case, I did a power cut for a different reason, and the issue with cayenne was resolved after power up. I had previously rebooted at least A dozen times with other diagnostic steps in between, to no avail.

i’ve learned over time, if you’re having an issue debugging the raspberry, and rebooting doesn’t fix it, try cutting the power.

1 Like