unlike previous versions of EAP, jboss-cli.sh from 6.1.1 ER3 can freeze a script it is part of, if server requires authentication but no user/pass is provided on command line. In previous versions of EAP, if script is run with "< /dev/null" it fails in case server requires auth but user/pass is not supplied on command line. In 6.1.1 ER3 the script outputs a prompt for user to input a username and a password no matter if such input can be received or not. This can never happen when stdin is /dev/null. Moreover one would run the command in such a way only in scripts so such script would hang forever. The command is sometimes even hard to kill. One needs to use "kill -9" to be sure. This can make automation scripts unreliable and hard to debug while these would have failed in a timely manner with previous versions of EAP. It is also not possible to automate testing of CLI because of this same problem. It is reasonable to expect a program to exit with an error if it requires input but stdin is closed or empty. This can be very confusing to users that are not savvy writing scripts.
Created attachment 784035 [details] thread dump of the hung process attaching a thread dump of the hung process
Aleksandar Kostadinov <akostadinov> made a comment on jira AESH-106 btw it does not matter if program is started from a terminal or not, it just hangs even if I start it with `nohup`. It would have made sense if running from terminal is detected and user input received even if stdin is /dev/null. But simply hanging with no way for user to terminate the process neither a way to input data can't be a desirable behavior for anybody.
the only way im able to produce this atm is if i do: "./jboss-cli connect < /dev/null" which doesnt make much sense afaik. note that this is when you are prompted for username/passwd. if i try a script like: $ cat rep.sh #!/bin/bash ./jboss-cli.sh -c <<EOF admin admin!234 batch /system-property=bar2:add(value=foo) run-batch exit EOF and run it like this: ./rep.sh < /dev/null everything works ok. if i change the script to and invalid username/password and run the script again i get an exception when trying to log in and then the program exits normally. so if you could please show me a script that behaves like you mentioned above that would be very nice.
I'm talking about running a script like: > /usr/share/jbossas/bin/jboss-cli.sh --connect --command="$CLI_COMMAND" < /dev/null basically all unix command line tools expecting user input fail fast if stdin is null or closed. Or some of them detect a terminal and read user unput from it. My personal use case is to test cli behavior and that it properly requires authentication when run with unauthorized OS user but allows connection without password for users with the correct filesystem permissions. We already had a bug with that. If you find it necessary I can dig out the security advisory. But at the moment, the test suite that worked with 6.1.0 just hangs when the test for the bad user executes. With 6.1.0 jboss-cli just exited with an error message in this case. Which is the desired behavior. I looked through aesh commits but didn't find anything obvious as to what change caused the behavior difference with older versions.
thanks, i can reproduce it locally as well. afaik there shouldnt be any commits that would change this in aesh if this worked for eap6.1. ill try to look at the jboss-cli source as well...
after testing with: "./jboss-cli.sh < /dev/null" which exits normally with a ctrl-c im starting to think that there is something thats locked in jboss-cli when connection failes. - this is just a thought though....
when looking at your stack dump i cant seem to fit the code lines with what im having locally. could you point me to the correct branch i should look at? atm im looking at the EAP_6.1.1.ER4 branch and it doesnt fit with the stack dump. eg: CommandContextImpl.java:1315
I took it with wildfly master branch. But you could do a kill -3 on the process and it will output stack on stdout.
ok, that makes more sense. it was just that your stack dump didnt match mine. im thinking that this is caused by the connection code in jboss-cli and not aesh, but im not 100%. the cli in wildfly master will hopefully change a bit when its updated to the latest aesh version. i have a working branch locally, but it still need some work before it can be merged.
Found an easier way to reproduce. The following command is executed properly in EAP 6.0.1 (jline) but it keeps reading stdin in EAP 6.1.0 (aesh). echo 'ls' | $JBOSS_HOME/bin/jboss-cli.sh --controller=localhost:9999 -c
this should be fixed in wildfly8 upstream i think test it there. not pushed into eap6 yet afaik.
Very nice! I just tried wildfly master branch and it is working fine. Both with stdin being /dev/null and having stdin closed. FYI to have stdin closed you can use the following command: ( exec <&-; /tmp/wildfly/bin/jboss-cli.sh -c ls ; ) I hope it's not too late to go in EAP 6.1.1
It can be fixed by backporting WFLY-1865 [1]. Sent pull requests to the EAP repository. 6.x: https://github.com/jbossas/jboss-eap/pull/302 6.1.x: https://github.com/jbossas/jboss-eap/pull/303 [1] https://github.com/wildfly/wildfly/commit/c00d46915af533ebe38d1f6ca83b30b8c3f7714c
Added draft release note. Setting NEEDINFO flag to request technical verification from assignee. Please reset the 'requires_doc_text' flag to '?' if the draft is inaccurate and leave a comment with corrections.
*** Bug 996164 has been marked as a duplicate of this bug. ***
Verified on EAP 6.2.0.ER2
Ståle Pedersen <stale.pedersen> updated the status of jira AESH-106 to Resolved
FYI things work for me on RHEL6, RPM distro. FYI I still see another bug 1017290
This BZ ticket was listed in the EAP 6.1.1 Release Notes as a "Bug Fix" whereas I believe it should have been listed as a "Known Issue". Can someone please confirm either way, as the Release Notes document is in translation and the status of this issue should be resolved before translation proceeds.
Hi Russell, you are right. This issue should be documented for 6.1.1 as "Known Issue".