php5-fpm service fails with "invalid byte sequence in US-ASCII"

[mbrodala]

The php5-fpm service fails to start on Ubuntu Trusty with an error message like this:

Error: /Stage[main]/Php::Fpm::Service/Service[php5-fpm]: Could not evaluate: invalid byte sequence in US-ASCII
Notice: /Stage[main]/Php::Fpm/Anchor[::php::fpm::end]: Dependency Service[php5-fpm] has failures: true
Warning: /Stage[main]/Php::Fpm/Anchor[::php::fpm::end]: Skipping because of failed dependencies
Notice: /Stage[main]/Php/Anchor[php::end]: Dependency Service[php5-fpm] has failures: true
Warning: /Stage[main]/Php/Anchor[php::end]: Skipping because of failed dependencies

The issue comes from the file /etc/init/php5-fpm.conf which contains some non-ascii characters for the upstart script author Ondřej Surý. Manually replacing this with pure ASCII characters fixes the issue.

Since I am not sure who can fix this issue I am adding it here for others to find.

See also this issue on ask.puppetlabs.com and in cookbook-php-fpm.

[fpletz]

Thanks for reporting and making us aware of this. I'm not sure, however, if we should fix this or rather forward this to Ondřej because we're no managing the php-fpm upstart config at /etc/init/php-fpm.conf.

But I wonder why we don't have this problems as we're also mostly running Ubuntu trusty here. Maybe some environmental differences. Will investigate.

[mbrodala]

Not sure if forwarding this will yield a thing since Ondřej already said this:

JFTR I do not intend to cripple my name (since I was asked) - you should fix that in Chef. For goddess' sake it's 2014 and we use UTF-8 for years now!

It might very well be a Puppet issue, but I wanted to be sure other users of this module are able to find this report and an interim solution. For the record, this is the locale output on my machine:

LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Some people suggest setting e.g. en_US.UTF-8 as locale which needs to be done for the user Puppet is executed with (usually root) but I had no success with this so far.

[mbrodala]

Here is the upstream report for Puppet: upstart provider fails with non-ASCII characters in job conf file with a non-UTF8 locale.

I suggest watching that report and adding info as necessary but keep this one open until a fix is applied in Puppet.

[mbrodala]

Here's the umbrella task in Puppet and I have yet to grasp the gist of it:

Improve Puppet's handling of non-ASCII character encodings

[Yamakasi]

I have the same problem with this on Ubuntu. Is there any solution yet as I'm not able to find any working ones.

[mbrodala]

@Yamakasi ATM only to locally edit the mentioned file and replace/remove the non-ASCII characters.

[Yamakasi]

@mbrodala Sorry for my delay, but you say replace/remove, which file and which non-ASCII characters as I'm not using one in my own manifests.

[mbrodala]

@Yamakasi Have a look at my initial post. The file is shipped with the package.

[globin]

I'm not sure what we should do here as this technically is a bug in puppet and not in the module code. We could replace the init file or do some hackery to avoid this but I'm not sure it's worth it. If someone has a nice solution feel free to reopen or submit a PR and let's hope Puppet gets this right soon.

[dmk-ralf-urban]

I solved the problem for me in this way: I added in the field "Supported Locales" the string "cs_CZ.UTF-8". I have several languages added: "en_US.UTF-8", "fr_FR.UTF-8", "it_IT.UTF-8"

[timothydc]

Adding the "cs_CZ.UTF-8" to locales did not work for me.
I had to set a default locale . ( in my case I used en_GB.UTF-8 )

[Yamakasi]

I just overpuppetized that string in it's startscript... much better and never an issue anymore.

[mbrodala]

@Yamakasi Could tell us more details here?

[Yamakasi]

@mbrodala simple, just create your own php5-fpm.conf.erb and remove the Characters from his name.

Done

[mbrodala]

That's one solution, thanks.

[tnory56]

This worked for me after a vagrant destroy
puphpet/puphpet#1792

[mbrodala]

For the record we are currently using a workaround like this in our Vagrantfile:

config.vm.provision "puppet" do |puppet|
  # ...
  puppet.facter = {
    # Specifying the LANG environment variable this way is a work around.
    # The work around can be removed when this issue is fixed https://github.com/mitchellh/vagrant/issues/2270
    "hack=hack LANG=en_US.UTF-8 hack" => "hack"
  }
end

We are also using a Puppet module (saz-locales) to ensure this locale is present.