[PUP-1055] "invalid byte sequence" with service provider upstart Created: 2013/12/16  Updated: 2018/08/21

Status: Accepted
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: redmine.exporter Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: i18n, redmine, service, type_and_provider, ubuntu, upstart, utf-8
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by PUP-3501 upstart provider fails with non-ASCII... Closed
Relates
relates to FACT-778 Puppet 3.7.3 doesn't run when started... Closed
Template:
Team: Platform OS

 Description   

I am sometimes getting "invalid byte sequence in US-ASCII" when using the Service type with the upstart provider. (I am not manually setting `provider => 'upstart'`, it is being set based on OS detection).
The problem seems to randomly pop up, and then goes away on its own. I did manage to capture the output of `agent --trace` during one run when the issue occurred.

This is with Ubuntu 12.04.1 and ruby 1.9.3-p0

Error: /Stage[main]/Ipa::Client::Basic/Service[sssd]: Could not evaluate: invalid byte sequence in US-ASCII
/usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:204:in `match'
/usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:204:in `match'
/usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:204:in `block in enabled_post_0_9_0?'
/usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:203:in `each_line'
/usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:203:in `enabled_post_0_9_0?'
/usr/lib/ruby/vendor_ruby/puppet/provider/service/upstart.rb:101:in `enabled?'
/usr/lib/ruby/vendor_ruby/puppet/type/service.rb:56:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1027:in `block in retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1022:in `each'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1022:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1041:in `retrieve_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:32:in `perform_changes'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:133:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:48:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:83:in `eval_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:103:in `block (2 levels) in evaluate'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:351:in `block in thinmark'
/usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:350:in `thinmark'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:103:in `block in evaluate'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:382:in `traverse'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:98:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:144:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:122:in `block in apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:179:in `block in benchmark'
/usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:178:in `benchmark'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:121:in `apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:179:in `run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (5 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (4 levels) in run'
/usr/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:119:in `with_client'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:42:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:84:in `run_in_fork'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `block in run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `call'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `controlled_run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:338:in `onetime'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:312:in `run_command'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:456:in `plugin_hook'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block in run'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:504:in `exit_on_fail'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:132:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:86:in `execute'
/usr/bin/puppet:4:in `<main>'



 Comments   
Comment by Benjamin Li [ 2014/06/02 ]

I'm seeing a very similar problem attempting to manage isc-dhcp-server on Ubuntu 14.04. I traced the problem to non-ASCII characters in /etc/init/isc-dhcp-server.conf:

description "ISC DHCP IPv4 server"
author "Stéphane Graber <stgraber@ubuntu.com>"
...

In my case the error happens every time, but the trace is almost identical to this one.

Comment by Adrian Reber [ 2014/10/25 ]

Same problem on Ubuntu 14.04 with isc-dhcp-server.

Comment by Andre Keller [ 2014/12/07 ]

Same with nsd, also on Ubuntu 14.04:

# nsd - Name Server Daemon
 
description "Name Server Daemon"
author "Ondřej Surý <ondrej@debian.org>"
...

Comment by Erik Lattimore [ 2015/03/11 ]

It seems that if you set the LANG=en_US.UTF-8 env variable of the puppet daemon (i.e. by modifying /etc/environment and restarting the daemon). Facter has issues (FACT-778) on OSX 10.10 relating to not setting the LANG env variable (which is typically set by our terminal and not by the OS) so maybe puppet needs to be initializing the environment correctly (I assume en_US.UTF-8 may not always be the right choice).

Comment by Glenn Schmidt [ 2015/09/02 ]

Same problem with php5-fpm, on Ubuntu 14.04

description "The PHP FastCGI Process Manager"
author "Ondřej Surý <ondrej@debian.org>"

Has anyone found a workaround other than to manually doctor these init scripts? They are installed by Debian packages, they're not part of the puppet manifest. And the agent run fails completely when this error occurs.

Interestingly it only happens for me when the agent runs automatically, NOT when I run puppet agent --test manually from the shell. Just as this user describes.

I've tried setting Encoding.default_external = Encoding::UTF_8 on the Puppet master, and setting LANG=en_US.UTF-8 on the agent in /etc/environment and also in /etc/default/puppet but these measures haven't made a difference.

Comment by Simon Deziel [ 2015/09/02 ]

My cron job wrapper includes this:

export LC_ALL="C.UTF-8"
...
puppet agent --onetime --no-daemonize --no-usecacheonfailure

HTH,
Simon

Comment by Alex Muntada [ 2015/12/07 ]

An important thing to notice in Ubuntu 14.04 is that this problem only occurs when puppet is started by systemd during the boot, where LANG is still undefined. But the problem disappears when puppet is restarted from a shell, where LANG is already defined:

# cat /proc/$(pgrep -f 'puppet agent')/environ | tr '\0' '\n' | grep ^LANG=
# service puppet restart
# cat /proc/$(pgrep -f 'puppet agent')/environ | tr '\0' '\n' | grep ^LANG=
LANG=en_US.UTF-8

Comment by Maggie Dreyer [ 2017/05/15 ]

Thank you for reporting this. We believe this issue has already been addressed in a later release of Puppet. If you experience this issue against the current version of Puppet, please add a comment to this ticket with your reproduction scenario.

For more info on getting the current version of Puppet Agent, see https://docs.puppet.com/puppet/latest/install_pre.html.

Comment by Martijn Heemels [ 2017/12/07 ]

I'm reopening because this is still an issue with the current version of the PC1 collection package. As far as I can tell both the package and the OS versions are still supported.

  • Linux: Ubuntu 14.04.5 LTS
  • Puppet Agent 4.10.9, installed from official PC1 collection repo (http://apt.puppetlabs.com trusty PC1)
  • System locale: LANG="en_US.UTF-8"
  • packages:
  • - puppetlabs-release-pc1: 1.1.0-4trusty
  • - puppet-agent: 1.10.9-1trusty

The behaviour exactly matches the symptoms described in this ticket: `Could not evaluate: invalid byte sequence in US-ASCII` on the PHP-FPM Service's init-script, due to UTF-8 characters being present.

The agent's environment on bootup:

UPSTART_INSTANCE=
runlevel=2
UPSTART_JOB=rc
TERM=linux
PATH=/sbin:/usr/sbin:/bin:/usr/bin
RUNLEVEL=2
PREVLEVEL=N
UPSTART_EVENTS=runlevel
PWD=/
previous=N

On service puppet restart:

TERM=linux
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/puppetlabs/bin
LANG=en_US.UTF-8
PWD=/

When LANG=en_US.UTF-8 is set, either by restarting from a login session or via /etc/default/puppet the run succeeds. On node bootup the puppet run gives the error, despite the global LANG being set to "en_US.UTF-8".

Generated at Thu Nov 21 03:54:50 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.