openjdk team mailing list archive

[Erik Forsberg <forsberg@xxxxxxx>]

I see this as well, although on oracle JVM 7u75, but that's no surprise
given that it originates from the same codebase as openjdk-7.

Doing a bit of strace on the jps program shows some interesting data:

# strace -f jps -v 2>&1|grep /tmp/hsperfdata
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NOFOLLOW) = 3
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
[pid  9064] mkdir("/tmp/hsperfdata_root", 0755) = -1 EEXIST (File exists)
[pid  9064] lstat("/tmp/hsperfdata_root", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NOFOLLOW) = 3
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
[pid  9064] stat("/tmp/hsperfdata_root", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid  9064] stat("/tmp/hsperfdata_root/9063", {st_mode=S_IFREG|0600, st_size=32768, ...}) = 0
[pid  9064] access("/tmp/hsperfdata_root/9063", R_OK) = 0
[pid  9064] stat("/tmp/hsperfdata_cassandra", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
[pid  9064] open("/tmp/hsperfdata_cassandra", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid  9064] stat("/tmp/hsperfdata_cassandra/13926", {st_mode=S_IFREG|0600, st_size=32768, ...}) = 0
[pid  9064] access("/tmp/hsperfdata_cassandra/13926", R_OK) = 0
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NOFOLLOW) = 6
[pid  9064] open("/tmp/hsperfdata_root", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 7
[pid  9064] lstat("/tmp/hsperfdata_root", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid  9064] open("/tmp/hsperfdata_cassandra", O_RDONLY|O_NOFOLLOW <unfinished ...>
[pid  9064] open("/tmp/hsperfdata_13926", O_RDONLY <unfinished ...>
[pid  9064] unlink("/tmp/hsperfdata_root/9063") = 0

I have two processes here:

9063, the jps program, running as root. Shows up as it should.
13926, a cassandra server, running as cassandra user. Does not show up as it should.

Note how jps is first finding the hsperfdata file in
/tmp/hsperfdata_cassandra, then tries to open /tmp/hsperfdata_13926,
which doesn't exist.

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-7 in Ubuntu.
https://bugs.launchpad.net/bugs/1417962

Title:
  6b34 regression: jps as root does not show classname anymore but
  instead 'process information unavailable' for processes running as
  non-root user

Status in openjdk-6 package in Ubuntu:
  Confirmed
Status in openjdk-7 package in Ubuntu:
  Confirmed

Bug description:
  I noticed the following behavior change in the jps command line tool when updating from
  6b33-1.13.5-1ubuntu0.12.04 -> 6b34-1.13.6-1ubuntu0.12.04.1 on a ubuntu 12.04 64bit system.

  Staring point is a java process for apache tomcat running as non-root
  user (username openbravo in below example) with pid 1462.

  In 6b33 when running jps -l as root it did correctly identify the classname of the running processes as shown here:
  luna686:~# jps -l
  1462 org.apache.catalina.startup.Bootstrap
  11610 sun.tools.jps.Jps

  However after updating the same jps call as root-user does now show:
  luna686:~# jps -l
  12056 sun.tools.jps.Jps
  1462 -- process information unavailable

  Which break some custom monitoring of us trying to find tomcat process
  via its classname.

  Note: Problem only occours when running jps as root user and process
  in question is running non-root. When running jps as same user as the
  tomcat process is running with then both 6b33 + 6b34 work as expected

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1417962/+subscriptions