Bug 990227 - jboss-cli.sh freeze when run unattended - e.g. from scripts
jboss-cli.sh freeze when run unattended - e.g. from scripts
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CLI (Show other bugs)
6.1.1
Unspecified Unspecified
unspecified Severity unspecified
: ER1
: EAP 6.2.0
Assigned To: Alexey Loubyansky
Aleksandar Kostadinov
Russell Dickenson
: Regression
: 996164 (view as bug list)
Depends On:
Blocks: 1002997
  Show dependency treegraph
 
Reported: 2013-07-30 11:41 EDT by Aleksandar Kostadinov
Modified: 2013-12-15 11:16 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In previous versions of Red Hat JBoss Enterprise Application Platform, if the server was automated with a script that closed, or set to 'null', STDIN, the server would exit upon reaching a point where user input was required. In the most recent release of the product, however, this was not the case and the server would hang in that scenario. This release of the product includes an updated verions of Aesh (Another Extendable Shell) that reinstates the original behavior. Servers started with an automated script exit as expected, and no longer hang when requiring user input.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-15 11:16:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
thread dump of the hung process (16.02 KB, text/plain)
2013-08-07 13:48 EDT, Aleksandar Kostadinov
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker AESH-106 Major Resolved read() hangs when stdin is a redirection from /dev/null 2017-11-30 03:38 EST

  None (edit)
Description Aleksandar Kostadinov 2013-07-30 11:41:34 EDT
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.
Comment 1 Aleksandar Kostadinov 2013-08-07 13:48:41 EDT
Created attachment 784035 [details]
thread dump of the hung process

attaching a thread dump of the hung process
Comment 2 JBoss JIRA Server 2013-08-07 14:48:54 EDT
Aleksandar Kostadinov <akostadinov@jboss.org> 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.
Comment 3 Ståle W. Pedersen 2013-08-07 17:29:46 EDT
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.
Comment 4 Aleksandar Kostadinov 2013-08-08 00:35:27 EDT
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.
Comment 5 Ståle W. Pedersen 2013-08-08 02:54:56 EDT
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...
Comment 6 Ståle W. Pedersen 2013-08-08 03:08:44 EDT
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....
Comment 7 Ståle W. Pedersen 2013-08-08 04:36:48 EDT
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
Comment 8 Aleksandar Kostadinov 2013-08-08 07:06:48 EDT
I took it with wildfly master branch. But you could do a kill -3 on the process and it will output stack on stdout.
Comment 9 Ståle W. Pedersen 2013-08-08 07:14:00 EDT
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.
Comment 10 Osamu Nagano 2013-08-20 01:13:54 EDT
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
Comment 11 Ståle W. Pedersen 2013-08-20 03:59:17 EDT
this should be fixed in wildfly8 upstream i think test it there. not pushed into eap6 yet afaik.
Comment 12 Aleksandar Kostadinov 2013-08-20 04:23:48 EDT
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
Comment 13 Osamu Nagano 2013-08-21 00:52:28 EDT
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
Comment 14 Scott Mumford 2013-08-30 01:36:22 EDT
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.
Comment 16 baranowb 2013-09-04 08:59:49 EDT
*** Bug 996164 has been marked as a duplicate of this bug. ***
Comment 19 Petr Kremensky 2013-09-18 08:54:22 EDT
Verified on EAP 6.2.0.ER2
Comment 20 JBoss JIRA Server 2013-09-22 15:45:11 EDT
Ståle Pedersen <stale.pedersen@jboss.org> updated the status of jira AESH-106 to Resolved
Comment 24 Aleksandar Kostadinov 2013-10-09 11:18:47 EDT
FYI things work for me on RHEL6, RPM distro. FYI I still see another bug 1017290
Comment 25 Russell Dickenson 2013-10-09 21:45:47 EDT
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.
Comment 26 Petr Kremensky 2013-10-10 01:44:59 EDT
Hi Russell,
you are right. This issue should be documented for 6.1.1 as "Known Issue".

Note You need to log in before you can comment on or make changes to this bug.