Process hang on FreeBSD

[Patrick Gibson]

I'm a first-time Puppet user, working with FreeBSD 9.2, Puppet 3.3.1, and Ruby 2.0. I'm starting out with a very simple setup to test the waters:

node 'myhost' {

  package { 'devel/jsmin':

    ensure  => 'installed',

    provider => 'ports'

  }

}

When I run:

puppet apply -v --debug manifests/site.pp

I get a bunch of output with various Linuxisms like selinux, rpm, apt-get, dpkg, etc (making me think I need to specify that this is a FreeBSD host?), and then:

Debug: Prefetching ports resources for package

Debug: Executing '/usr/sbin/pkg_info -aoQ'

Debug: Executing '/usr/sbin/pkg_info -aoQ'

Debug: Executing '/usr/local/sbin/portupgrade -N -M BATCH=yes devel/jsmin'

It all looks good, except that the process seems to stall out here. Running '/usr/local/sbin/portupgrade -N -M BATCH=yes devel/jsmin' manually works fine and completes in a few seconds. I can see from the `ps` listing that command is active, but it just sits there, not completing.

I'm not sure how to debug this any further. Is it considered a bad idea to run Puppet on a FreeBSD host? Based on my Google searches and amount of discussion around it, it seems like there are very few people who are doing this.

Any insight would be greatly appreciated.

Thanks,

Patrick

[Jeff Bachtel]

First, to clarify - do you have pkgng installed on your FreeBSD box? That is, should you be using /usr/sbin/pkg instead of /usr/local/bin/pkg_info if you are doing local package management?

If so, the current freebsd provider is not likely to work well for you, as it's pretty tied into the old framework. There's a new pkgng provider for freebsd+puppet available at https://github.com/xaque208/puppet-pkgng that might be worth trying.

Second, to debug you can try changing /usr/lib/ruby/site_ruby/1.8/puppet/provider/package/ports.rb (or equivalent, on FreeBSD that could all be under /usr/local/lib/ruby/site_ruby/2.0/puppet/provider/package/ports.rb or elsewhere) line 19 from

    cmd = %w{-N -M BATCH=yes} << @resource[:name]
to
    cmd = %w{-v -N -M BATCH=yes} << @resource[:name]

to turn on portupgrade's verbosity.

Third, no running Puppet on FreeBSD is not a bad idea. Lots of people work pretty hard to make it work, but it unfortunately doesn't get the exposure and attention that Linux does, and thus stuff might not be as well tested.

Jeff

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5f2d0086-69b5-4a5e-8d36-419e294f1695%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Russell A. Jackson]

On 12/17/2013 04:31 PM, Patrick Gibson wrote:
> Debug: Executing '/usr/local/sbin/portupgrade -N -M BATCH=yes devel/jsmin'

In short, out-of-the-box, puppet is broken on FreeBSD in regards to package
handling.

Portupgrade doesn't like being run with stdin not being a terminal. You'll
probably find you have a `script` process taking 100% cpu when you see it hang.
This problem has been around for a long time and still hasn't been fixed as far
as I know.

The default (freebsd) pkg_add binary package provider is also broken mainly
because the of heuristics that pkg_add -r use. You'll find this to a problem
when the symlink name under /Latest doesn't match the name that the package
records in the pkgdb. This leads to puppet trying to install the package on
every run.

If you install puppet from ports, it applies a patch to address this problem but
requires using the ports origin (like with the ports provider) as the package
name. Instead of using pkg_add -r, it downloads the ports index and looks up the
package name for a given ports origin and then supplies the specific url of the
full package name as a argument to pkg_add.

I have an updated version of this provider that fixes a number of issues as well
as supporting ensure => latest.

https://bitbucket.org/csub/puppet-module-freebsd

Be aware, having this module in your module path will mask the default freebsd
provider distributed with puppet.

There are also third party puppet modules that implement a provider for pkgng
that work well. If you can migrate to pkgng, I would strongly suggest doing so.

--
Russell A. Jackson <r...@csub.edu>
Network/Datacenter Operations
California State University, Bakersfield

[Derek Cole]

Just wanted to throw in that you should update to pkgng. pkg_add isnt even going to be an option in FreeBSD10. I have been using https://forge.puppetlabs.com/zleslie/pkgng successfully with FreeBSD10 Beta 3 and puppet.

[Patrick Gibson]

Thanks, all. I was originally hoping to just be able to build ports the old fashioned way, but have abandoned that route. I've upgraded to pkgng and am successfully using the zleslie/pkgng provider. Things are going well and I'm already very excited at how easy it's going to be to setup new systems. I'm at a point where the prebuilt packages weren't compiled with the options I needed, so I'm quickly learning all about poudriere and setting up a build machine.

One minor thing I've noticed whose only impact is cluttering up the important output is warning messages like:

/usr/local/lib/ruby/site_ruby/2.0/puppet/provider/package/freebsd.rb:18: warning: class variable access from top-level

Looking through the bug tracker, it seems there's been discussion and proposed solutions over the years, though perhaps they've not been applied globally? Do people see this on other platforms? Looking through some of the other providers, it seems like freebsd.rb is alone in its @@ usage.

Patrick

[Russell A. Jackson]

On 12/19/2013 04:44 PM, Patrick Gibson wrote:
> Thanks, all. I was originally hoping to just be able to build ports the old
> fashioned way, but have abandoned that route. I've upgraded to pkgng and am
> successfully using the zleslie/pkgng provider. Things are going well and
> I'm already very excited at how easy it's going to be to setup new systems.
> I'm at a point where the prebuilt packages weren't compiled with the
> options I needed, so I'm quickly learning all about poudriere and setting
> up a build machine.
>
> One minor thing I've noticed whose only impact is cluttering up the
> important output is warning messages like:
>
> /usr/local/lib/ruby/site_ruby/2.0/puppet/provider/package/freebsd.rb:18:
> warning: class variable access from top-level

The PACKAGE_ORIGIN patch needs to be disabled on the puppet port which is the
root cause of the warning. Someone should probably put in a PR to ports to
disable the patch by default so the default binary builds don't have it.

A hack'ish way to deal with it, as I have done, is to override the provider in a
module's lib directory by copying the standard provider ruby source file to
<modulename>/lib/puppet/provider/package/freebsd.rb.