Bugzilla – Full Text Bug Listing
| Summary: | Path to PBS Tools | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Roland Schulz <roland> |
| Component: | RM.PBS | Assignee: | Project Inbox <ptp-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arossi, g.watson |
| Version: | 4.0.3 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Roland Schulz
By setting the launch command to sh -lc "java ... instead of java ... it works on all machines I could find. The "sh -lc" gurantees that all login-shell environment variables are read in. Is there any disadvantage of this approach to add sh to the launch command? How does shutdown take place on the Java proxy? Is it issued a command to exit or does the client do kill -9 / kill -15 or something similar? If the latter, there may occasionally be issues with killing the shell and the child process not dying. To be safe one would want to kill the shell process child explicitly as well, I would think. Maybe this is a non-issue. (In reply to comment #2) > How does shutdown take place on the Java proxy? Is it issued a command to exit > or does the client do kill -9 / kill -15 or something similar? If the latter, > there may occasionally be issues with killing the shell and the child process > not dying. To be safe one would want to kill the shell process child > explicitly as well, I would think. > > Maybe this is a non-issue. No the Java process isn't being killed. (In reply to comment #1) > By setting the launch command to > sh -lc "java ... > instead of > java ... > it works on all machines I could find. The "sh -lc" gurantees that all > login-shell environment variables are read in. > > Is there any disadvantage of this approach to add sh to the launch command? The sort answer is yes. A couple of reasons: 1. Remote tools is already running the command using '/bin/sh -c' so you would actually be running '/bin/sh -c "sh -lc ..."'. I don't think this is very desirable. 2. The -l option starts the shell as if it was a login shell, which executes the system wide and user's profile and logout scripts. This can cause problems if these do something strange. For example, abe checks if your .forward file is more than 6 months old, and if so, prompts the user to verify that it is still ok. This would cause commands run using "sh -lc" to fail, with no indication to the user as to what is going wrong. Basically, running commands using ssh (or any kind of remote shell) is a pain and there is no really neat solution I know about. In general, I've found it's most reliable to run using "sh -c", but then you miss out on user defined paths, modules, softenv, etc. Remember also that the user's shell may not be bash, but could be tcsh, ksh, or something else. If you can think of or find a way to make this work for all cases that would be great, but it would need to be compatible with remote tools also. See KillableExecution.java and ControlChannel.java for some of the convolutions that are needed. (In reply to comment #4) > (In reply to comment #1) > > By setting the launch command to > > sh -lc "java ... > > instead of > > java ... > > it works on all machines I could find. The "sh -lc" gurantees that all > > login-shell environment variables are read in. > > > > Is there any disadvantage of this approach to add sh to the launch command? > > The sort answer is yes. I see. Then I suggest the following alternative: We run "sh -c 'which qstat'" and if that doesn't find it "sh -lc 'which qstat'". We also do this for all of the other PBS tools. If both fail than the user has to provide the paths or we give an error. It could be done both by the proxy or by the UI (using remote exec). Doing it on the UI side would have the advantage that we could allow the user to enter the paths if we can't automatically find them. Doing it on the proxy side is easier to implement. Should we first implement it on the proxy side and later (if manual option is required) do it on the UI side? If you run "sh -lc 'which qstat" you'll still need to be prepared for the command to hang forever, as the user's .profile may contain a read command or something else weird. I would suggest just providing better diagnostics to the user, such as a message describing the problem and how to rectify it. e.g. "The 'qstat' command has been unable to be located on the remote system. Please manually log into the system and type the command 'which qstat'. Then enter the full path to the qstat command in the PBS resource manager configuration page." (You could even make the text 'configuration page' a link to the actual page.) Superseded by new PBS RM. |