How to reload wildfly using CLI - jboss

How is it done? I have scoured the net and no combination that I have found and tried works.
According to this https://access.redhat.com/documentation/en-us/jboss_enterprise_application_platform/6.2/html/administration_and_configuration_guide/reload_the_application_server_using_the_management_cli
it's easy: just run
:reload
But that does not work for me - I get
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0031: No operation named 'reload' exists at address []",
"rolled-back" => true
}
This is what I've tried:
Either the CLI command (i.e. when inside the CLI) or the command line (i.e. as passed to /jboss-cli.sh) would be very much appreciated.
By the way, I think I am running in standalone mode (certainly, there is only one instance running on my computer).
Many thanks.

You're not running in standalone mode which is why the :reload operation and reload command do not exist. In your screenshot it shows [domain#localhost:9990]. That means you're running in domain mode.
For domain mode you can still reload however. You just need to execute the operation on the host you're working on. By default the host name is master. The command would be:
/host=master:reload

Related

What causes error "Connection test failed: spawn npm; ENOENT" when creating new Strapi project with MongoDB?

I am trying to create a new Strapi app on Ubuntu 16.4 using MongoDB. After stepping through the tutorial, here: https://strapi.io/documentation/3.0.0-beta.x/guides/databases.html#mongodb-installation, I get the following error: Connection test failed: spawn npm; ENOENT
The error seems obvious, but I'm having issues getting to the cause of it. I've installed latest version of MongoDB and have ensured it is running using service mongod status. I can also connect directly using nc, like below.
$ nc -zvv localhost 27017
Connection to localhost 27017 port [tcp/*] succeeded!
Here is an image of the terminal output:
Any help troubleshooting this would be appreciated! Does Strapi perhaps log setup errors somewhere, or is there a way to get verbose logging? Is it possible the connection error would be logged by MongoDB somewhere?
I was able to find the answer. The problem was with using npx instead of Yarn. Strapi documentation states that either should work, however, it is clear from my experience that there is a bug when using npx.
I switched to Yarn and the process proceeded as expected without error. Steps were otherwise exactly the same.
Update: There is also a typo in Strapi documentation for yarn. They include the word "new" before the project name, which will create a project called new and ignore the project name.
Strapi docs (incorrect):
yarn create strapi-app new my-project
Correct usage, based on my experience:
yarn create strapi-app my-project
The ENOENT error is "an abbreviation of Error NO ENTry (or Error NO ENTity), and can actually be used for more than files/directories."
Why does ENOENT mean "No such file or directory"?
Everything I've read on this points toward issues with environment variables and the process.env.PATH.
"NOTE: This error is almost always caused because the command does not exist, because the working directory does not exist, or from a windows-only bug."
How do I debug "Error: spawn ENOENT" on node.js?
If you take the function that Jiaji Zhou provides in the link above and paste it into the top of your config/functions/bootstrap.js file (above module.exports), it might give you a better idea of where the error is occurring, specifically it should tell you the command it ran. Then run the command > which nameOfCommand to see what file path it returns.
"miss-installed programs are the most common cause for a not found command. Refer to each command documentation if needed and install it." - laconbass (from the same link, below Jiaji Zhou's answer)
This is how I interpret all of the above and form a solution. Put that function in bootstrap.js, then take the command returned from the function and run > which nameOfCommand. Then in bootstrap.js (you can comment out the function), put console.log(process.env.PATH) which will return a string of all the directories your current environment is checking for executables. If the path returned from your which command isn't in your process.env.PATH, you can move the command into a path, or try re-installing.

OrientDB 2.2.13 console.sh: getting "Cannot create a connection to remote server address(es)"

I have an embedded database where I start an OServer and trying to connect to it from the console. I've been doing this successfully for many months and upgrading the database as new versions come out. Now, with 2.2.13, the embedded operations seem to work but I can't connect to the server with the 2.2.13 console.sh. I get the message:
Error: com.orientechnologies.orient.core.exception.OStorageException: Cannot create a connection to remote server address(es): [127.0.0.1:2424]
DB name="master"
The java code running the embedded database gets the following exception:
$ANSI{green {db=db}} Error executing request
com.orientechnologies.orient.core.exception.ODatabaseException: Error on plugin lookup: the server did not start correctly
DB name="db"
at com.orientechnologies.orient.server.OServer.getPlugin(OServer.java:850)
at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.openDatabase(ONetworkProtocolBinary.java:857)
at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.handshakeRequest(ONetworkProtocolBinary.java:229)
at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.execute(ONetworkProtocolBinary.java:194)
at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:77)
Seems to be looking for the 'cluster' plugin.
Any idea why this doesn't work anymore? It did work in 2.2.12.
Thanks
Curtis
Seems I had automatic backup turned on but the config file was missing. So, the server looked like it started up but actually didn't.
I created the config file and set enabled to false. Still didn't start up because it sees the false and stops the configuration and throws an exception because the 'delay' parameter isn't set.
I think orientdb should start up without backups enabled if the config file is missing or the enabled parameter is set to false.
At least the console is working now.

synchronizing history when ipython notebook and console are connected to the same kernel

I have ipython notebook running on a remote server, i.e.
ipython notebook --profile=nbserver
which I access from my local machine. Further, I ssh to the remote server from my machine, and start ipython console (terminal) on that server. I have found following command to work well:
ipython console --existing \
~/.config/ipython/profile_nbserver/security/kernel-*.json
Now I am connected to the same remote kernel from two different clients (lets call them browser and terminal). Everything works well, except one annoying detail:
1) in browser, I type a=1
2) in terminal, I type b=2
3) in both clients I can see both commands using %history. But when I want to cycle through the history (in terminal) using Up, it only shows the commands which have been typed in the terminal, (i.e b=2). Similarly, I am unable to use a + PageDown in the terminal, to go back in history and find the command starting with a.
From what I understand, my two clients are using two separate history files history.sqlite. But why does %history show all commands ?
Question:
Is there any way to configure using one history.sqlite for both clients ?
I find, having easy access to history is absolutely crucial. Moreover, I see using both terminal and browser as complementary, they both have tradeoffs and are best used combined.
You can set where the history gets loaded either by setting it at the terminal:
ipython --HistoryManager.hist_file=$HOME/ipython_hist.sqlite
or within the ipython config files:
import os
c.HistoryManager.hist_file=os.path.expanduser("~/ipython_hist.sqlite")

Oracle ILOM CLI access

I am trying to access an Oracle ILOM interface via command line to read the event log.
As far as I know there are several ways to do this, but none work for me and my environment:
IPMItools: seems to be available only for Linux or on the CD/DVD that originally came with the server, which of course was lost;
SSH access (via putty) works fine, but I could not figure a way to automate logging in, running a command on the remote server and reading the result (still looking into it);
command line SSH access via plink works fine, but as soon as I try adding a command to run on the server (e.g. plink.exe -l root -pw password FQDN help) I get the error message "shell: Invalid credentials". adding the -t option did not change anything;
the SSH.NET library for powershell fails with the following exception "Exception calling "Connect" with "0" argument(s): "No suitable authentication method found to complete authentication". Documentation suggests adding a generated public RSA key to the server to allow for possword-less login. That cannot be done on Sun ILOMs;
Connecting via a serial port as detailed here does not work for me. I must be missing something from the posted code, but I simply cannot open a connection.
Has anyone ever tried to access an ILOM from command line? Could anyone offer a pointer as to what might work?
Ideally I'd like to automate this in a powershell script to be run from a Windows machine, but I'm open to any suggestions that do not require Visual Studio to implement.
Any help would be greatly appreciated!
ipmi and ssh remote command only supports in ilom3.0+.
if you are using alom, ilom2.0, or sxcf, you won't be able to use these tools.
I'd recommand to use python with pexpect https://pexpect.readthedocs.io/en/stable/.
check my snippet https://gist.github.com/happlebao/ca143cf3feaf60ca8ef75f7a66cf8a8a

Why is pgsql sometimes not listening for the first few seconds after start even though "service postgres status" returns OK?

I have a web app that uses postgresql 9.0 with some plperl functions that call custom libraries of mine. So, when I want to start fresh as if just released, my build process for my development area does basically this:
dumps data and roles from production
drops dev data and roles
restores production data and roles onto dev
restarts postgresql so that any cached versions of my custom libraries are flushed and newly-changed ones will be picked up
applies my dev delta
vacuums
Since switching my app's stack from win32 to CentOS, I now sometimes (i.e., it seems, only if and only if I haven't run this build process in "a while"--perhaps at least a day) get an error when my build script tries to apply the delta:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Specifically, what's failing to execute at the shell level is this:
psql --host=$host -U $superuser -p $port -d $db -f "$delta_filename.sql"
If, immediately after seeing this error, I try to connect to the dev database with psql, I can do so with no trouble. Also, if I just re-run the build script, it works fine the second time, every time I've encountered this. Acceptable workaround, but is the underlying cause something to be concerned about?
So far in my attempts to debug this, I inserted a step just after the server restart (which of course reports OK shutdown, OK startup) whereby I check the results of service postgresql-dev status in a loop, waiting 2 seconds between tries if it fails. On my latest build script run, said loop succeeds on the first try--status returns "is running"--but then applying the delta still fails with the above connection error. Again, second try succeeds, as does connecting via psql outside the script just after it fails.
My next debug attempt was to sleep for 5 seconds before the first status check and see what happens. So far this seems to solve the problem.
So why is pgsql not listening on the socket after it starts [OK] and also has status running ok, for up to 5 seconds, unless it has "recently" been restarted?
The status check only checks whether the process is running. It doesn't check whether you can connect. There can be any amount of time between starting the process and the process being ready to accept connections. It's usually a few seconds, but it could be longer. If you need to cope with this, you need to script it so that it checks whether it is possible to connect before proceeding. You could argue that the CentOS package should do this for you, but it doesn't.
Actually, I think in your case there is no reason to do a full restart. Unless you are loading libraries with shared_preload_libraries, it is sufficient to restart the connection to pick up new libraries.