[java] versus java -Xms512M -Xmx... Linux ps problem

[lazyrunner50]

I'm having a very strange problem with a package I just released. If I release the package under one directory, it shows [java] when I do ps, and if I release it in another directory it shows the regular process string (java -Xms512M -Xmx1048M...). At my company, we have our environment set up such that we can release different versions of the package simply by changing some softlinks. Anyway here are the 4 senarios:

1. Package released under /apps/<packagename>/<new version #>
ps -fu <username>
[java]
2. Package released under ~/apps/<packgename>/<new version #>
ps -fu <username>
java -Xms512M -Xmx1048M...
3. Old Package released under /apps/<packagename>/<old version #>
ps -fu <username>
java -Xms512M -Xmx1048M...
4. Old Package released under ~/apps/<packagename>/<old version #>
ps -fu <username>
java -Xms512M -Xmx1048M...

I don't think there is anything wrong with the package because when I deployed it from /apps/... to ~/apps/... , I did cp -r (so all the permissions stayed the same). Additionally, I don't think there's anything wrong with the /apps directory because a previous version of the package works just fine in the same directory. The process itself seems to run just fine, however, we require the full process string because the shutdown script greps on the ps to shut it down properly.

I looked into the /proc/<PID> directory for some help, unfortunately I couldn't find anything useful. The cmdline and environ files are exactly the same between the version released under local (~/apps), and under root (/apps)

Before someone suggests to leave the package local since that works, it is against company policy to have packages in local (the only reason we do it is for testing purposes).

 

[DrD123]

Hi lazyrunner50,

Are the scripts to startup the processes containing JAVA the same? Is the one for "1" different at all? Could you check the scripts also?

The -Xms512M -Xmx1048M are settings (minimum and maximum heap size) that are initially manually added in so it can allocate that amount of memory to the JAVA process. So the install location wouldn't pass those to JAVA.

I'd have to guess someone has the memory settings in there somewhere: scenarios 2 - 4, or they don't in there in scenario 1.




Good Luck
DrD

 

[lazyrunner50]

Yep, the scripts are exactly the same (in all 1/2 and in 3/4 the packages are the same, only the location is changed).

The section of the ps string I quoted is just the beginning of the process string. It continues on to give the other options. Only reason I stopped there is because it is quite long. Basically I just wanted to show that in one instance it shows the whole string whereas in the other instance it just shows [java]

When I look at the cmdline file under /proc/<PID>, all the options look the same

 

[stefanwagner]

can you add an

echo $$

to the scripts?
This will print the ip, so you will be able to identify them.

don't visit my homepage:

http://home.arcor.de/hirnstrom/bewerbung

 

[Annihilannic]

This is normal behaviour when ps is unable to determine the command line supplied to a programme. Is this actually causing any problems from apart from the ps listing? The only reason I can think of it being problematic is if you have some kind of monitoring scripts that depend on the ps output matching a certain string...?

Annihilannic.

 

[lazyrunner50]

Stefan, it's not so much that I want to identify which script, I'm simply trying to get the entire process string to print out when I run the ps command.

Annihilannic, not sure what you mean by "is unable to determine the command line supplied". I looked under /proc/<pid>, and the cmdline file was exactly the same as the time I started the program under the home directory (with the exception of the ~ path appended to some of the directories mentioned). As for it being problematic, not really (the process runs just fine), however we have many monitoring programs, some of which would look for the process string.

 

[Annihilannic]

I'm not say I know why it is unable to determine the command line, I'm as puzzled about that as you are. However if, for whatever reason, ps is unable to obtain that information, [processname] is the output it will display.

Annihilannic.

 

[elgrandeperro]

First the obvious:

Did you run the ps as the same user?
Can you run the ps with the full path /bin/ps (to remove the chance of an alias or path problem?

Supressing the environment sounds like a security thing or as stated above permissions thing. If the test was done the same, I would next strace both ps commands and compare the output to see the differences.

eugene