running my rhq agent as root, I'm able to inventory the apache instance. However, I don't think this is the ideal solution.

This is due to Sigar not being able to discover process details for processes owned by a different user. I think we should ask Hyperic to fix this. If I can see the process info for other users' processes running ps from the command line, I should be able to see it via Sigar too. Even SIGHT provided this...

After starting apache, I'm able to see that it is running using the ps command as jsant:

[jsant@localhost ~]$ sudo /usr/sbin/apachectl start
[jsant@localhost ~]$ ps -ef | grep apache
apache 6836 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6837 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6838 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6839 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6840 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6841 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6842 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
apache 6843 6834 0 10:10 ? 00:00:00 /usr/sbin/httpd -k start
jsant 6893 2457 0 10:12 pts/5 00:00:00 grep apache

as a workaround, I'm able to manually discovery the apache instance

I also don't get Apache autodiscovered on Ubuntu. Some more detail...

From my agent logs:

2008-04-25 10:29:22,458 INFO [InventoryManager.discovery-1] (rhq.core.pc.inventory.AutoDiscoveryExecutor)- Process scan auto-detected new server resource: scan=[ProcessScan: query=[process|basename|match=apache2,process|basename|nomatch|parent=apache2], name=[Apache2OnUnix]], discovered-process=[process: pid=[5578], name=[apache2], ppid=[1]]
2008-04-25 10:29:22,546 ERROR [InventoryManager.discovery-1] (org.rhq.plugins.apache.ApacheServerDiscoveryComponent)- '?' is not a valid Apache executable (java.io.IOException: ? does not exist.).

The error log comes from:

            String executablePath = process.getProcessInfo().getName();
            ApacheBinaryInfo binaryInfo;
            try {
                binaryInfo = ApacheBinaryInfo.getInfo(executablePath, discoveryContext.getSystemInformation());
            } catch (Exception e) {
                log.error("'" + executablePath + "' is not a valid Apache executable (" + e + ").");
                continue;
            }

Interesting that the log message about the process lists name twice "Apache2OnUnix" and "apache2", but when it's retrieved from the process info, it comes back as ?.

FYI:

11:34:52 -> ps -ef | grep apache
www-data 4342 5578 0 Apr22 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 4343 5578 0 Apr22 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 4344 5578 0 Apr22 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 4345 5578 0 Apr22 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 4346 5578 0 Apr22 ? 00:00:00 /usr/sbin/apache2 -k start
root 5578 1 0 Apr21 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 21751 5578 0 Apr23 ? 00:00:00 /usr/sbin/apache2 -k start

In a nutshell, Sigar.getProxExe(), Sigar.getModules(), Sigar.getProcEnv(), and possibly some other proc functions, will throw a security exception if the process is *not* owned by the same user the SIGAR process (the JON Agent, in this case) is running as. However, Sigar.getProcArgs() still works, and the executable path can potentially be derived from the args (i.e. argv[0]). This is actually what Hyperic did in the JON 1.x Apache plugin - here's the code they used (from net.hyperic.hq.product.ServerDetector):

    /**
     * Attempt to find the absolute name of the process executable.
     * If the name cannot be determined, <code>null</code> is returned.
     * @param pid Process identifier
     * @param name Binary base name to match against
     * @return The process executable name.
     */
    protected static String getProcExe(long pid, String name) {
        try {
            String exe = getSigar().getProcExe(pid).getName();
            //possible to be "" on solaris
            if (exe.length() > 0) {
                return exe;
            } //else fallthru
        } catch (SigarException e) {
            //likely permission denied
        }

        String argv0 = null;
        String[] args = getProcArgs(pid);
        if (args.length != 0) {
            //might not be absolute path.
            argv0 = args[0];
            File bin = new File(argv0);
            if (bin.exists() && bin.isAbsolute()) {
                return argv0;
            }
        }

        List modules = getProcModules(pid);
        if (modules.size() > 0) {
            if (name == null) {
                return (String)modules.get(0);
            }
            name = File.separator + name;
            for (int i=0; i<modules.size(); i++) {
                String bin = (String)modules.get(i);
                if (bin.endsWith(name)) {
                    return bin;
                }
            }
        }

        return argv0;
    }


Note, this algorithm will fail to find the absolute exe path, if the program was started using a relative path.

We never incorporated this logic into JON 2.0. Here's the logic we use (in org.rhq.core.system.ProcessInfo):

            private static final String UNKNOWN = "?";
            ...
            ProcExe procExe = null;
            try {
                procExe = sigar.getProcExe(pid);
            } catch (Exception e) {
                handleSigarCallException(e);
            }
            ...
            this.name = (procExe != null) ? procExe.getName() : UNKNOWN;

So we'll always fail to find the executable path for processes running as a different user than the JON Agent. If we incorporate the algorithm from JON 1.x, we'll at least be able to figure it out for processes that were started using an absolute path for the exe name.

Fixed - r1040. We now use the same logic as JON 1.x to determine the Apache executable path. The only time we'll fail now is if the Apache process is running as a different user *and* it was started specifying a relative path to the executable.

Can now discover apache running as different user