+++ This bug was initially created as a clone of Bug #787322 +++ Description of problem: CLI can not support non-interactive mode even when a script file or command is provided on the command-line. For example, if system attempts to execute a Remote CLI script as another user or attempts to execute a script as a forked or background process, the CLI script is not executed and the Java process hangs. This is due to no stdin console. Even when non-interactive options are passed to the CLI, it still insists on an input device (terminal) being attached to the executing process. Specifically, this is caused by the incorrect initialization of the ClientMain class. During initialization, command-line parameters are parsed and a decision is made to use interaction or non-interactive mode, however, regardless of the command-line arguments and decision, the initializer of ClientMain still sets up the interactive components of jline. Specifically, jline.ConsoleReader having a requirement to read from FileDescriptor.in which is not attached to an actual tty/stty when the JVM is executed as a service (su someuser -c '...') or in the background (java ... .ClientMain &). Version-Release number of selected component (if applicable): 4.2 How reproducible: Always Steps to Reproduce: 1. Execute CLI using -f argument with anything in it: ./rhq-cli.sh -u rhqadmin -p rhqadmin -s localhost -t 7080 -f does/not/matter & Actual results: JVM hangs and background process is 'stopped' Expected results: JVM should exit with error indicating file could not be found --- Additional comment from loleary on 2012-02-03 19:11:06 EST --- Thread dump from running process reveals the hung stack: "main" prio=10 tid=0x00007f7354008800 nid=0x7270 runnable [0x00007f73591f3000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:236) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) - locked <0x00000000fe0a3968> (a java.io.BufferedInputStream) at jline.UnixTerminal.exec(UnixTerminal.java:303) at jline.UnixTerminal.exec(UnixTerminal.java:282) at jline.UnixTerminal.stty(UnixTerminal.java:273) at jline.UnixTerminal.initializeTerminal(UnixTerminal.java:89) at jline.Terminal.setupTerminal(Terminal.java:75) - locked <0x00000000ee250af8> (a java.lang.Class for jline.Terminal) at jline.Terminal.getTerminal(Terminal.java:26) at jline.ConsoleReader.<init>(ConsoleReader.java:191) at jline.ConsoleReader.<init>(ConsoleReader.java:186) at jline.ConsoleReader.<init>(ConsoleReader.java:174) at org.rhq.enterprise.client.ClientMain.<init>(ClientMain.java:149) at org.rhq.enterprise.client.ClientMain.main(ClientMain.java:103) --- Additional comment from ccrouch on 2012-02-15 08:07:37 EST --- Lukas, can you investigate this.
master: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=11d405fe3de2c55d8d525d5fc736825e0dc8a67c Author: Lukas Krejci <lkrejci> Date: Wed Feb 15 18:16:36 2012 +0100 [BZ 790859] - Do not expect standard input when the CLI runs in non-interactive mode. * restore the printing out of the CLI version on startup * specifying only the "-v" option will yet again just print the version and exit * specifying an invalid port will cause the CLI to fail startup
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.