RS isn't able to start services if it doesn't have privileges to access its working dir

[lw]

If I start the services as cmsuser in my home directory (which obviously isn't accessible to cmsuser) everything works for all services except ResourceService. I get this error:

luca@luca-thinkpad ~ $ sudo -u cmsuser cmsResourceService -a 1
Using configuration file /usr/local/etc/cms.conf.
2013/03/11 22:57:33 - INFO     [ResourceService,0] ResourceService 0 up and running!
2013/03/11 22:57:33 - INFO     [ResourceService,0] Restarting (AdminWebServer, 0)...
2013/03/11 22:57:33 - CRITICAL [ResourceService,0] Exception not managed, quitting. Exception `OSError(13, 'Permission denied')' and traceback `Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/cms-1.1.0pre-py2.7.egg/cms/async/AsyncLibrary.py", line 271, in run
    self._step()
  File "/usr/lib/python2.7/site-packages/cms-1.1.0pre-py2.7.egg/cms/async/AsyncLibrary.py", line 290, in _step
    self._trigger()
  File "/usr/lib/python2.7/site-packages/cms-1.1.0pre-py2.7.egg/cms/async/AsyncLibrary.py", line 332, in _trigger
    ret = func()
  File "/usr/lib/python2.7/site-packages/cms-1.1.0pre-py2.7.egg/cms/service/ResourceService.py", line 171, in _restart_services
    cwd=cwd
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 13] Permission denied: '.'
'

I don't know exactly what it's doing. I think we should investigate and fix this.

BTW, this is yet another hint that it's probably a good idea to change the way RS starts and detects the other services running on the machine.

[stefano-maggiolo]

[Oh gosh, now I got used reading stack traces on the other way round...]

General note: I don't think you are supposed to use cmsuser directly, but to add your user to the group.

On the actual question, we set cwd mostly because in the non-installed version we need it to be the directory of the service to start, and then of course it needs access to that.

In the installed version (your case) we shouldn't need it but it is set anyway (to ".") because apparently it saved some line of codes. But a saner value is None instead of ".", which by subprocess docs means "don't change cwd at start". Does this change solve it?

[lw]

Mmh... from my understanding, what we do now is:

• if CMS is installed we set (for example) command = "cmsWorker" and cwd = "."
• if CMS is NOT installed we set (for example) command = "./Worker.py" and cwd = "cms/service"

So far nothing strange, except that I'm puzzled about how this can work in case CMS is not installed, because the subprocess documentation [1] says that:

If cwd is not None, the child’s current directory will be changed to cwd before it is executed. Note that this directory is not considered when searching the executable, so you can’t specify the program’s path relative to cwd.

and therefore it should try to execute "./Worker.py" inside the cwd of RS, without finding it, right?

My suggestion, to avoid any risk, is to remove any cwd definition (and its parameter in subprocess.Popen), and use directly command to tell the system where the file we want to execute is, like:

command = os.path.join(".", ResourceService.SERVICE_PATH[service.name], "%s.py" % service.name)

Yet, since this approach assumes that $REPO (which we require to be RS's cwd) is in the PATH, I'm still not completely satisfied. Also, I wanted to try this modified code, but ran into an issue when changing "process_cmdline": I didn't know what to do to support the different filesystem locations the services are in.

Therefore my proposal is to wait until we fix issue #85, thus having all executables in a single directory, and then make what I described above, with the addition of using the path of ResourceService.py (via __file__) to get the ones of the other files, avoiding any relative path.

[1] http://docs.python.org/2/library/subprocess.html#subprocess.Popen

[stefano-maggiolo]

[1] says that cwd is not added to the executables path search, so you can't start "Worker.py", but you can start "./Worker.py" (as you do in bash). Moreover, if you use your solution, the root dir of CMS need not to be in the executable path (same reason as before).

I think the cwd was chosen exactly because it offered the same structure for process_cmdline regardless of the directory the service is in.

In your original problem, you started cmsResourceService, so it tries to run cmsWorker and so on, but it failed because we also set cwd="." which is unaccessible. As said in the first reply, setting cwd="." in that case is useless (what I really meant was "just give me something, I don't care", and this is covered by setting cwd=None). So, a tentative could be to set cwd=None in that case and hoping that subprocess behavior is different.

Can you change it, see if it solves your situation, and commit in any case the change?