So a connection reset is pretty fatal, and it makes me feel like your PuppetDB instance isn't even working today. We should probably start by determining your PuppetDB instance is working at all.
Is this a production instance? Is anything talking to it correctly at all? What happens when you restart it for example, any change? You should be actively seeing commands being submitted to that PuppetDB in its puppetdb.log as so: 2014-07-13 19:00:21,775 INFO [c.p.p.command] [a42497d2-7b96-49ae-bcaf-5c9b2020cac2] [replace facts] puppetdb1.vm 2014-07-13 19:00:21,961 INFO [c.p.p.command] [adadbf63-c5b5-4e81-bdcf-59d187d53451] [replace catalog] puppetdb1.vm 2014-07-13 19:00:22,207 INFO [c.p.p.command] [7305367c-1c9d-4565-b45d-9a61b6ef88ee] [store report] puppet v3.6.2 - puppetdb1.vm Whats more, curl's _should_ be working. Can you provide the results (in text please, not a screenshot) of running the following: root@puppetdb1:~# netstat -anp | grep java tcp6 0 0 :::8080 :::* LISTEN 10823/java tcp6 0 0 :::8081 :::* LISTEN 10823/java tcp6 0 0 192.168.182.132:53125 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53126 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53124 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53123 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53118 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53121 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53130 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53120 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53117 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53127 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53129 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53119 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53128 192.168.182.196:5432 ESTABLISHED 10823/java tcp6 0 0 192.168.182.132:53122 192.168.182.196:5432 ESTABLISHED 10823/java unix 2 [ ] STREAM CONNECTED 15655 10823/java unix 2 [ ] STREAM CONNECTED 17083 10823/java root@puppetdb1:~# netstat -anp | grep 8080 tcp6 0 0 :::8080 :::* LISTEN 10823/java Then taking the process id (10823): root@puppetdb1:~# ps auxw | grep 10823 puppetdb 10823 6.7 10.5 747000 217344 ? Ssl 19:04 0:22 /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Xmx192m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/puppetdb/puppetdb-oom.hprof -Djava.security.egd=file:/dev/urandom -cp /usr/share/puppetdb/puppetdb.jar clojure.main -m com.puppetlabs.puppetdb.core services -c /etc/puppetdb/conf.d --debug Also ... can you tell me exactly what version of PuppetDB you are running? Normally you can query this with something like: root@puppetdb1:~# curl 'http://localhost:8080/v3/version' { "version" : "2.1.0" } But since your curl requests are failing, perhaps we can gather it from the logs: root@puppetdb1:~# grep 'PuppetDB version' /var/log/puppetdb/puppetdb.log 2014-07-13 19:00:03,333 INFO [c.p.p.c.services] PuppetDB version 2.1.0 Please perform the above, and show full working as I've done, that helps me understand the full results. ken. On Wed, Jul 16, 2014 at 3:21 PM, Alex Wacker <[email protected]> wrote: > Also not seeing anything related to the failure to connect in the logs > > > On Wednesday, July 16, 2014 9:51:48 AM UTC-4, Ken Barber wrote: >> >> > I am able to get a response out of the standard puppet API (not >> > puppetdb) >> > via curl however puppetdb only gives such: >> > >> > While something such as the puppet master API (while not exactly the >> > puppetdb api) will at least respond to me >> >> I can't help but notice you are connecting from a windows box to >> localhost (127.0.0.1) in your tests. Is PuppetDB running on a Windows >> box or something? Because this is not a supported nor tested >> configuration sorry, and I wouldn't be surprised if its very broken. >> PuppetDB only works on Linux and some Unix OS's generally: >> http://docs.puppetlabs.com/puppetdb/2.1/#system-requirements. >> >> If its not running on Windows, you'll need to check your puppetdb.log >> (usually in /var/log/puppetdb) when that connection attempt is made. >> Connection reset is generally caused by an application fault of some >> kind and it should be followed up with an exception in the logs. >> >> ken. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/08ff0fb4-b1b2-4b52-8b61-e2696cbebac2%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAE4bNTn_8TYE7eZY81%3DSA-PZkhcxM0AoxhK3Bs8PBGw8zTKMxQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
