Details
-
Type:
Bug
-
Status: Accepted
-
Priority:
Normal
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:
Ubuntu 14.04 LTS 64bit
Repository: puppetlabs-release-pc1-trusty.deb
-
Template:customfield_10700 86952
Description
Faulty LOCALE settings will cause puppetserver to abort at installation
root@pm01:~# apt-get install puppetserver
Reading package lists... Done
Building dependency tree
Reading state information... Done
puppetserver is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "nb_NO.UTF-8",
LC_MONETARY = "nb_NO.UTF-8",
LC_CTYPE = "en_US.UTF-8",
LC_ADDRESS = "nb_NO.UTF-8",
LC_TELEPHONE = "nb_NO.UTF-8",
LC_NAME = "nb_NO.UTF-8",
LC_MEASUREMENT = "nb_NO.UTF-8",
LC_IDENTIFICATION = "nb_NO.UTF-8",
LC_NUMERIC = "nb_NO.UTF-8",
LC_PAPER = "nb_NO.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up puppetserver (2.1.1-1puppetlabs1) ...
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
/opt/puppetlabs/server/apps/puppetserver/scripts/install.sh: line 224: 6901 Aborted (core dumped) /opt/puppetlabs/puppet/bin/puppet config set --section master vardir /opt/puppetlabs/server/data/puppetserver
dpkg: error processing package puppetserver (--configure):
subprocess installed post-installation script returned error exit status 134
Errors were encountered while processing:
puppetserver
E: Sub-process /usr/bin/dpkg returned an error code (1)
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Zendesk Support
- Links Explorer
This is due to the locales on the system. Native facter will not run without a valid locale set. In this case, it core dumps, which isn't the best user experience, but the solution is to resolve the locale issues on the system. Some googling on the perl errors turned up several stack overflow posts. They all suggested some combination of removing/purging the locales package, reconfiguring it, and regenerating the locales.
- http://ubuntuforums.org/showthread.php?t=1720356
- http://unix.stackexchange.com/questions/110757/locale-not-found-setting-locale-failed-what-should-i-do
- https://www.thomas-krenn.com/en/wiki/Perl_warning_Setting_locale_failed_in_Debian
- http://stackoverflow.com/questions/21816121/ubuntu-server-strange-locale-issue
I have linked a ticket I opened about facter handling bad locales more gracefully.
Thanks, I did not post this issue because my faulty locale settings. But due to puppet handling it in the wrong way 
Frank Solli
added a comment - Thanks, I did not post this issue because my faulty locale settings. But due to puppet handling it in the wrong way Past Haus so, your expectation is that once the related Facter ticket is resolved, this issue will go away? You don't expect any packaging changes to be necessary for Puppet Server?
Chris Price
added a comment - Past Haus so, your expectation is that once the related Facter ticket is resolved, this issue will go away? You don't expect any packaging changes to be necessary for Puppet Server? I'm not sure if the facter ticket will resolve this issue or not. If the resolution for that is to just make a cleaner exception with bad locale, then the problem might persist. If the resolution is to continue past the exception, the problem should go away.
I'm not sure that any changes to puppet server will help here. If we had clean config separation, we wouldn't need to call out to `puppet config set` here, which would avoid this problem here.
However, even if we get past installation, I'm not sure puppetserver itself will be able to run. If loading facter from ruby (as puppet does), causes a core dump, I have to imagine that loading it from jruby, (as puppetserver does) will also core dump.
I think we should probably try to make sure the facter fix allows for a clean run even with a bad locale.
I've got a PR open for FACT-1123 that will make it proceed if the locale is busted (printing a warning that it is falling back to the "C" locale). This will prevent facter from crashing and will allow it to stumble forward, but could cause funkiness if any localized data is actually used in a fact resolution. I don't believe that this will impact any core facts.
Branan Riley
added a comment - I've got a PR open for FACT-1123 that will make it proceed if the locale is busted (printing a warning that it is falling back to the "C" locale). This will prevent facter from crashing and will allow it to stumble forward, but could cause funkiness if any localized data is actually used in a fact resolution. I don't believe that this will impact any core facts. Notes from backlog grooming:
It looks like the related Facter PR has been merged.
From reading the conversation in FACT-1123, it sounds like the Facter side of this has been resolved and that someone should be able to test whether installing Puppet Server with a puppet-agent pulled from a nightly build, e.g., http://nightlies.puppetlabs.com/puppet-agent/8abae21edbcb02b9dc69be5bbb2b705782906416/, would still show the problem.
Jeremy Barlow
added a comment - From reading the conversation in FACT-1123 , it sounds like the Facter side of this has been resolved and that someone should be able to test whether installing Puppet Server with a puppet-agent pulled from a nightly build, e.g., http://nightlies.puppetlabs.com/puppet-agent/8abae21edbcb02b9dc69be5bbb2b705782906416/ , would still show the problem. Moses Mendoza I bet you can validate that this issue has been fixed.
Past Haus Rob Braden any ideas on this?