Error when using in a multi user setup

[akshayrawat]

I get this error when using prezto from a second user (where the first user also uses prezto) on MacOS.

prompt_sorin_precmd_async:4: permission denied: /tmp/zsh-prompt_sorin_data

Doing a chmod a+r+w for it creates the same problem for the other user.

prezto version: latest as of now
zsh 5.2 (x86_64-apple-darwin15.4.0)

[ezintz]

It seems like this line

prezto/runcoms/zprofile

Line 71 in 4f19700

mkdir -p -m 700 "$TMPDIR"

is responsible for creating the directory where your prompt, sorin, is trying to save data to.

Since the directory is created with 700 you can change it for example to 777 to allow everyone to write to it. I am not sure if this is correct, what if multiple users are logged in? From my understanding each user is overwriting the data of the other one, if all are using the same prompt.

I would change the prompt setup to be unique for each user at

prezto/modules/prompt/functions/prompt_sorin_setup

Line 101 in 4f19700

_prompt_sorin_precmd_async_data="${TMPPREFIX}-prompt_sorin_data"

.

[jlax47]

@akshayrawat I think there might be something wrong with your system. By default, osx creates a user specific temp directory. You should not be getting any conflicts because $TMPDIR should already be set and be specific to you.

Also the fact that the directory that you are trying to create is: /tmp/zsh-prompt_sorin_data tells me that $TMPDIR is not set or doesn't exist and the variable $LOGNAME is empty.

I don't know exactly what's going on with your system, but it should be a fairly easy fix. Edit the file: .zprezto/runcoms/zprofile and change lines 70-71 from:

if [[ ! -d "$TMPDIR" ]]; then
  export TMPDIR="/tmp/$LOGNAME"
  mkdir -p -m 700 "$TMPDIR"
fi

to:

if [[ ! -d "$TMPDIR" ]]; then
  export TMPDIR="$(mktemp -d)"
fi

This will create a per user temporary directory with the correct permissions which should prevent the problem you are seeing (and others you haven't seen yet).

[jlax47]

#1209 - Not sure if this will get merged or not, but I think it's a reasonable fix.

[donpatrice]

@jlax47 this does not work for me with Ubuntu 16.04. This also affects the module.

[paulmelnikow]

Hey @donpatrice, #1209 was merged into zsh-users/prezto, the community fork of this repo. zsh-users is an organization dedicated to host Zsh community projects and therefore became the rational home for a community maintained version of prezto. See #1239 for more information on the fork.

This is the commit.

You may want to migrate over. There are some upgrade instructions, soon to be merged.

[donpatrice]

Thank you @paulmelnikow very much for the hint. The commit mentioned does not work for me, I will open an issue on zsh-users.

[belak]

The fix was merged yesterday, so I'm closing this issue now.

[paulmelnikow]

So, as it turns out, the fix in #1209 only fixed the issue for login shells.

There are a couple ways this could be fixed for non-login shells: see prezto-inactive-community-fork#35 (comment) and prezto-inactive-community-fork#35 (comment).

@belak Would you like to reopen this, so we can finish up that discussion here?

[belak]

Sure, makes sense. Thanks for following up.

[belak]

I think the best method may be to set TMPPREFIX in init.zsh, as that would ensure it's handled properly.

[paulmelnikow]

That would fix TMPPREFIX, which would be good as a minimum since prezto itself depends on it. (Though TMPPREFIX is itself a zsh thing.)

That said, the rest of the .zprofile handling seems similarly broken in non-login shells. Can you think of a way to fix the test in .zshenv?

[belak]

I'm not sure what the best way to handle this would be... I guess this is a bit more complicated than first glance.

[binarykitchen]

so, what's the official fix? it still happens for me on latest master

[belak]

I don't know if there is a "correct" fix for the runcoms. Additionally, I haven't actually used them in a while, so I'm probably not the best person to ask about those.

That being said, the sorin prompt should be fixed, as 2f20a80 ensured a unique tmp file is created for each running process and a0541ce ensured that we fall back to /tmp if TMPDIR isn't set.

If you're having similar issues with other parts of the code, or you have more info I can use to reproduce this, I'd be happy to look into it further.

[binarykitchen]

ok, will git pull once those two commits are merged @belak

[belak]

Those commits were merged about a week ago.

[binarykitchen]

hmmm, but they still happen

nodejs@binarykitchen ~/.zprezto ❯❯❯ git pull
remote: Counting objects: 9, done.
remote: Total 9 (delta 3), reused 3 (delta 3), pack-reused 6
Unpacking objects: 100% (9/9), done.
From https://github.com/sorin-ionescu/prezto
   a0541ce..d9a1380  master     -> origin/master
Updating e606b09..d9a1380
nodejs@binarykitchen ~/.zprezto ❯❯❯ prompt_sorin_precmd_async:4: permission denied: /tmp/zsh-prompt_sorin_data                                               ⏎
nodejs@binarykitchen ~/.zprezto ❯❯❯ zsh                                                                                                                      ⏎
nodejs@binarykitchen ~/.zprezto ❯❯❯ prompt_sorin_precmd_async:4: permission denied: /tmp/zsh-prompt_sorin_data

[belak]

After pulling did you try in the current shell or a new shell? The current shell would have the old code loaded. One key thing to note: the current code doesn't use a tmp directory named like that. It should be /tmp/sorin-prompt-async-XXXXXXXXXX where the Xs are replaced with random characters.

[binarykitchen]

in a new shell of course, that's why i entered zsh inbetween, see above

and no idea who/where /tmp/zsh-prompt_sorin_data is being set

[belak]

Ah, I didn't see the new shell call. Sorry about that. Maybe it's loading from a different location than you think it is? ag prompt_sorin_data gives zero results against the current commit on master (that's the old tmp location - as you can see in 2f20a80), so I'm fairly sure the new code isn't being used.

[binarykitchen]

ok - all i want to know is how to fix this? :)

[belak]

It should be fixed on master, as I mentioned... but for whatever reason, however you're loading prezto isn't picking up the new version... which leads me to believe that prezto may be cloned to multiple locations on your system and the one which is actually being used has not been updated.

Are your dotfiles posted anywhere? I'd be happy to take a look to see if I can spot anything.

[binarykitchen]

well, the dotfiles are exactly the defaults you provide in the runcoms directory

lrwxrwxrwx    1 nodejs nodejs   36 Nov 25  2016 .zlogin -> /home/nodejs/.zprezto/runcoms/zlogin
lrwxrwxrwx    1 nodejs nodejs   37 Nov 25  2016 .zlogout -> /home/nodejs/.zprezto/runcoms/zlogout
lrwxrwxrwx    1 nodejs nodejs   39 Nov 25  2016 .zpreztorc -> /home/nodejs/.zprezto/runcoms/zpreztorc
lrwxrwxrwx    1 nodejs nodejs   38 Nov 25  2016 .zprofile -> /home/nodejs/.zprezto/runcoms/zprofile
lrwxrwxrwx    1 nodejs nodejs   36 Nov 25  2016 .zshenv -> /home/nodejs/.zprezto/runcoms/zshenv
-rw-------    1 nodejs nodejs  404 Nov 25  2016 .zsh_history
lrwxrwxrwx    1 nodejs nodejs   35 Nov 25  2016 .zshrc -> /home/nodejs/.zprezto/runcoms/zshrc

[belak]

This is what I see with the default setup:

[belak@torbjorn ~]$ zsh
~ ❯❯❯ cd .zprezto
~/.zprezto ❯❯❯ git rev-parse HEAD
d9a1380263bbeb27a9ed91b79e04e99b65760535
~/.zprezto ❯❯❯ cd
~ ❯❯❯ ls /tmp/sorin*
/tmp/sorin-prompt-async-HSi7MuXutW
~ ❯❯❯ ls /tmp/zsh*
zsh: no matches found: /tmp/zsh*

I realize "it works on my machine" doesn't always mean that the code is correct, but this is how I'm making sure I'm not completely crazy.

[belak]

This might be a silly question, but are you on the master branch, or do you have another branch checked out? Also, are you using a custom fork? Your git pull log said Updating e606b09..d9a1380 but e606b09 doesn't appear to exist in the main prezto repo.

[binarykitchen]

aaaaaaaaahhhh, finally solved it myself. i had a little git mess, ignored some files. not reverted that and pulled all over again incl submodules. all good now :)

thanks for your help dude!

[belak]

Glad you got it figured out! And it sounds like this fixed the error for you, so I'm closing this for now. :D

This should be solved, but if anyone runs into this issue please let me know and I can repopen it.