Cannot init OMPython - Server port file mismatch

[ivan-gomes]

When testing with omc = OMCSessionZMQ() I get the following error:

2019-06-05 17:17:03,438 - OMPython - ERROR - OMC Server is down. Please start it! Log-file says:
Created ZeroMQ Server.
Dumped server port in file: /tmp/openmodelica.nobody.port.520e1d1cf66e42edab1847382e320d83
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/conda/lib/python3.7/site-packages/OMPython/__init__.py", line 541, in __init__
    self._connect_to_omc(timeout)
  File "/opt/conda/lib/python3.7/site-packages/OMPython/__init__.py", line 564, in _connect_to_omc
    raise Exception("OMC Server is down. Could not open file %s" % self._port_file)
Exception: OMC Server is down. Could not open file /tmp/openmodelica.jovyan.port.520e1d1cf66e42edab1847382e320d83

You'll notice the mismatch between the created file/tmp/openmodelica.nobody.port.520e1d1cf66e42edab1847382e320d83 and what OMPython is looking for /tmp/openmodelica.jovyan.port.520e1d1cf66e42edab1847382e320d83.

If I ls -lh /tmp it shows

-rw-r--r-- 1 jovyan users  113 Jun  5 17:27 openmodelica.jovyan.port.520e1d1cf66e42edab1847382e320d83.log
-rw-r--r-- 1 jovyan users   21 Jun  5 17:27 openmodelica.nobody.port.520e1d1cf66e42edab1847382e320d83

cat /tmp/openmodelica.nobody.port.520e1d1cf66e42edab1847382e320d83

Created ZeroMQ Server.
Dumped server port in file: /tmp/openmodelica.nobody.port.520e1d1cf66e42edab1847382e320d83$

cat /tmp/openmodelica.nobody.port.520e1d1cf66e42edab1847382e320d83

tcp://127.0.0.1:46505

ps ax | grep omc

   11 ?        Ss     0:00 /bin/sh -c /usr/bin/omc --interactive=zmq +z=520e1d1cf66e42edab1847382e320d83
   12 ?        Sl     0:00 /usr/bin/omc --interactive=zmq +z=520e1d1cf66e42edab1847382e320d83
   24 pts/0    S+     0:00 grep omc

Please assist. I believe the source of the issue is that the subprocess is ran as nobody instead of the current user, but it is not clear to me what is causing that.

[peterscherpelz]

I just hit this error when I tried to run openmodelica in a Docker container. I assume it's something related to the weird way Docker users map onto the kernel's users that causes it to have "nobody" in the port filename.

In any case, OMPython tries to figure out the correct user by calling python's getpass.getuser() function. That can be overridden with environment variables, so I found that setting the environment variable LOGNAME=nobody fixed this error. See https://docs.python.org/3/library/getpass.html

I hope that helps!

[jpwijbenga]

I think it might not be Docker's fault. In the ompython code the call to getpass.getuser() results in the correct user. When I go into the Docker container and try to start omc as a custom user, the omc executable is run as the correct user, but still omc dumps to the openmodelica.nobody.port..... file. OMPython knows the correct user, but OMC executable does not...

[sjoelund]

There are no user names in the Linux kernel, only user IDs. If you want to run a docker image with the same usernames as you have, you need to pass along your /etc/passwd or generate one for your username...

If you look in htop or similar it will tell you the correct usernames because it will map the user IDs outside of docker :)

It seems the omc executable will only look for the USER env.var. Python will look for more: https://docs.python.org/3/library/getpass.html

For me, if I run docker with default settings, I get in Python:

>>> import getpass
>>> getpass.getuser()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/getpass.py", line 169, in getuser
    return pwd.getpwuid(os.getuid())[0]
KeyError: 'getpwuid(): uid not found: 1001'

So I don't know what settings you use, but probably some env.var is being sent to docker.

[jpwijbenga]

If I look into the container my USER env var is empty, despite adding the user in the Dockerfile. So the getpass works, but the USER env var itself is empty.

[jpwijbenga]

Fixed it by adding ENV USER=om to Dockerfile.

[AnHeuermann]

Fixed it by adding ENV USER=om to Dockerfile.

This solves the issue (tested just now because I did run into the same issue when playing with Docker).