Running psi4 as root

build
1

Hi there,

I’m building an application that depends on psi4 via openfermionpsi4 and have installed psi4 via the psi4conda build script on Ubuntu 14.04. I need to run psi4 as root on this machine in order for it to pick up on some dependencies, but the openfermionpsi4 package the application is using makes a subprocess.Popen() call without root access, and so it can’t work properly. I looked into setting the setuid bit for the psi4 executable to work around this, but since the psi4 executable is actually a script, that doesn’t seem to be recommended. What options do I have to be able run psi4 in this context?

Thanks,
Tim

2

I’m not quite following the necessities and constraints here, so take this as a smattering of facts, not as a focused answer. The psi4conda installer should be pretty self-contained as far as dependencies – it should only need a few system libs like dl, m, and c. That said, there’s no reason you couldn’t install psi4conda into the root user’s account, if it needed to natively have root ownership. Yes, bin/psi4 is just a lightweight script. The main part of psi4 is a python module (lib/python*/site-packages/psi4/core.so for compiled and psi4/driver/ for python, both imported by psi4/__init__.py). The script bin/psi4 just performs options handling, translates psithon into python and imports the psi4 module. Anything that’s in python there’s no problem editing (though it’ll be hard to keep track of w/o being under git control). Could you use envvars PATH and PYTHONPATH to link programs together? bin/psi4 --psipai-path spits out bash commands to modify those envvars so that python -c "import psi4" just works.

3

loriab,

Thanks for the quick reply! I think I already have psi4conda installed into the root user’s account (this just requires running the install script as root, right?). Whenever I try to run bin/psi4, the import psi4 works fine, but problems show up in exec(content). Though I guess I’m not sure that the problem is psi4 can’t reach its dependencies with sudo, just that it spits out errors without sudo and works fine with it.

Here’s a mysterious stack trace if it might help:

psi4 psi4conda/share/psi4/samples/cc1/input.dat

/srv/platform/platform/deploy/psi4conda/lib/python2.7/site-packages/v2rdm_casscf/v2rdm_casscf.so loaded.
Traceback (most recent call last):
  File "/srv/platform/platform/deploy/psi4conda/bin/psi4", line 248, in <module>
    exec(content)
  File "<string>", line 28, in <module>
  File "/srv/platform/platform/deploy/psi4conda/lib//python2.7/site-packages/psi4/driver/driver.py", line 1050, in optimize
    G, wfn = gradient(lowername, return_wfn=True, molecule=moleculeclone, **kwargs)
  File "/srv/platform/platform/deploy/psi4conda/lib//python2.7/site-packages/psi4/driver/driver.py", line 606, in gradient
    wfn = procedures['gradient'][lowername](lowername, molecule=molecule, **kwargs)
  File "/srv/platform/platform/deploy/psi4conda/lib//python2.7/site-packages/psi4/driver/procrouting/proc.py", line 788, in select_ccsd_gradient
    return func(name, **kwargs)
  File "/srv/platform/platform/deploy/psi4conda/lib//python2.7/site-packages/psi4/driver/procrouting/proc.py", line 2231, in run_ccenergy_gradient
    ccwfn = run_ccenergy(name, **kwargs)
  File "/srv/platform/platform/deploy/psi4conda/lib//python2.7/site-packages/psi4/driver/procrouting/proc.py", line 2179, in run_ccenergy
    ref_wfn = scf_helper(name, **kwargs)  # C1 certified
  File "/srv/platform/platform/deploy/psi4conda/lib//python2.7/site-packages/psi4/driver/procrouting/proc.py", line 1330, in scf_helper
    e_scf = scf_wfn.compute_energy()

RuntimeError: 
Fatal Error: PSIOManager cannot get a mirror file handle

Error occurred in file: /scratch/psilocaluser/conda-builds/psi4_1495009270718/work/psi4/src/psi4/libpsio/filemanager.cc on line: 190
The most recent 5 function calls were:

psi::PsiException::PsiException(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, char const*, int)
psi::PSIOManager::mirror_to_disk()
psi::PSIOManager::open_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)
psi::PSIO::open(unsigned int, int)
psi::Matrix::save(psi::PSIO*, unsigned int, psi::Matrix::SaveType)
4

Have you set PSI_SCRATCH to some local, existing, writeable directory? Any chance the disk is full?

5

PSI_SCRATCH was previously empty, and I tried setting it to /tmp/psi_scratch, but that doesn’t seem to change anything. Should files show up there after psi4 exits? The disk has plenty of space; I’m running this off a fresh AWS EC2 image.

6

Did you mkdir psi_scratch in tmp/? In whatever cmd file launches psi4, try writing to that dir and making a subdir before trying your psi4 run. Does psi4 --test work ok? Scratch files are indexed in psi.PID.clean in submission directory. After proper execution, they are removed, but they may linger if execution fails. You can force them to stay with psi4 -m

7

I did make the directory beforehand. Ah, ok, I tried running psi4 from /tmp and it worked without sudo. The directory I was running from previously does have restricted write access, so it looks like that’s the problem. Is there a way to make psi4 not depend on the directory it’s run from? I can modify the permissions for the openfermionpsi4 folder to get it working, but I’m wondering if there’s another environment variable I can set or something.

psi4 --test does fail if I run it from the write restricted directory, but works from /tmp. I’d post the output, but it’s more characters than the forum tolerates.

8

Psi will write the output file alongside the input file, so you could get around outfile by placing the infile elsewhere, specifying the full path to outfile or by -o stdout to send it to screen. But little files like psi.PID.clean and timer.dat I think it always writes to the dir from which run.

Without fully knowing how the pieces go together, I’d think that invoking psi from a freely writable location with whatever PATH or PYTHONPATH adjustments are needed to find openfermionpsi4 would be the way to go.

9

I ended up modifying the write permissions for the directory psi4 currently runs from, and it works smoothly. Thank you so much for your help!