projectile-global-mode prevents new processes from working over TRAMP

[Silex]

I don't have time to investiguate it right now but I should be able to this week.

[Silex]

Hum, actually it seems to only happen on one server... maybe more of a TRAMP issue than projectile.

[Silex]

Ok, the issue happens with _any_ asynchronous shell command that starts a new connection, and the problem is because of the :lighter that tries to call projectile-project-name all the time. I guess it tries to use a not-yet ready TRAMP connection.

I'm trying to make the right fix but it's not trivial.

[Silex]

Ok, basically something seems to be broken in Emacs 24.4.

I just tested with Emacs 25.0.50.1 (master branch) and the bug doesn't happen, so I'll close this.

[Silex]

Aaaaactually the bug _also_ happens with emacs 25 but less often. Given that emacs 25 has other bugs that prevents me from using it, I'm back on emacs 24 and I'll try to solve this bug.

[Silex]

Okay, I found interesting stuffs:

(setq projectile-mode-line '(:eval (format " Projectile[%s]" (file-truename default-directory))))
(setq projectile-mode-line '(:eval (format " Projectile[%s]" default-directory)))

The first line creates the problem, while the 2nd one doesn't.
Apparently, file-truename doens't work properly when the TRAMP connection is in progress...

@thomasf, @tarsius: I can't find a way to detect wether TRAMP is ready to be used... I tried the following but it still exhibits the bug:

(setq projectile-mode-line '(:eval (if (or (not (tramp-tramp-file-p default-directory)) (tramp-connectable-p default-directory))
                                         (format " Projectile[%s]" (file-truename default-directory))
                                       " Projectile[NOOOO]")))

It looks like tramp-connectable-p returns true when it should not.

Any ideas/trick to check wether TRAMP is "ready" to be used? maybe with-timeout?

[Silex]

Hum, with-timeout seems to work, but it's a bit hacky:

(setq projectile-mode-line '(:eval (with-timeout (0.2 " Projectile[NOOO]")
                                     (format " Projectile[%s]" (projectile-project-name)))))

[Silex]

I'm trying to find answers at http://lists.gnu.org/archive/html/bug-gnu-emacs/2015-01/msg00596.html for information.

[bgits]

It probably worth pointing out that projectile was working normally with TRAMP until I installed tern.

[Silex]

If tern spawns a process then it happens because of projectile's :lighter because of a TRAMP bug. See the mailing list discussion.

[bgits]

disabled tern still an issue. For the uninitiated, what is :lighter?

[thomasf]

The lighter is the projectile-mode-line customization option which produces the text that is displayed in the mode line. You can customize it to not show the project name and see if your problem is related to this issue.

[Silex]

@bgvianyc: (setq projectile-mode-line " Projectile") fixes all of these issues for me.

[timvisher]

Adding a :+1: for this. Anything I can do to help diagnose the issue, just let me know. I've applied @Silex's workaround and it works so I'm at least back up off the floor.

[Silex]

I had the idea of using tramp-action-succeed to fix this issue, but to my surprise the issue was gone! I can't reproduce anymore, do you guys still experience it?

[timvisher]

@Silex Did anything change on your end? tramp version, emacs version, etc.?

[Silex]

@timvisher: obviously projectile did change, and yeah I probably rebuilt emacs a few time from the git repo.

I'm mostly interested in having someone say "I still have it" to know if I should spent time trying to reproduce it before attempting to fix it.

[timvisher]

@Silex Yep. I was mostly trying to pin down what I would have to do to reproduce your results. ;)

[Silex]

@timvisher: well, do you still see this problem happening without the workaround?

[timvisher]

@Silex Hrm… It looks like I have Emacs 24.5/projectile 0.12.0 which is the latest of both and I still need the fix. Would it be more helpful to 'upgrayed' to projectile HEAD, emacs HEAD, or both?

[Silex]

@timvisher: if you could do a quick test with projectile HEAD it'd be great.

[timvisher]

@Silex on Emacs 24.5/projectile HEAD I believe I still see the issue.

[Silex]

@timvisher: alright, thanks for reporting I'll do some tests

[2mc]

Any new about your testing, yet?
Would be great to proceed here a bit.
I think this issue is liked to those as well:
https://github.com/bbatsov/projectile/issues/835
https://github.com/bbatsov/prelude/issues/887

[Silex]

@2mc: sorry, somehow I missed your comment in my activity feed

I'll try again with 24.5, but for me the problem seems to be solved when using https://launchpad.net/~ubuntu-elisp/+archive/ubuntu/ppa

[Silex]

Ok, I confirm the problem is gone when using https://launchpad.net/~ubuntu-elisp/+archive/ubuntu/ppa, testing 24.5 at the moment.

[Silex]

@2mc, @timvisher: ok, I'm not sure what to think... because I can't reproduce even with 24.5. Can someone try this and reproduce the problem?

Save a file named bug.el with this content (edit the user@host part):

(package-initialize)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-refresh-contents)
(package-install 'projectile)
(projectile-global-mode)
(find-file "/scpx:user@host:/tmp/foo.txt")
(async-shell-command "ls")

Then run this:

emacs -Q -l bug.el

By me everything behaves as intended.

[2mc]

@Silex Thank you so much for taking up this thread.

Indeed, your bug.el example works even without ubuntu/ppa here on OSX 10.10.5.

Your test, however, does not foresee any decryption of an epa .authinfo file (which is probably the most common way of enabling host password lookup with emacs).

So here is a slightly modified test that will make TRAMP hang, if projectile-global-mode is enabled, right after the decryption has been done (no matter, if the password for authinfo.gpg is provided by the gpg-agent or by a prompt):

(package-initialize)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-refresh-contents)
(package-install 'projectile)

(setq auth-sources '((:source "~/authinfo.gpg")))
(require 'epa-file)
(epa-file-enable)
(setq epg-gpg-program "gpg2")

(projectile-global-mode)
(setq projectile-enable-caching t)

(find-file "/sudo::/tmp/foo.txt")
(async-shell-command "ls")

As you see, I also switched the TRAMP-path to /sudo:: for easier local testing. You have to make sure though, that TRAMP will actually try to find the root password in authinfo.gpg and will not simply refer to a cached sudo password. To ensure this, add this entry to your /etc/sudoers first:

Defaults timestamp_timeout=0

In my case the above is a robust test for making TRAMP hang as described here #835 and there
bbatsov/prelude#887. If you do not enable caching for projectile

(setq projectile-enable-caching nil)

projectile-global-mode does not interfere anymore and everything works fine. What that means exactly, I don't know. Still, my TRAMP problem are caused by the current projectile package.

[Silex]

@2mc: well, ok but that means the original bug I reported here is gone

I'll try to reproduce _your_ bug and see what happens :)

[2mc]

@Silex If it's that what it means, it's already great progress, congratulation!

I was unable to isolate the dysfunctional experience I come across with that well before your new initiative of helping us out of the deadlock, even though I tried (see the refs above).

Maybe it was always 'my bug' and I mistook it for the one discussed here as the symptoms were quite similar.
Whatsoever, I'd be very glad, if the now isolated issue above could be sorted out, too.

Thank you for your efforts, indeed!

[tonycpsu]

I think I might be having a similar or at least related problem with Tramp/Projectile. Emacs 24.4, Projectile latest from MEPLA (2015-10-something). Whenever I select a project on a remote TRAMP host, I get the following error from projectile-find-file:

[sh: /usr/local/bin/zsh: No such file or directory]

If I manually type in the name of a file I know is there, I can open it, but Projectile doesn't seem to be able to find the files itself (I've tried invalidating the cache).

Notably, /usr/local/bin/zsh is my shell on the local host, but not the remote host that I'm trying to load project files from.

If this is a different issue I can open a separate ticket, but it seemed related to these problems with TRAMP/Projectile integration more generally.

[Silex]

@tonycpsu: this looks like a different issue... probably simply a plain TRAMP issue, try to find out why there is a call to zsh in the first place.

[tonycpsu]

@Silex: I have no such problems if I disable projectile and simply use find-file and enter /ssh:host/path/file

[tonycpsu]

@Silex: I should also add thatido-find-file works fine as well.

[ackerleytng]

@tonycpsu, I am facing the same issue, with exactly the same situation. Did you finally find a fix? C-c p s s works though, as in using ag on the remote server

[KGZM]

@ackerleytng @tonycpsu Also having this problem. Did either of the two of you have any luck in solving it?

[ackerleytng]

I kind of forgot if I managed to fix it, but I vaguely remember having to install zsh on the remote side and placing a symlink to something that tramp expects

[Silex]

Will be closed by #1129