This issue was reported by Alexey Kamenchuk on rhq-users.org. He explains that he is not able to auto-discovery his postgres resources, and that he has well over 100 to find and import. His workaround is to navigate to each platform and perform a "manual add" on each, adding the connection property details for each, but this is of course rather tedious. His agent log shows the following: 2010-06-21 12:09:09,271 INFO [InventoryManager.discovery-1] (rhq.core.pc.inventory.AutoDiscoveryExecutor)- Process scan auto-detected new server resource: scan=[ProcessScan: query=[process|basename|match=^(postgres|postmaster)$,process|basename|nomatch|parent=^(postgres|postmaster)$], name=[unix]], discovered-process=[process: pid=[20646], name=[/data/pgsql/bin/postgres], ppid=[1]] 2010-06-21 12:09:09,292 INFO [ResourceDiscoveryComponent.invoker.daemon-2] (org.rhq.plugins.postgres.PostgresDiscoveryComponent)- Discovered a postgres process: ProcessScanResult: scan=[ ProcessScan: query=[process|basename|match=^(postgres|postmaster)$,process|basename|nomatch|parent=^(postgres|postmaster)$], name=[unix]], info=[process: pid=[20646], name=[/data/pgsql/bi n/postgres], ppid=[1]] 2010-06-21 12:09:09,344 INFO [ResourceDiscoveryComponent.invoker.daemon-2] (org.rhq.plugins.postgres.PostgresDiscoveryComponent)- Failed to connect to the database org.postgresql.util.PSQLException: FATAL: password authentication failed for user "postgres" at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:291) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3.Jdbc3Connection.<init>(Jdbc3Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:185) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.buildConnection(PostgresDiscoveryComponent.java:195) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.getConnection(PostgresDiscoveryComponent.java:259) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.createResourceDetails(PostgresDiscoveryComponent.java:150) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.discoverResources(PostgresDiscoveryComponent.java:123) at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:266) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) 2010-06-21 12:09:09,345 WARN [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Failure during discovery for [Postgres Server] Resources - failed after 56 ms. java.lang.Exception: Discovery component invocation failed. at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:270) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at org.rhq.plugins.postgres.PostgresDiscoveryComponent.getDatabaseNames(PostgresDiscoveryComponent.java:277) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.getServerResourceName(PostgresDiscoveryComponent.java:295) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.createResourceDetails(PostgresDiscoveryComponent.java:151) at org.rhq.plugins.postgres.PostgresDiscoveryComponent.discoverResources(PostgresDiscoveryComponent.java:123) at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:266) ... 5 more Looking at SCM history, it shows me the createResourceDetails method of the PostgresDiscoveryComponent was altered to obtain a more accurate/descriptive server resource name. However, this new piece of code requires a live connection to the PG instance, which won't work if the user has changes the default PWD for 'postgres' user. So the connection to the PG server fails, returns a null Connection object, which then causes NPE later in the workflow. This NPE is then uncaught and bubbles out of createResourceDetails, which rolls back the discovery of that PG server. Effectively the only way to add a PG server with non-default credential now is to go to the platform and manually add it. I think we need a reasonable fallback mechanism to allow discovery no matter what.
Commit 0c86996 fixes this. The discovery should succeed even if the connection to the server cannot be obtained (for whatever reason). I also made a couple of other enhancements: A correct "listen address" is autodiscovered. Even if the postgres server was configured to listen only on some of the IPs the machine resolves to, "127.0.0.1" would always be used as the host address in autodiscovery. This is no longer true and the correct IP address (or hostname) is read out from postgresql.conf (if the agent has enough privileges to read that file). Also, the version of the server is detected even if the connection to the server is not possible.
Pushing this old issue to ON_QA, it should be tested after higher priority items
Verified on jon-2.4.0.GA_QA build#73 (10868:d9790b0) If the connection to the server cannot be obtained, postgres is auto-discovered. The hostname from postgresql.conf is auto discovered and the version of the server is detected.
Mass-closure of verified bugs against JON.