IOError: [Errno 13] Permission denied: '/sys/class/gpio/gpio4/direction'

[sirdel]

usingsht -vtrd 4 17 I get a gpio4 direction error

Traceback (most recent call last):
  File "/usr/local/bin/sht", line 9, in <module>
    load_entry_point('sht-sensor==16.2.0', 'console_scripts', 'sht')()
  File "/usr/local/lib/python2.7/dist-packages/sht_sensor/sensor.py", line 264, in main
    sht = Sht(opts.pin_sck, opts.pin_data)
  File "/usr/local/lib/python2.7/dist-packages/sht_sensor/sensor.py", line 211, in __init__
    super(Sht, self).__init__(pin_sck, pin_data, **sht_comms_kws)
  File "/usr/local/lib/python2.7/dist-packages/sht_sensor/sensor.py", line 67, in __init__
    self._init()
  File "/usr/local/lib/python2.7/dist-packages/sht_sensor/sensor.py", line 72, in _init
    self.gpio.set_pin_value(pin, k='direction', v='low')
  File "/usr/local/lib/python2.7/dist-packages/sht_sensor/gpio.py", line 65, in set_pin_value
    with open(get_pin_path(n, k), 'wb', 0) as dst:
IOError: [Errno 13] Permission denied: '/sys/class/gpio/gpio4/direction'

2nd time round I get a gpio17 direction error

...
...
IOError: [Errno 13] Permission denied: '/sys/class/gpio/gpio17/direction'

3rd time round it works as expected :-

sht -vtrd 4 17
temperature: 26.84
rh: 42.062958002
dew_point: 12.8694307018

Looks like a delay is needed for udev to change the access permissions after the pin has been exported ? This nasty hack worked

...
...
log.debug('Exporting pin: %s', n)
with open(join(path_gpio, 'export'), 'wb', 0) as dst:
  gpio_access_wrap(ft.partial(dst.write, bytes(n)))
  time.sleep(0.1)
...

[mk-fg]

Thanks for reporting.

Yeah, module currently has nothing to do with permissions by itself and simply expects stuff to be accessible without any extra delay.

Can indeed be udev-related, if you're not running this code as root and have some permissions setup for gpio nodes, maybe via custom udev rules. But if you do run the script as root, then guess it's likely some kernel quirk where flushed write to "export" doesn't wait for all these other knobs to be initialized properly.

I think it might be possible to add some option to make script/module retry access in a loop on failure, until it succeeds, as a general workaround for such issues - might implement that sometime later.

Other workaround I might suggest (aside from the one you've already proposed) for a more practical case - simply initialize these pins on your device before using the module - i.e. run some script on boot that'd e.g. do echo 4 > /sys/class/gpio/export && sleep 0.5 && chown ... and such. Might be better than time.sleep(0.1) in that it doesn't waits for udev at all (if it is involved).

[mk-fg]

Didn't even remember that I had gpio_access_wrapper() func to do that "sleep and retry" thing there, which apparently wasn't applied in that one instance, hence the errors.

Should be fixed now - added it for open() in set_pin_value() as well, thought didn't test it, so please reopen if there'll be any issues.

[misudo]

I'm getting a very similar error, I created an issue for it here. Could you help?

[mk-fg]

As also mentioned in kizniche/Mycodo#162, issue seem to be indeed same one as reported here, as this line:

with open(get_pin_path(n, k), 'wb', 0) as dst:

Was changed in the c27d283f commit.

If you've installed module via pip, pip install --upgrade sht-sensor should probably fix it, otherwise might be a good idea to update via same channel as you've installed the thing from (e.g. distro package or something like that).

Not 100% sure if that commit fixes the issue, as I've never heard back from the reporter here, but probably should.

[misudo]

Thank you so much, Misha, it looks like the issue is now gone and all works well with sht -vtrd 21 17. However, it has not fixed the problem for the Mycodo project - still no data display; I guess the problem is now on the other side;). I'll be digging into this now.

[mk-fg]

Note that there also seem to be a recent commit in mycodo with sht1x fixes - https://github.com/kizniche/Mycodo/commit/6477798 (13 days ago), so you might want to update that code as well, or make sure that you have that change applied.

[misudo]

I tried upgrading, but it looks like I'm running the newest version. @mk-fg , thank you for all your help!

[kizniche]

@misudo You will need to restart the daemon for the new sht module to be loaded. If yo do not restart it, it will continue using the old module. Restart with sudo service mycodo restart

Keep in mind that the requirements.txt uses sht-sensor version 16.2.0, which I believe may be affected by this issue. By upgrading your module with the above command, you will have the latest version. Also, if upgrading Mycodo through it's Admin panel, you will downgrade your version to 16.2.0 because that is what's in requirements.txt. If you can confirm the latest module version works in Mycodo, I will update the requirements.txt.

[misudo]

Thank you both, @mk-fg and @kizniche, all works now!