PuppetDB
  1. PuppetDB
  2. PDB-377

Can't start puppetdb after upgrade to 1.6.0-1.fc19.noarch

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.6.0
    • Fix Version/s: 1.6.2
    • Component/s: None
    • Labels:
      None
    • Environment:

      Fedora 19 x86_64

    • Story Points:
      3

      Description

      yum-cron got me puppetdb-1.6.0-1.fc19.noarch and puppetdb-terminus-1.6.0-1.fc19.noarch earlier today. Now I cannot get the service to start:

      java[11322]: java.lang.NullPointerException: null
      java[11322]: at clojure.lang.RT.intCast (RT.java:1087)
      java[11322]: com.puppetlabs.jdbc$make_connection_pool.invoke (jdbc.clj:293)
      java[11322]: com.puppetlabs.jdbc$pooled_datasource.invoke (jdbc.clj:323)
      java[11322]: com.puppetlabs.puppetdb.cli.services$_main.doInvoke (services.clj:242)
      java[11322]: clojure.lang.RestFn.invoke (RestFn.java:421)
      java[11322]: clojure.lang.Var.invoke (Var.java:419)
      java[11322]: clojure.lang.AFn.applyToHelper (AFn.java:163)
      java[11322]: clojure.lang.Var.applyTo (Var.java:532)
      java[11322]: clojure.core$apply.invoke (core.clj:617)
      java[11322]: com.puppetlabs.puppetdb.core$run_command.invoke (core.clj:87)
      java[11322]: com.puppetlabs.puppetdb.core$_main.doInvoke (core.clj:95)
      java[11322]: clojure.lang.RestFn.applyTo (RestFn.java:137)
      java[11322]: com.puppetlabs.puppetdb.core.main (:-1)
      systemd[1]: puppetdb.service: main process exited, code=exited, status=1/FAILURE
      kill[11350]: Usage:
      kill[11350]: kill [options] <pid|name> [...]
      kill[11350]: Options:
      kill[11350]: -a, --all do not restrict the name-to-pid conversion to processes
      kill[11350]: with the same uid as the present process
      kill[11350]: -s, --signal <sig> send specified signal
      kill[11350]: -q, --queue <sig> use sigqueue(2) rather than kill(2)
      kill[11350]: -p, --pid print pids without signaling them
      kill[11350]: -l, --list [=<signal>] list signal names, or convert one to a name
      kill[11350]: -L, --table list signal names and numbers
      kill[11350]: -h, --help display this help and exit
      kill[11350]: -V, --version output version information and exit
      kill[11350]: For more details see kill(1).
      systemd[1]: puppetdb.service: control process exited, code=exited status=1
      systemd[1]: Unit puppetdb.service entered failed state.

        Activity

        Hide
        Ryan Senior added a comment -

        Can you post your database.ini file? I'm in #puppet on freenode (rsenior) as well if you want to troubleshoot it real-time.

        Show
        Ryan Senior added a comment - Can you post your database.ini file? I'm in #puppet on freenode (rsenior) as well if you want to troubleshoot it real-time.
        Hide
        John Florian added a comment - - edited

        Sure thing Ryan. Here ya go:

        [database]
        # For the embedded DB: org.hsqldb.jdbcDriver
        # For PostgreSQL: org.postgresql.Driver
        # Defaults to embedded DB
        classname = org.hsqldb.jdbcDriver
        
        # For the embedded DB: hsqldb
        # For PostgreSQL: postgresql
        # Defaults to embedded DB
        subprotocol = hsqldb
        
        # For the embedded DB: file:/path/to/database;hsqldb.tx=mvcc;sql.syntax_pgs=true
        # For PostgreSQL: //host:port/databaseName
        # Defaults to embedded DB located in <vardir>/db
        subname = file:/var/lib/puppetdb/db/db;hsqldb.tx=mvcc;sql.syntax_pgs=true
        
        # Connect as a specific user
        # username = foobar
        
        # Use a specific password
        # password = foobar
        
        # How often (in minutes) to compact the database
        # gc-interval = 60
        
        # Number of seconds before any SQL query is considered 'slow'; offending
        # queries will not be interrupted, but will be logged at the WARN log level.
        log-slow-statements = 10
        

        I'm new to IRC, but believe I'm connected to freenode #puppet as jflorian.

        FWIW, I've removed all traces of my puppetdb install (yum remove plus all configs, logs, etc.) and did a fresh yum install puppetdb. This didn't help. I get the exact same NPE.

        Show
        John Florian added a comment - - edited Sure thing Ryan. Here ya go: [database] # For the embedded DB: org.hsqldb.jdbcDriver # For PostgreSQL: org.postgresql.Driver # Defaults to embedded DB classname = org.hsqldb.jdbcDriver # For the embedded DB: hsqldb # For PostgreSQL: postgresql # Defaults to embedded DB subprotocol = hsqldb # For the embedded DB: file:/path/to/database;hsqldb.tx=mvcc;sql.syntax_pgs= true # For PostgreSQL: //host:port/databaseName # Defaults to embedded DB located in <vardir>/db subname = file:/ var /lib/puppetdb/db/db;hsqldb.tx=mvcc;sql.syntax_pgs= true # Connect as a specific user # username = foobar # Use a specific password # password = foobar # How often (in minutes) to compact the database # gc-interval = 60 # Number of seconds before any SQL query is considered 'slow'; offending # queries will not be interrupted, but will be logged at the WARN log level. log-slow-statements = 10 I'm new to IRC, but believe I'm connected to freenode #puppet as jflorian. FWIW, I've removed all traces of my puppetdb install (yum remove plus all configs, logs, etc.) and did a fresh yum install puppetdb. This didn't help. I get the exact same NPE.
        Hide
        Ryan Senior added a comment -

        I've done some debugging with John. It looks to me like a packaging or maybe scripts issue, not sure. The error indicates a bad database.ini config, but the config is the stock config. The config by itself runs fine outside of Fedora. Running 1.6.0 from the source directly on Fedora did not have issues either. I have reproduce it on FC18, John has reproduced it on FC19 and FC20.

        I'll write up a separate issue for this, but it looks like logging information for Fedora is going directly to /var/log/messages, rather than /var/log/puppetdb/*

        Show
        Ryan Senior added a comment - I've done some debugging with John. It looks to me like a packaging or maybe scripts issue, not sure. The error indicates a bad database.ini config, but the config is the stock config. The config by itself runs fine outside of Fedora. Running 1.6.0 from the source directly on Fedora did not have issues either. I have reproduce it on FC18, John has reproduced it on FC19 and FC20. I'll write up a separate issue for this, but it looks like logging information for Fedora is going directly to /var/log/messages, rather than /var/log/puppetdb/*
        Hide
        Ryan Senior added a comment -

        Kenneth Barber, Matthaus Owens and I were looking at this today and it's definitely a Fedora specific issue. I'll be sending something out to the Puppet users mailing list, but the short of it is the PuppetDB 1.6.0 packages on Fedora are broken. Specifically the puppetdb.jar that is included in the RPM. Grabbing a puppetdb.jar from the tarball (or another distro) and replacing the one included with the Fedora RPM fixes the issue. Probably the easiest thing to do now is just use 1.5.2. The 1.6.0 packages for Fedora are going to be removed from the repositories soon. We're going to start working on a 1.6.1 release tomorrow that will have the packaging fix.

        Show
        Ryan Senior added a comment - Kenneth Barber , Matthaus Owens and I were looking at this today and it's definitely a Fedora specific issue. I'll be sending something out to the Puppet users mailing list, but the short of it is the PuppetDB 1.6.0 packages on Fedora are broken. Specifically the puppetdb.jar that is included in the RPM. Grabbing a puppetdb.jar from the tarball (or another distro) and replacing the one included with the Fedora RPM fixes the issue. Probably the easiest thing to do now is just use 1.5.2. The 1.6.0 packages for Fedora are going to be removed from the repositories soon. We're going to start working on a 1.6.1 release tomorrow that will have the packaging fix.
        Hide
        Ryan Senior added a comment -

        The fix for the packaging problem is here: https://github.com/puppetlabs/puppetdb/pull/827

        Show
        Ryan Senior added a comment - The fix for the packaging problem is here: https://github.com/puppetlabs/puppetdb/pull/827
        Show
        Kenneth Barber added a comment - Merged here: https://github.com/puppetlabs/puppetdb/commit/be0bf6fcaec90d12fe70f064a3324591524fcaaf
        Hide
        Jason A. Smith added a comment -

        Just a note, this is not only a Fedora issue. I took the 1.6.0 src rpm, rebuilt it on a RHEL6 host and had the exact same problem. Following the pull request to patch the spec file to disable the jar repack and rebuilding the rpm fixed the problem for me.

        Show
        Jason A. Smith added a comment - Just a note, this is not only a Fedora issue. I took the 1.6.0 src rpm, rebuilt it on a RHEL6 host and had the exact same problem. Following the pull request to patch the spec file to disable the jar repack and rebuilding the rpm fixed the problem for me.
        Hide
        Ryan Senior added a comment -

        Email to the puppet-users list with more info: https://groups.google.com/d/msg/puppet-users/MsKAANvxYuM/jjcqDH2GDr4J

        Show
        Ryan Senior added a comment - Email to the puppet-users list with more info: https://groups.google.com/d/msg/puppet-users/MsKAANvxYuM/jjcqDH2GDr4J

          People

          • Assignee:
            Ryan Senior
            Reporter:
            John Florian
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Agile