Skip to content
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

UI dir check in #2918 breaks on Windows #3229

Closed
slackpad opened this issue Jul 5, 2017 · 2 comments
Closed

UI dir check in #2918 breaks on Windows #3229

slackpad opened this issue Jul 5, 2017 · 2 comments
Labels
type/bug Feature does not function as expected

Comments

@slackpad
Copy link
Contributor

slackpad commented Jul 5, 2017

This captures the follow up from #2918 (comment):

This breaks for me on Windows, between using release 0.8.0 and 0.8.5. I do not use ui_dir (only ui set to true) in the config. Since upgrading, I now get that (incorrect) error message, and now it will not launch. Even adding in a line for "ui_dir": "" with blank string value I thought might work after looking at the diff, but does not. Maybe there is a default or something that only happens on Windows?

Simplified it down to this only to still reproduce the symptom:

{
  "addresses": {
    "http": "0.0.0.0"
  },
  "advertise_addr": "192.168.1.123",
  "datacenter": "foo",
  "log_level": "info",
  "node_name": "bar",
  "server": true,
  "ui": true
}

Results in log:

==> Both the ui and ui-dir flags were specified, please provide only one
@slackpad slackpad added the type/bug Feature does not function as expected label Jul 5, 2017
@tylerwalts
Copy link

Thanks @slackpad for the help. After looking closer, I am using choco to install and manage consul via nssm, and looking deeper into how it is launched I see that the CLI is passing the ui-dir arg in. Sorry for the false alarm and I'll leave this up in case anyone else has a similar issue:

image

My "fix" is to remove the "ui": true from my config, since the CLI arg sets the UI path out of box and it is redundant. Everything working as expected now 👍

@slackpad
Copy link
Contributor Author

slackpad commented Jul 6, 2017

Got it - thanks for the follow up @tylerwalts. Glad it was something simple - this one didn't make sense otherwise :-)

@slackpad slackpad closed this as completed Jul 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug Feature does not function as expected
Projects
None yet
Development

No branches or pull requests

2 participants