New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when running jupyter notebook with a user with id != 1000 #1318

Closed
csala opened this Issue Apr 7, 2016 · 11 comments

Comments

Projects
None yet
8 participants
@csala

csala commented Apr 7, 2016

Apparently, jupyter notebook command attempts to write something on folder /run/user/1000 which belongs to user with id 1000.
If jupyter notebook is run with a different user, the following stacktrace appears:

Traceback (most recent call last):
  File "/opt/jupyter/bin/jupyter-notebook", line 11, in <module>
    sys.exit(main())
  File "/opt/jupyter/local/lib/python2.7/site-packages/jupyter_core/application.py", line 267, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/opt/jupyter/local/lib/python2.7/site-packages/traitlets/config/application.py", line 595, in launch_instance
    app.initialize(argv)
  File "<decorator-gen-7>", line 2, in initialize
  File "/opt/jupyter/local/lib/python2.7/site-packages/traitlets/config/application.py", line 74, in catch_config_error
    return method(app, *args, **kwargs)
  File "/opt/jupyter/local/lib/python2.7/site-packages/notebook/notebookapp.py", line 1021, in initialize
    self.init_configurables()
  File "/opt/jupyter/local/lib/python2.7/site-packages/notebook/notebookapp.py", line 815, in init_configurables
    connection_dir=self.runtime_dir,
  File "/opt/jupyter/local/lib/python2.7/site-packages/traitlets/traitlets.py", line 529, in __get__
    return self.get(obj, cls)
  File "/opt/jupyter/local/lib/python2.7/site-packages/traitlets/traitlets.py", line 508, in get
    value = self._validate(obj, dynamic_default())
  File "/opt/jupyter/local/lib/python2.7/site-packages/jupyter_core/application.py", line 99, in _runtime_dir_default
    ensure_dir_exists(rd, mode=0o700)
  File "/opt/jupyter/local/lib/python2.7/site-packages/ipython_genutils/path.py", line 167, in ensure_dir_exists
    os.makedirs(path, mode=mode)
  File "/opt/jupyter/lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/run/user/1000/jupyter'
@csala

This comment has been minimized.

Show comment
Hide comment
@csala

csala Apr 7, 2016

Actually, I found out something still more interesting: The id which jupyter uses to decide which folder it should write in (this /run/user/{id}), seems to be the id of the user which the session was initially open with.

So, if I ssh into a host using a user which has id X and then I sudo su - anotheruser, when I run jupyter from user anotheruser the folder it uses is /run/user/X

csala commented Apr 7, 2016

Actually, I found out something still more interesting: The id which jupyter uses to decide which folder it should write in (this /run/user/{id}), seems to be the id of the user which the session was initially open with.

So, if I ssh into a host using a user which has id X and then I sudo su - anotheruser, when I run jupyter from user anotheruser the folder it uses is /run/user/X

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Apr 7, 2016

Member

This is coming from the environment variable $XDG_RUNTIME_DIR. Normally, when you log in, that is set to a newly created directory which only your user has access to. I'm guessing that it doesn't get set again when you use sudo to change user.

I think we have a fallback if it's not set, so the easiest thing might be to unset the environment variable after sudo-ing. In fact, I thought sudo dropped environment variables by default. :-/

Member

takluyver commented Apr 7, 2016

This is coming from the environment variable $XDG_RUNTIME_DIR. Normally, when you log in, that is set to a newly created directory which only your user has access to. I'm guessing that it doesn't get set again when you use sudo to change user.

I think we have a fallback if it's not set, so the easiest thing might be to unset the environment variable after sudo-ing. In fact, I thought sudo dropped environment variables by default. :-/

@jesseHFG

This comment has been minimized.

Show comment
Hide comment
@jesseHFG

jesseHFG May 11, 2016

I had the same problem. export XDG_RUNTIME_DIR="" eliminated the problem.

jesseHFG commented May 11, 2016

I had the same problem. export XDG_RUNTIME_DIR="" eliminated the problem.

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver May 12, 2016

Member

You can also (at least in bash) unset XDG_RUNTIME_DIR for the same effect.

Member

takluyver commented May 12, 2016

You can also (at least in bash) unset XDG_RUNTIME_DIR for the same effect.

@GISDev01

This comment has been minimized.

Show comment
Hide comment
@GISDev01

GISDev01 Jun 15, 2016

unset XDG_RUNTIME_DIR

Worked for me as well. Need to run that before starting juypterhub after sudo-ing into our jupyterapp-specific account.

GISDev01 commented Jun 15, 2016

unset XDG_RUNTIME_DIR

Worked for me as well. Need to run that before starting juypterhub after sudo-ing into our jupyterapp-specific account.

@lpryszcz

This comment has been minimized.

Show comment
Hide comment
@lpryszcz

lpryszcz Jun 24, 2016

I have also encountered similar problem. Thanks for the hint.
Note, you can add it to jupyter user ~/.bashrc, then it will load on every login echo 'unset XDG_RUNTIME_DIR' >> ~/.bashrc
https://bioinfoexpert.com/2016/06/24/running-jupyter-as-public-service/

lpryszcz commented Jun 24, 2016

I have also encountered similar problem. Thanks for the hint.
Note, you can add it to jupyter user ~/.bashrc, then it will load on every login echo 'unset XDG_RUNTIME_DIR' >> ~/.bashrc
https://bioinfoexpert.com/2016/06/24/running-jupyter-as-public-service/

@gnestor gnestor added this to the no action milestone Sep 14, 2016

@gnestor gnestor closed this Sep 14, 2016

@georgeha

This comment has been minimized.

Show comment
Hide comment
@georgeha

georgeha Sep 26, 2016

worked for me too. Great!

georgeha commented Sep 26, 2016

worked for me too. Great!

@matrs

This comment has been minimized.

Show comment
Hide comment
@matrs

matrs Nov 21, 2016

Why is this closed if it's still a problem?
I just installed anaconda in arch linux as a regular user, there is no sudo involved and i got this error. no error for su user. Fixed by unsettling $XDG_RUNTIME_DIR

matrs commented Nov 21, 2016

Why is this closed if it's still a problem?
I just installed anaconda in arch linux as a regular user, there is no sudo involved and i got this error. no error for su user. Fixed by unsettling $XDG_RUNTIME_DIR

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Nov 21, 2016

Member

What is XDG_RUNTIME_DIR set to in that case?

I believe that if XDG_RUNTIME_DIR is set to a location that is not writable, that's a problem with your environment. It's supposed to be set at login to a directory which is r+w for your user and your user only.

Member

takluyver commented Nov 21, 2016

What is XDG_RUNTIME_DIR set to in that case?

I believe that if XDG_RUNTIME_DIR is set to a location that is not writable, that's a problem with your environment. It's supposed to be set at login to a directory which is r+w for your user and your user only.

@matrs

This comment has been minimized.

Show comment
Hide comment
@matrs

matrs Nov 22, 2016

The problem is that, the folder set by jupyter notebook is only writable by SU, but that shouldn't happen because i'm starting the notebook as a regular user and also i'm logged in as regular user. This didn't happen when i used ipython/jupyter from my distro repo (i used that for about two years).

The folder is the same as is in the OP, /run/user/1000/jupyter

matrs commented Nov 22, 2016

The problem is that, the folder set by jupyter notebook is only writable by SU, but that shouldn't happen because i'm starting the notebook as a regular user and also i'm logged in as regular user. This didn't happen when i used ipython/jupyter from my distro repo (i used that for about two years).

The folder is the same as is in the OP, /run/user/1000/jupyter

@matrs

This comment has been minimized.

Show comment
Hide comment
@matrs

matrs Nov 22, 2016

So I was installing anaconda in a new partition owned by the root user, even though everybody was able to write in it. I changed the owner to my regular user and now i don't have the problem anymore. Previously, the folder /run/user/1000/jupyter was owned by root and by definition that folder is only writable by the target user. Now is owned by my regular user.

matrs commented Nov 22, 2016

So I was installing anaconda in a new partition owned by the root user, even though everybody was able to write in it. I changed the owner to my regular user and now i don't have the problem anymore. Previously, the folder /run/user/1000/jupyter was owned by root and by definition that folder is only writable by the target user. Now is owned by my regular user.

lresende added a commit to lresende/ansible-spark-cluster that referenced this issue Sep 13, 2017

Workaround for notebook crash when using su to the notebook user
This is described in notebook issue 1318
jupyter/notebook#1318

And the workaround is applied on the elyra start script.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment