Emacs hangs at contacting host

[danprince]

Trying to install spacemacs on Ubuntu 15.04.

I've moved the spacemacs files to ~/.emacs.d/, but when I start emacs I get a flash of the initial emacs window, then a black screen with

Contacting host: melpa.org:443

Once it opened with orgmode.org:80 instead, but I haven't been able to recreate that.

• Emacs works fine without the init file (emacs -q).
• Using emacs 24.4.1
• Using spacemacs 0.105.0
• emacs --debug-init produces no output
• I can curl https://melpa.org so not a network restriction

I've tried a fresh install of both emacs and spacemacs as well as using emacs, emacs24 and emacs24-x (but I'm not exactly sure what the differences are).

I've been writing Clojure for the last few months and I'm keen to beat some of the struggles I've been having with Lisp + Vim, but after five or six attempts, I've given in and resorted to putting in an issue. Any ideas?

[syl20bnr]

Can you try launching emacs with emacs --insecure to not use HTTPS to contact MELPA ?

[danprince]

Aha, that's how created the orgmode.org:80 hang. It starts with melpa.org:80 then switches to Contacting host: orgmode.org:80 and hangs there instead.

[danprince]

@syl20bnr Is it possible to install the packages manually from the repository? If so, will that prevent emacs from making that initial network request?

[greasynose]

@danprince I'm also meet this problem, do you solve it ?

[nickbdyer]

Did anyone find a solution to this?

[danprince]

I haven't solved this problem yet. I just tried building emacs 24.4 from source and I still have a similar problem with Spacemacs.

Running emacs and emacs-24.4 causes it to hang at:

Opening TLS connection to melpa.org...done

Running emacs --insecure causes it to hang at:

Contacting host: melpa.org

[liangwang]

The same issue as OP reported, and the issue is only observed on Linux, no problems on Windows and MacOS.

Using latest spacemacs (v0.105.14), and emacs 24.5 for all three platforms.

[wende]

I've got the same problem on OSX with Emacs v0.105.19

Running from finder instead of terminal fixed the issue

[myme5261314]

Also meeting this issue, even though I've replaced melpa, org and gnu urls to the China mirror, It takes at least 5 minutes or more staying echo the contacting host: elpa.zilongshanren.com:80. @zilongshanren The only way I found for now to work with it is just wait, maybe 10 minutes, maybe 30 minutes, it varies. I'm on Ubuntu 14.04, using Emacs 24.5.1, spacemeacs 0.105.20

[zilongshanren]

@myme5261314 Try to disable https?

[myme5261314]

Yes

  (setq-default
   ;; If non nil ELPA repositories are contacted via HTTPS whenever it's
   ;; possible. Set it to nil if you have no way to use HTTPS in your
   ;; environment, otherwise it is strongly recommended to let it set to t.
   ;; This variable has no effect if Emacs is launched with the parameter
   ;; `--insecure' which forces the value of this variable to nil.
   ;; (default t)
   dotspacemacs-elpa-https nil
   ;; Maximum allowed time in seconds to contact an ELPA repository.
   dotspacemacs-elpa-timeout 5

But the funny thing is that the dotspacemacs-elpa-timeout 5 seems have no effects, it just hang on for more than 5 seconds.

@zilongshanren don't make it wrong, it's not caused by the mirror, the problem exists while using melpa outside China, refer to the issue author.

[necto]

Similar issue here. I wanted to bootstrap spacemacs on a new ubuntu 14.04 machine. Tried multiple emacs versions.

• 24.3 kinda works - it manages to download packages, but then some packages do not work with emacs version lower than 24.4.
• 24.4, 24.5, 25.1, no matter if I add --insecure option or not, hangs on

contacting host: melpa.org:443

And becomes unresponsive (5 sec timeout in .spacemacs clearly does not work). --debug-init does not help, as it hangs right after start. I can interrupt the init process by C-G C-G, but then I can not exit emacs, as C-x C-c nor SPC q q do not work.

[myme5261314]

Actually, don't know why, after a long holiday, my issue described above was gone and it exists before the holiday. Using the china mirrors won't hang up. Just for reference.

[snaphuman]

Hi. I have an emacs config that remained almost the same through several emacs updates and I did not change how emacs contact melpa repositories. So checking melpa documentation I noticed that my config was pointing to http://melpa.milkbox.net/packages as shown in the following code snippet

'(package-archives (quote (("melpa" . "http://melpa.milkbox.net/packages/") ("gnu" . "http://elpa.gnu.org/packages/"))))

Changing this config to as recommended in melpa.org solved the issue to me:

(require 'package) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/")) (when (< emacs-major-version 24) (add-to-list 'package-archives '("gnu" . "http://elpa.gnu.org/packages/")))

Hope this helps

[ghost]

I had the same issue just now. It happened after I added html to the existing dotspacemacs-configuration-layers list in my ~/.spacemacs per the HTML layer instructions, and closed Spacemacs.

When I next started Spacemacs, it hung. Above the mode line, it said:

Found 9 new package(s) to install...
--> refreshing package archive: melpa... [1/3]

Below the mode line, it said: Contacting host: melpa.org:443

After several minutes, Spacemacs gave the following messages above the mode line:

9 errors at startup! Spacemacs may not be able to operate properly.
Warning (spacemacs): 
Error connection time out for melpa repository!

and the following below the mode line:

Leaving directory `/home/sampablokuper/.emacs.d/elpa/haml-mode-20150508.2011'

Compiling file /home/sampablokuper/.emacs.d/elpa/haml-mode-20150508.2011/haml-mode-pkg.el at Tue Aug 16 20:53:16 2016
Entering directory `/home/sampablokuper/.emacs.d/elpa/haml-mode-20150508.2011/'

Compiling file /home/sampablokuper/.emacs.d/elpa/haml-mode-20150508.2011/haml-mode.el at Tue Aug 16 20:53:16 2016

In haml-fontify-region:
haml-mode.el:134:14:Warning: `font-lock-syntactic-keywords' is an obsolete
    variable (as of 24.1); use `syntax-propertize-function' instead.

In haml-fontify-region-as-javascript:
haml-mode.el:174:43:Warning: reference to free variable
    `js--font-lock-keywords-3'
haml-mode.el:175:56:Warning: reference to free variable
    `js-font-lock-keywords-3'
haml-mode.el:176:47:Warning: reference to free variable `js-mode-syntax-table'
haml-mode.el:177:60:Warning: reference to free variable
    `javascript-mode-syntax-table'
haml-mode.el:180:61:Warning: reference to free variable
    `js--quick-match-re-func'

In haml-fontify-region-as-markdown:
haml-mode.el:202:28:Warning: reference to free variable
    `markdown-mode-syntax-table'

In haml-maybe-extend-region:
haml-mode.el:386:18:Warning: reference to free variable `font-lock-beg'
haml-mode.el:390:17:Warning: reference to free variable `font-lock-end'
haml-mode.el:390:55:Warning: assignment to free variable `font-lock-beg'
haml-mode.el:392:21:Warning: assignment to free variable `font-lock-end'

Compiling no file at Tue Aug 16 20:53:18 2016

I tried restarting Spacemacs a couple of times, with similar results.

Update: A day later, and restarting Spacemacs worked fine, without any of the warnings above.

[wudixiaotie]

The reason is mepla.org is not stable. I use an agent based in US, still can't open page Multiple-Cursors from melpa. Got an Error: 503 Service Unavailable

[ghost]

The reason is mepla.org [sic] is not stable.

It's true that melpa.org is sometimes down. Additionally, it might sometimes be unreachable for other reasons outside the melpa maintainers' control, e.g. client misconfiguration, or unreliable internet connectivity. But even if Spacemacs can't reach melpa.org, or if melpa.org returns an error when Spacemacs does reach it, Spacemacs ideally ought not to hang :)

[d12frosted]

@sampablokuper Indeed it should hang. I've sent PR that advocates this issue.

[ghost]

@d12frosted

Indeed it should hang. I've sent PR that advocates this issue.

I'm not yet sufficiently literate in Emacs Lisp to grok your PR, but I think it means that if Spacemacs can't reach a repository (e.g. Melpa), then it will hang with the following error:

Archive '%s' is not available. Please verify that you have internet connection and you are able to connect to +%s.

That's definitely more helpful than the current feedback, but it would be nice if the feedback would additionally give the user a clearly stated means to bypass the hang, deferring whatever it was that Spacemacs was trying to do with the currently-unreachable repository until the next time Spacemacs is started. E.g.

Archive '%s' is not available. Please verify that you have internet connection and you are able to connect to +%s. Alternatively, press foo bar to skip this operation until the next time Spacemacs is run.

I'm not sure what the most user-friendly key binding would be, which is why I just wrote foo bar. Maybe something like SPC e s for "Spacemacs error skip"?

Anyhow, it's great that you're working to improve the issue. Thanks!

[d12frosted]

@sampablokuper :

but I think the implication is that if Spacemacs can't reach a repository (e.g. Melpa), then it will hang with the following error

Yes, you understood it correctly.

That's definitely more helpful than the current feedback, but it would be nice if the feedback would additionally give the user a clearly stated means to bypass the hang

I don't see any way to help with connectivity problem without looking into specific case. Bad internet connection, walls and other stuff can't be and should not be fixed from Spacemacs side. That's why it states Please verify that you have internet connection and you are able to connect to %s.. And sometimes archive is just down. And again, you have to verify that you can connect manually to the server using printed link. This message is not ideal. But my point is that it should not provide recipes for solving internet connection troubles. Documentation is better place for this.

Alternatively, press foo bar to skip this operation until the next time Spacemacs is run.

In some cases it makes no sense. I mean, if it's fresh install and MELPA is not available - Spacemacs can't function anyway. Because core itself uses a lot of third-party packages. If you let people pass though this error - they'll get messages like 'package-*** is not available' and it will be even more misleading. When Spacemacs tries to install package - package is required somehow. Not having this package installed is undefined behaviour. Trying to be as friendly as possible also means mitigating undefined behaviour 😸 At least in my opinion.

Anyhow, it's great that you're working to improve the issue. Thanks!

There is room for improvement 😸 Ideally I would like to have fallback package archive to be used when one of third-party package archives is down. So ideally user should never see that error (except for missing internet connection).

[ghost]

@d12frosted thanks for the clarifications.

Bad internet connection, walls and other stuff can't be and should not be fixed from Spacemacs side.

Agreed. But even if the user's internet connection (or Melpa, etc) is down, that should never prevent the user from running Spacemacs, if Spacemacs and its core dependencies are already installed on the user's computer. Right?

A key reason to use locally installed software like Spacemacs rather than a "cloud" service is to be able to get work done without being dependent upon having a good connection to some remote server.

[TheBB]

But even if the user's internet connection (or Melpa, etc) is down, that should never prevent the user from running Spacemacs, if Spacemacs and its core dependencies are already installed on the user's computer. Right?

Nor will it, unless you have changed the configuration somehow so that additional packages are needed.

I don't mean to suggest that the current state of affairs is fine, but do please understand that Spacemacs hangs because it's trying to install stuff that you told it to install.

[d12frosted]

if Spacemacs and its core dependencies are already installed on the user's computer. Right?

In my opinion - not. If Spacemacs tries to install something - then this something is missing, so Spacemacs can't operate correctly. But I wonder what @TheBB and @syl20bnr think about it 💃

A key reason to use locally installed software like Spacemacs rather than a "cloud" service is to be able to get work done without being dependent upon having a good connection to some remote server.

If everything is installed you don't have to be online anymore. If you wish additional functionality that has dependencies that are not yet installed - you need internet connection again :(

---

Oh, @TheBB is fast 😸

I don't mean to suggest that the current state of affairs is fine, but do please understand that Spacemacs hangs because it's trying to install stuff that you told it to install.

Yeah, exactly. 😸 💯

[necto]

I agree that Spacemacs must be operational with or without Internet connection. If it is not the first launch, then it should keep the latest working setup, and if the repo is unavailable - backup to the latest working setup. Otherwise people can never rely on it as a primary editor.

[TheBB]

Since user configuration can be arbitrarily complex, there's no truly reliable way for us to keep track of the last working setup. I'm interested to hear suggestions as to what that could look like.

[necto]

Well, I see it as keeping the latest working .spacemacs config file (shadow copy) somewhere hidden in .emacs.d and packets all working. When Spacemacs loads up, and sees the configuration changed, it first checks the connection, then (if the repo is available) it updates and downloads necessary packets, then it copies the new .spacemacs replacing the shadow copy. If there is no connection, it reports it to the user, and loads up the shadow copy, that was working last time.

[ghost]

@d12frosted wrote:

@TheBB wrote: I don't mean to suggest that the current state of affairs is fine, but do please understand that Spacemacs hangs because it's trying to install stuff that you told it to install.

Yeah, exactly.

Yes, I understood all that before making my comments above, and my points still stand.

Here was my use case:

• I had an internet connection.
• As far as I was aware, Melpa was up.
• I had an HTML file I needed to edit.
• I wanted to edit it in Spacemacs, ideally using the HTML layer.
• I didn't have the Spacemacs HTML layer installed.
• I added html to the existing dotspacemacs-configuration-layers list in my ~/.spacemacs per the instructions, and restarted Spacemacs.

Every one of these points is reasonable, right?

But it turned out that at the moment Spacemacs restarted, either Melpa was down or returning errors (or perhaps my internet connection became flaky?), so Spacemacs hung. It hung with no immediately discoverable cause and no immediately discoverable remedy that would let me at least get on and edit my file in Spacemacs. It was not, at that point, clear to me that Spacemacs had hung because I had html to the existing dotspacemacs-configuration-layers list in my ~/.spacemacs and Spacemacs couldn't reach Melpa to download the HTML layer. (It was not until I found this bug report that I was confident that this had been the cause.)

That meant that at that point I couldn't readily edit that HTML file in Spacemacs. I had to choose between troubleshooting Spacemacs, or just using another text editor.

When Spacemacs prevents the user from using Spacemacs, that is a showstopper bug in Spacemacs.

This is why I made my suggestion above, which if implemented would fix this bug.

Thanks for your time :)

[TheBB]

Well, I see it as keeping the latest working .spacemacs config file (shadow copy) somewhere hidden in .emacs.d and packets all working. When Spacemacs loads up, and sees the configuration changed, it first checks the connection, then (if the repo is available) it updates and downloads necessary packets, then it copies the new .spacemacs replacing the shadow copy. If there is no connection, it reports it to the user, and loads up the shadow copy, that was working last time.

Unfortunately there's no guarantee that the user configuration is entirely contained in the dotfile, or even that all the layers used can be inferred from the dotfile alone, nor is it guaranteed that if the list of layers are the same, then the list of packages are also the same.

Examples:

• I have a private layer that loads the theming layer. It's not possible to determine a priori from my dotfile alone that the theming layer will be loaded. (As it happens, the theming layer doesn't need any packages.)
• Package download can be triggered if layers are changed, not just if the dotfile changes. That means the last known good state also depends on the current .emacs.d git commit as well as the state of the entire layer load path, which may include directories that are not managed by git at all.
• Some packages are toggled on or off depending on circumstances. Usually these are simple user settings, but in the case of e.g. tern it checks for the existence of a tern executable on your system, a condition that cannot be reproduced by rolling back a config.

As far as I'm concerned this is far too complicated to get right, and getting it half-right isn't worth the trouble. It is much more achievable to

• warn the user in case this happens, and
• possibly treat the missing packages as excluded rather than “hoping for the best” (this is also not guaranteed to always work, but at least the mechanism for it exists already)

[d12frosted]

@sampablokuper

(re: hanging and skipping connectivity errors)

But it turned out that at the moment Spacemacs restarted, either Melpa was down or returning errors (or perhaps my internet connection became flaky?), so Spacemacs hung. It hung with no immediately discoverable cause and no immediately discoverable remedy that would let me at least get on and edit my file in Spacemacs. It was not, at that point, clear to me that Spacemacs had hung because I had html to the existing dotspacemacs-configuration-layers list in my ~/.spacemacs and Spacemacs couldn't reach Melpa to download the HTML layer. (It was not until I found this bug report that I was confident that this had been the cause.)

Just to clarify. I don't think that this is desired behaviour. That's why I am working on improving it. And thanks for bringing that up 😸

When Spacemacs prevents the user from using Spacemacs, that is a showstopper bug in Spacemacs.

While that sounds right, users should be responsible for the changes they do in their configurations (which can be scattered across many different files). Using your example, if I want to edit html file, but I am offline and html layer is not yet enabled - Spacemacs physically can't help me with editing html files, because it misses required packages. If we allow user to skip that 'error', behaviour of Spacemacs is undefined. Whenever I hit similar situation - I just don't enable required layer and edit file in other mode (even fundamental-mode is helpful enough in most cases).

We probably should add suggestions when it's impossible to download required packages. E. g. ask user to disable specific layer or remove package from list of additional packages. So Spacemacs can start properly. Also, probably lazy installation flow should not propose user to enable layer if package archives are not reachable.

---

(re: rollback to last working config)

@TheBB nice examples you bring up here. Also in some cases some packages depend on .dir-locals.el. For example, with completion backend in haskell layer.

And as another example - Spacemacs actually can be loaded manually. I store Spacemacs in ~/.spacemacs.d and load it manually from ~/.emacs.d/init.el. So again, breaking changes might come outside of Spacemacs :/

As far as I'm concerned this is far too complicated to get right, and getting it half-right isn't worth the trouble.

Exactly.

[ghost]

@d12frosted wrote:

Just to clarify. I don't think that this is desired behaviour. That's why I am working on improving it. And thanks for bringing that up.

You're welcome, and thanks to you, too!

Using your example, if I want to edit html file, but I am offline and html layer is not yet enabled - Spacemacs physically can't help me with editing html files, because it misses required packages.

That's different to my example.

In my example, before I added html to the existing dotspacemacs-configuration-layers list in my ~/.spacemacs, Spacemacs was able to help me edit HTML files. That is because HTML files are text files and Spacemacs is a text editor, and Spacemacs at that point was letting me edit text files and was not hanging.

If we allow user to skip that 'error', behaviour of Spacemacs is undefined.

Maybe at the moment, but not necessarily. The solution is to define the behaviour of Spacemacs in such a case. That would be much better than having Spacemacs just hang, which doesn't help the user at all.

The first bit of behaviour to implement would be better feedback: inform the user of the trouble Spacemacs has encountered. It's great that you're working on this!

The next bit of behaviour to implement would be to give the user a good way to get out of that trouble.

A common user interface pattern for this is "safe mode". Windows used to have this; maybe it still does. Some web browsers, likewise. The idea of a "safe mode" is that it won't give you all the functionality you would ideally have, but it will dependably give you enough functionality to get basic things done (e.g. edit text files) until you have finished troubleshooting whatever it is that was preventing the full desired functionality from being achieved. That is the essence of what I advocated in my earlier comment, but I hope that giving a name to it (i.e. "safe mode") will make my suggestion clearer. By "an option to bypass the hang", I essentially mean "an option to enter Spacemacs Safe Mode".

The more functional that safe mode is, the better, as long as Safe Mode is dependable. Invoking Safe Mode should never cause Spacemacs to hang: it should always provide at least the functionality offered by an unmodified Spacemacs install.

One way to achieve this might be to ship Spacemacs with a read-only "safe mode" configuration in addition to the user-editable configuration. The former would contain comments explaining its purpose and advising the user not to modify or delete it.

Upon invocation of Safe Mode, Spacemacs would then load that "safe mode" configuration instead of the user's configuration.

There, that's it; that would provide an adequate fix for this issue :)

A more sophisticated refinement of that idea, if anyone got really keen, would be for Spacemacs to tentatively load each part of the user's configuration after having loaded the "safe mode" configuration. By "tentatively", I mean something like, "For each function in the user's configuration, attempt to run that function, but if it returns an error or takes more than a few seconds to return, then skip it and move on to the next function." If that worked robustly, then even if the whole of the user's config couldn't be loaded, at least the end result would work and it would also be configured as closely to the user's desired behaviour as possible without hanging.

Whenever I hit similar situation - I just don't enable required layer and edit file in other mode (even fundamental-mode is helpful enough in most cases).

Sure, but if the user is unaware of what is causing Spacemacs to hang or how to stop it hanging, then (a) this resolution might not be obvious to them, and (b) they had better have another text editor handy, because while Spacemacs is hanging, they can't use Spacemacs to revert the addition they made to their ~/.spacemacs file that is resulting in the hang. Which is why I am proposing a fix that would solve (a) and (b) :)

We probably should add suggestions when it's impossible to download required packages. E. g. ask user to disable specific layer or remove package from list of additional packages. So Spacemacs can start properly.

If this were implemented entirely within Spacemacs, that would be great: much better than hanging! Ideally, the user should not have to invoke another text editor in order to fix the problem.

Also, probably lazy installation flow should not propose user to enable layer if package archives are not reachable.

I see where you're coming from here, but I disagree with this specific implementation suggestion. There is a temporal consideration here. When a user adds a layer's name to their config, they are not saying to Spacemacs, "Download and install this layer right now!" What they are instead saying to Spacemacs is, "Next time you load this config, please try to download and install this layer; and if at that point you can't download or install it, then don't hang or otherwise interrupt my productivity, just inform me what it was that you couldn't do and why, and give me the option to ask you to try again next time you load this config."

Thanks again :)