GPIO permission denied, udev racing

[craigerl]

I'm "reopening" this bug since it's still observed in direwolf 1.6. In this case it's a Raspberry Pi ZeroW. The additional 250ms wait time is likely insufficient on this cpu. Increase to a full second giving udev a chance to update permissions?

pi@gtown:~ $ tail -f /run/direwolf.log 
Line 8: Invalid port number for IGate server. Using default 14580.
Audio device for both receive and transmit: plughw:0,0  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
You don't have the necessary permission to access GPIO.
There are three different solutions: 
 1. Run as root. (not recommended)
 2. If operating system has 'gpio' group, add your user id to it.
 3. Configure your user id for sudo without a password.

[dranch]

A Raspberry Pi Zero W has more than enough CPU power to run Direwolf at it's maximum performance and there isn't any need for extended TXDELAY for a Zero that's not not too overloaded (high CPU load). As to your UDEV issue, are you sure the login name that's running the Direwolf process is in the "udev" Unix group and you've logged out and logged back in to get those permissions? I don't believe there is a real issue here so please move your support question to the direwolf@groups.io email list as Github's "issue" tracker is only for bugs and new feature enhancements.

[craigerl]

The pi user is in the gpio group, there isn't a udev group(?). The issue is observed, rarely, immediately after a reboot, with significant cpu load on account of the boot proces and systemd. Ultimately the issues still exists, even if we don't want to call it a bug. I upped the value to 500ms, to see if that helps. I'll also put defensive code around the direwolf command since it's still non-deterministic, though, imho, the fix should be a retry inside direwolf upon gpio permission error. I'll followup with the mailing list, thanks.

[dranch]

Ultimately it's WB2OSZ's call here but I believe your issue is happening at the UDEV level and not Direwolf. If Udev is malfunctioning, no number of Direwolf retries will be helpful here.