Consul fails to start if /etc/consul is not present

[tootedom]

Hi there,

I built from master an rpm and installed it on a fresh machine. However, consul fails to start with:

sudo cat /var/log/consul 
==> Error reading '/etc/consul': open /etc/consul: no such file or directory

This could be fixed by removing

-config-dir=/etc/consul

from: SOURCES/consul.sysconfig

However, I read the conversation on #45 which says this was kept for backwards compatibility. The only thing I could think of was to add the creation of /etc/consul back into the spec for consul. Not sure if this is how you wish to address consul not starting on fresh install.

Hope that explains the pull request.

cheers
/dom

[phrawzty]

#45 (comment)

We should probably think about how long we want to support the "backwards compatibility" - that's the sort of thing that comes back to bite you later.

😏

[phrawzty]

Perhaps we could consider a mechanism to determine whether this is a fresh install or an upgrade. Is there a way to do this RPM-native, or would we need to resort to janky conditionals?

[skj-dev]

It can be captured in the pre and post sections. Basically, if the first argument is 1, then it's an initial installation. If it's 2, then it's an upgrade. Just because RPM is RPM, in the case of preun and postun, 1 means an upgrade and 0 means an uninstall.

Hope that helps. :)

[mmraz]

What OS version is this occurring on? I'd want to validate the difference when using systemd versus init.

[lambdaknight]

I'm not the original poster, but I'm running into the same issue on CentOS Linux release 7.2.1511 (Core). Same issue happens with consul-template.

[phrawzty]

Ultimately this change is minor in that it doesn't affect core functionality. I'm OK to merge 40530c1 on the condition that we add a note about it in the README.

[lambdaknight]

I would suggest a similar change for consul-template. It similarly blows up when "/etc/consul-template" doesn't exist.

[duritong]

@rumenvasilev you are right the symlink could have been a possibility, but what should happen with the content that is now in /etc/consul ?

I would be in favor of moving out the situation and only supporting the standard directory. A post-script should move anything in /etc/consul to /etc/consul.d and then make a symlink. I know it will break a few situations (e.g. with the Puppet module, where the directory is being managed), but will they should be able to adapt their modules easily, especially as there is a consul_version fact.