Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-3180

`pe-pupperserver` has StackOverflowError; possibly related to forcing reparse of puppet.conf via touch command

    XMLWordPrintable

Details

    • Bug
    • Status: Open
    • Normal
    • Resolution: Unresolved
    • None
    • None
    • None
    • Needs Assessment
    • 47106,47593
    • 2
    • Needs Assessment

    Description

      This customer has reported unplanned `pe-puppetserver` service restarts in different ocassions but in the past there seems to be a correlation between the `pe-puppetserver` service restart and a "pressumed" puppet.conf re-parsing (ZD ticket 47106) => customer has processes that could simulate a touch on the file which seems to be enough to trigger a re-parse of the file

      2022-01-23T02:23:53+0000 gbl20124319 puppet-agent[1521]: Config file /etc/puppetlabs/puppet/puppet.conf changed; triggering re-parse of all config files.

      {{}} 

      2022-01-23T02:23:53.800Z ERROR [clojure-agent-send-off-pool-1] [p.t.internal] shutdown-on-error triggered because of exception!
      java.lang.StackOverflowError: null
      at clojure.core$concat$fn__5493.invoke(core.clj:725)
      at clojure.lang.LazySeq.sval(LazySeq.java:42)
      at clojure.lang.LazySeq.seq(LazySeq.java:51)}}

      However, in this latest instance, the `puppet.conf` file gets re-parsed at a later moment (e.g. 10 secs after approx) as per below.

      {{}}

      2022-03-06T02:34:33+0000 gbl20124319 puppet-agent[3634]: Config file /etc/puppetlabs/puppet/puppet.conf changed; triggering re-parse of all config files.

       

      2022-03-06T02:34:23.725Z ERROR [clojure-agent-send-off-pool-0] [p.t.internal] shutdown-on-error triggered because of exception!
      java.lang.StackOverflowError: null
      at clojure.core$concat$fn__5493.invoke(core.clj:725)
      at clojure.lang.LazySeq.sval(LazySeq.java:42)
      at clojure.lang.LazySeq.seq(LazySeq.java:51)
      at clojure.lang.RT.seq(RT.java:535)
      at clojure.core$seq__5402.invokeStatic(core.clj:137)
      at clojure.core$concat$fn__5493.invoke(core.clj:725)
      at clojure.lang.LazySeq.sval(LazySeq.java:42)
      at clojure.lang.LazySeq.seq(LazySeq.java:51)
      at clojure.lang.RT.seq(RT.java:535)
      at clojure.core$seq__5402.invokeStatic(core.clj:137)
      at clojure.core$concat$fn__5493.invoke(core.clj:725)
      at clojure.lang.LazySeq.sval(LazySeq.java:42)
      at clojure.lang.LazySeq.seq(LazySeq.java:51)
      at clojure.lang.RT.seq(RT.java:535)
      at clojure.core$seq__5402.invokeStatic(core.clj:137)
      at clojure.core$concat$fn__5493.invoke(core.clj:725)
      at clojure.lang.LazySeq.sval(LazySeq.java:42)
      at clojure.lang.LazySeq.seq(LazySeq.java:51)
      at clojure.lang.RT.seq(RT.java:535)

      The above cycle of messages below get repeated and repeated as above

      at clojure.core$seq__5402.invokeStatic(core.clj:137)
      at clojure.core$concat$fn__5493.invoke(core.clj:725)
      at clojure.lang.LazySeq.sval(LazySeq.java:42)
      at clojure.lang.LazySeq.seq(LazySeq.java:51)
      at clojure.lang.RT.seq(RT.java:535)

      until interrupted by the below without any additional data

       

      2022-03-06T02:34:23.740Z INFO [main] [p.t.internal] Beginning shutdown sequence
      2022-03-06T02:34:23.757Z INFO [async-dispatch-6] [p.c.services] Shutting down code-manager...
      2022-03-06T02:34:23.758Z INFO [async-dispatch-6] [p.c.shell-workers] Attempting to shut down deploy-pool workers...
      2022-03-06T02:34:23.759Z INFO [async-dispatch-6] [p.c.shell-workers] deploy-pool workers sucessfully shut down.
      2022-03-06T02:34:23.759Z INFO [async-dispatch-6] [p.c.services] code-manager shut down.
      

       
      The previous `clojure-agent-send-off-pool-0` ref to the error is as per below:

       

      2022-03-06T02:34:19.993Z INFO [clojure-agent-send-off-pool-0] [p.e.s.f.file-sync-storage-core] Automatically committing due to changes in staging-dir '/etc/puppetlabs/puppet/ssl/ca'
      

       
      Is there any additional info that can be extracted from the above `StackOverflowError`/ situation? or could we still consider the last `re-parsing` / service restart as part of the same situation even though, in the last ocassion, the re-parsing gets logged 10 secs after?

      Attachments

        Activity

          People

            Unassigned Unassigned
            jordi.garcia Jordi Garcia
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:

              Zendesk Support