psychopy.org | Reference | Downloads | Github

Iohub .iohpid permissions

This command:

io = iohub.launchHubServer()

evokes this error message:

IOError: [Errno 13] Permission denied: ‘C:\Program Files\JetBrains\PyCharm Community Edition 2017.2.4\helpers\pydev\.iohpid’

The stack trace points to this line:
iopFile= open(iopFileName,‘w’)

In this file:
“C:\Program Files (x86)\PsychoPy2\lib\site-packages\psychopy\iohub\client_init_.py”, line 990, in _startServer

I am running Psychopy on Windows 10 Home version 17.09 build 16299.64 and PyCharm version 2017.3.

So the user does not have permissions to create the “.iohpid” file in that directory. As a work-around, I’ve modified \psychopy\iohub\client_init_.py to put “.iohpid” file in ~/ instead, where of course the user would always have write permissions. That’s a pretty good solution but I’m not sure that it is perfect. If resources iohub uses are per-system and one user logs out leaving the IOHub server running and another user logs in and starts up the IOHub server then those could conflict. Have not looked into whether that would really be a problem or not. A system temp directory might be a better choice of location in case that turns out to be a real problem.

Also, io = iohub.launchHubServer() works from the Python command line but not from a script. Even though iopFileName resolves to the same path under both conditions.

There is some unexplained weirdness here: Why does my system exhibit this bug when, presumably, others do not? I’ve found only two references to the bug:
here:

and here:
https://groups.google.com/forum/#!topic/psychopy-users/7RRyFl1G7u0

I could not find it logged in the bug tracker at the PsychoPy github project, but it’s always possible that I overlooked something. Release notes for PsychoPy 1.85.3 say “Fix to iohub.launchHubServer() under Linux…” and perhaps it is related. That also suggests that I should have found a related issue in the bug tracker, so I probably did overlook it.

  • Allen

But you seem to be running the script from within PyCharm. What if you run it from the command line?

But you seem to be running the script from within PyCharm. What if you run it from the command line?

Well sometimes it runs. In that case the __init__.py script’s rootScriptPath variable resolves to the empty string so the script deposits its “.iohpid” file in the current working directory.

So it can work under some conditions but is nontheless defective in at least three respects.

  1. If the current working directory is not writable in will fail.
  2. It litters the directory tree with those .iohpid files. Whatever is the working directory from which the script is launched, it drops one of those files there, which it subsequently does not clean up.
  3. The iohub can only be used in a script launched when invoking Python from the system command line and it fails when importing a script at the Python prompt.

The brokenness is because iohub puts its .iohpid file in the directory to which os.path.dirname(sys.argv[0]) resolves. It’s just a bad policy. Here are three ways of fixing that.

  1. Put .iohpid in the user’s home directory. [works, trivial effort]
  2. Put .iohpid in the application data directory. [should work, a little more effort]
  3. Get rid of .iohpid. It looks like it is only used to identify orphaned server processes so that they can be killed on startup. Presumably those could be found instead by examining the system process list. [cleanest solution, some more work]

best,

Allen

Hi Allen,

That would be indeed be convenient for tinkering.

I’m not familiar enough with its internals to know how feasible it would be to get it to interact with the overall Python process rather than a specific script process.

I think more people might object to random crap appearing in their home directory than in some specific working directory (although maybe that’s acceptable practice in the Linux world?)

What’s “the application” in this context? Is it Python, PsychoPy, or the specific script being run? I’m not sure that it makes sense to think of Python as an application and the PsychoPy application won’t be running if the script is invoked from the command line. Perhaps it comes back to keeping all experiment-related files in one place (and for most PsychoPy users, for convenience the working directory is probably the location of the experiment script itself).

It sounds like you’ve got a great handle on what is happening here and how it could be improved. ioHub has been suffering from some benign neglect over the last couple of years, but it is getting some new attention paid to it lately, particularly by @richard and @jon (and I think there is some unreleased development from @sol in the pipeline too). If you are able to contribute to that, it would be really valued.

On https://github.com/psychopy/psychopy, posting issues is useful but pull requests are gold…

I think more people might object to random crap appearing in their home directory than in some specific working directory (although maybe that’s acceptable practice in the Linux world?)

There are a bunch of .* files in my Windows 10 home directory which various applications have left there, so it seems like common practice on Windows just as on OS X and Linux. The .* files are hidden by default so perhaps you have them but did not notice?

What’s “the application” in this context?

Definitely IOHub because that is the scope of the stored server process ID’s utility.

Even if you go through a system API to get the application directory, that API does not enforce matching the name of the executable file to the name of the requested application directory. At least it does not on Qt or Cocoa that I recall. If that part of the Qt API resolves to Windows API calls then those must behave the same in that respect. If Qt instead resolves to its own code then just do whatever Qt does because obviously Windows could not be enforcing against that.

pull requests are gold…

Yup. Ok, maybe I will dork around with other implementations over the weekend then submit something next week, unless someone else gets to it first or someone else chimes in here with some other better suggestions.

best,

Allen

2 Likes

I really don’t know much about this. One possibility in my mind is that this file could go in the ~/.psychopy folder

I do recall @daniel.e.shub’s pointing out that there’s a specification of where all the files should go (the XDG Base Directory Specification). My slight issue with that is that I rather like all files being in one place. I think that would have us putting app data in one place, user prefs in another and monitor calibation files somewhere else too (although there is a good reason for that if we want them shared between users).

Get rid of .iohpid. It looks like it is only used to identify orphaned server processes so that they can be killed on startup. Presumably those could be found instead by examining the system process list. [cleanest solution, some more work]

A solution I had suggested to Sol once was that the server process should close itself if the python process that created it disappeared. That seemed to me a better solution. The process runs in a loop anyway so it could be passed the process ID of the calling process and periodically check if it’s alive? Then, yes, I think this pid file isn’t needed

But, to reiterate, I don’t know much about it!