You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by to...@quarendon.net on 2019/03/20 08:31:37 UTC
Waiting for a command to be available
I'm wanting to automate some setup of a karaf based product. I want to create a docker image that is pre-configured for internal testing.
In order to do this I need to run some karaf shell commands.
What I was naively hoping to do is do something like:
/opt/karaf/bin/start && /opt/karaf/bin/client -u admin -p admin -f commands.txt && /opt/karaf/bin/stop
or perhaps:
/opt/karaf/bin/karaf < commands.txt
However my problem is that the shell comes up before the commands I need are available to run.
Any suggestions on how to deal with this?
- I can't find any documentation on shell variables that might give me a return code I could check and loop on with a sleep. This would probably work, but feels crude.
- A "does this command exist" command might be useful if I can then loop on its result. I can probably create such a command and put it in a bundle that I specify with a low start order to ensure it's available.
- Crudely sleeping for a long period of time would work (most of the time) but is inefficient.
Fiddle with the start level of the shell bundle so that it comes up last (I'm not even totally sure that would work -- since component activation happens asynchronously I suspect that things from earlier bundles are still happening while later bundles are then being started).
Or is what I'm trying to do just not very sensible? Even if I created REST API endpoints do to it I'd have essentially the same issue, I could just write the logic in an external program of some kind, java, shell, whatever (repeatedly "ping" an endpoint until it doesn't return 404, then I know the endpoints are available). I'm guessing JMX would have essentially the same problem, in that I would have to start karaf then loop until the JMX beans become available.
Note that I found what appears to be some old karaf documentation (https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/scripting.html) that includes a script for waiting for a command to become available. Perfect! However that a) doesn't work and b) would appear be based on standard OSGI gogo shell commands by the looks of it, rather than karaf shell commands, which aren't registered as services.
Thanks.
Re: Waiting for a command to be available
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
So, let me explain:
delay.console will start the shell "regular", without injecting any command
Once console is started, you can use the client.
However, it's up to you to check the status of the command (by scripting).
I guess the following Jira I created would help you:
https://issues.apache.org/jira/browse/KARAF-6111
https://issues.apache.org/jira/browse/KARAF-6110
Basically, assuming console.delay works for you, I guess you would just
need a way to "inject" commands/script when the shell is started right ?
Regards
JB
On 20/03/2019 09:59, tom@quarendon.net wrote:
>> FYI, I fixed an issue in client, now you can inject directly a script.
>
> Do you mean there's a way of using the "karaf" command and running a script?
> With the karaf.delay.console=true setting you can't pipe a script in to the karaf command, as it misinterprets the end of line as "Press Enter to open the shell now...".
> Using "start && client -f commands.txt && stop" a) seems unreliable and b) would seem to need a sleep anyway as otherwise the client tries to connect while karaf is still starting.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> Not sure what issue you have fixed (perhaps you could expand?) but the problem I have still remains.
Note also that the client appears to forget the password set on the command line if it has to retry (JIRA raised):
> client -u admin -p admin -r 30
> Logging in as admin
> retrying (attempt 1) ...
> retrying (attempt 2) ...
> Password:
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> Did you try with 4.2.4 (as I did the fix on the client thread in this
> version) ?
Not sure what issue you have fixed (perhaps you could expand?) but the problem I have still remains.
The problem I have is the number of arguments that are passed from the BAT file to java:
ARGS=%2 %3 %4 %5 %6 %7 %8 %9
or
ARGS=%1 %2 %3 %4 %5 %6 %7 %8 %9
I have 10 arguments (-u <username> -p <password> -d <delay> -r <attempts> -f <commands file>)
Therefore in both cases one or more arguments will be dropped before they get to java. Most confusing.
Re: Waiting for a command to be available
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Did you try with 4.2.4 (as I did the fix on the client thread in this
version) ?
On 20/03/2019 10:08, tom@quarendon.net wrote:
>> Using "start && client -f commands.txt && stop" a) seems unreliable and b) would seem to need a sleep anyway as otherwise the client tries to connect while karaf is still starting.
>
> Note that trying the "-d" and "-r" options on the bin/client along with -f seems to result in either "miss the commands file" or "miss the attempts" depending on which way round you put the options (karaf 4.2.2).
>
> I'll have a read though the source and see if I can find out why.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> Using "start && client -f commands.txt && stop" a) seems unreliable and b) would seem to need a sleep anyway as otherwise the client tries to connect while karaf is still starting.
Note that trying the "-d" and "-r" options on the bin/client along with -f seems to result in either "miss the commands file" or "miss the attempts" depending on which way round you put the options (karaf 4.2.2).
I'll have a read though the source and see if I can find out why.
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> FYI, I fixed an issue in client, now you can inject directly a script.
Do you mean there's a way of using the "karaf" command and running a script?
With the karaf.delay.console=true setting you can't pipe a script in to the karaf command, as it misinterprets the end of line as "Press Enter to open the shell now...".
Using "start && client -f commands.txt && stop" a) seems unreliable and b) would seem to need a sleep anyway as otherwise the client tries to connect while karaf is still starting.
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> No way to use etc/shell.init.script ?
Sorry, not sure I understand how that would help. That's a way I could get shell commands to be run automatically I'm assuming. That's part of my problem. The main problem is establishing whether the commands are available to run.
> FYI, I fixed an issue in client, now you can inject directly a script.
By what means? The client appears to support a -f option that pipes commands in from a file. Is that what you are referring to?
As I say, the main issue I have is waiting for the commands I need to be available, rather than actually how to invoke the commands
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> No way to use etc/shell.init.script ?
I've understood this comment now.
The best method seems to be to use the pattern of:
set EXTRA_JAVA_OPTS=-Dkaraf.shell.init.script=<commands.txt> -Dkaraf.delay.console=true
bin\karaf
(or equivalent)
Then ensure that the <commands.txt> file ends with "shutdown -f".
This seems to work as long as there aren't any errors in the script, if none of the commands return an error. The error handling seems to surround the complete initialisation script execution, so if any exception is thrown nothing further in the script is executed. Starting the script with "shutdown -f 1" seems a sensible precaution to ensure that karaf doesn't hang forever in these circumstances.
Anyway, this seems like a pattern than the
bin\start & bin\client -f <commands.txt> & bin\stop
pattern.
Re: Waiting for a command to be available
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
No way to use etc/shell.init.script ?
FYI, I fixed an issue in client, now you can inject directly a script.
Regards
JB
On 20/03/2019 09:31, tom@quarendon.net wrote:
> I'm wanting to automate some setup of a karaf based product. I want to create a docker image that is pre-configured for internal testing.
>
> In order to do this I need to run some karaf shell commands.
> What I was naively hoping to do is do something like:
>
> /opt/karaf/bin/start && /opt/karaf/bin/client -u admin -p admin -f commands.txt && /opt/karaf/bin/stop
>
> or perhaps:
>
> /opt/karaf/bin/karaf < commands.txt
>
> However my problem is that the shell comes up before the commands I need are available to run.
>
> Any suggestions on how to deal with this?
> - I can't find any documentation on shell variables that might give me a return code I could check and loop on with a sleep. This would probably work, but feels crude.
> - A "does this command exist" command might be useful if I can then loop on its result. I can probably create such a command and put it in a bundle that I specify with a low start order to ensure it's available.
> - Crudely sleeping for a long period of time would work (most of the time) but is inefficient.
> Fiddle with the start level of the shell bundle so that it comes up last (I'm not even totally sure that would work -- since component activation happens asynchronously I suspect that things from earlier bundles are still happening while later bundles are then being started).
>
> Or is what I'm trying to do just not very sensible? Even if I created REST API endpoints do to it I'd have essentially the same issue, I could just write the logic in an external program of some kind, java, shell, whatever (repeatedly "ping" an endpoint until it doesn't return 404, then I know the endpoints are available). I'm guessing JMX would have essentially the same problem, in that I would have to start karaf then loop until the JMX beans become available.
>
> Note that I found what appears to be some old karaf documentation (https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/scripting.html) that includes a script for waiting for a command to become available. Perfect! However that a) doesn't work and b) would appear be based on standard OSGI gogo shell commands by the looks of it, rather than karaf shell commands, which aren't registered as services.
>
> Thanks.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Waiting for a command to be available
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, you can set this in custom.properties.
On 20/03/2019 09:50, tom@quarendon.net wrote:
>> By the way, you can also add a delay to have shell available. You can do
>> this by adding karaf.delay.console=true in etc/config.properties.
>
> That looks promising.
> Can I set that other than in etc/config.properties? Can I set it in custom.properties for example (no), or somewhere similar?
>
> I don't want to have to copy the complete config.properties file and ship a copy of it, that feels fragile.
> Thanks.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Waiting for a command to be available
Posted by to...@quarendon.net.
> By the way, you can also add a delay to have shell available. You can do
> this by adding karaf.delay.console=true in etc/config.properties.
That looks promising.
Can I set that other than in etc/config.properties? Can I set it in custom.properties for example (no), or somewhere similar?
I don't want to have to copy the complete config.properties file and ship a copy of it, that feels fragile.
Thanks.
Re: Waiting for a command to be available
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By the way, you can also add a delay to have shell available. You can do
this by adding karaf.delay.console=true in etc/config.properties.
The shell will be available only when boot features are completely started.
Regards
JB
On 20/03/2019 09:31, tom@quarendon.net wrote:
> I'm wanting to automate some setup of a karaf based product. I want to create a docker image that is pre-configured for internal testing.
>
> In order to do this I need to run some karaf shell commands.
> What I was naively hoping to do is do something like:
>
> /opt/karaf/bin/start && /opt/karaf/bin/client -u admin -p admin -f commands.txt && /opt/karaf/bin/stop
>
> or perhaps:
>
> /opt/karaf/bin/karaf < commands.txt
>
> However my problem is that the shell comes up before the commands I need are available to run.
>
> Any suggestions on how to deal with this?
> - I can't find any documentation on shell variables that might give me a return code I could check and loop on with a sleep. This would probably work, but feels crude.
> - A "does this command exist" command might be useful if I can then loop on its result. I can probably create such a command and put it in a bundle that I specify with a low start order to ensure it's available.
> - Crudely sleeping for a long period of time would work (most of the time) but is inefficient.
> Fiddle with the start level of the shell bundle so that it comes up last (I'm not even totally sure that would work -- since component activation happens asynchronously I suspect that things from earlier bundles are still happening while later bundles are then being started).
>
> Or is what I'm trying to do just not very sensible? Even if I created REST API endpoints do to it I'd have essentially the same issue, I could just write the logic in an external program of some kind, java, shell, whatever (repeatedly "ping" an endpoint until it doesn't return 404, then I know the endpoints are available). I'm guessing JMX would have essentially the same problem, in that I would have to start karaf then loop until the JMX beans become available.
>
> Note that I found what appears to be some old karaf documentation (https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/scripting.html) that includes a script for waiting for a command to become available. Perfect! However that a) doesn't work and b) would appear be based on standard OSGI gogo shell commands by the looks of it, rather than karaf shell commands, which aren't registered as services.
>
> Thanks.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com