Good morning, I have a problem running a command on the linux terminal and returning it to an api, for some reason I get a response on the server that has nothing to do with it, it's as if I just ran the "show route". The answer is in an array but this is normal, the problem is that they have nothing to do with the manual command.
Code:
Manual command:
Result the server receives:
Try
exec('/usr/sbin/birdc show route', (err, stdout, stderr)=>{})
Related
I am following along here - https://docs.solana.com/developing/on-chain-programs/debugging
I have included this line in .bashrc
export RUST_LOG=solana_runtime::system_instruction_processor=trace,solana_runtime::message_processor=info,solana_bpf_loader=debug,solana_rbpf=debug
When I deploy a program to solana-test-validator and call the function the program completes sucessfully however the msg! calls in the rust program are not printing in the console.
I am getting command not found error for below. Do I have to configure the github cargo registry?
$RUST_LOG
solana_runtime::system_instruction_processor=trace,solana_runtime::message_processor=info,solana_bpf_loader=debug,solana_rbpf=debug: command not found
To see the msg! calls, you can use the solana logs tool, pointed at your local validator, by opening up another terminal and running:
solana logs --url localhost
Check out https://docs.solana.com/cli/usage#solana-logs for the full info on how to use it.
My requirement is to embed a terminal in my React-Electron app wherein all commands which I can run from bash can be run in the embedded terminal too.
Suppose I want to 'npm install' I want it to be possible through my embedded terminal too. Could anyone suggest possible solutions ?
I'm not exactly sure, but I bet you can create a interface with an text input, get the content from it, and use some function of NodeJS to run that content (witch should be a command). Then, just print the result on the screen.
You can use the exec function from "child_process" dependencie, like this.
const { exec } = require("child_process");
exec("ls");
For more details, you can check here: https://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback
I am developing a library/tool which lets the user execute arbitrary commands via SSH. Overall, this lib/tool will serve as software deployment tool, which needs access to remote machines to execute several commands (cd, mkdir, git ..., npm install, scp, etc).
While it basically works to execute remote commands via SSH, it seems that every time the command npm install is executed, the SSH connection gets terminated. I cannot tell what is causing this, but this very simple Node.js script can demonstrate it:
const spawn = require('child_process').spawn;
const bat = spawn('ssh', ['-T', '-oRequestTTY=no', '-oBatchMode=yes', 'user#host']);
bat.stdout.on('data', (data) => console.log('STDOUT: ' + data.toString()));
bat.stderr.on('data', (data) => console.log('STDERR: ' + data.toString()));
bat.on('exit', (code) => console.log(`Child exited with code ${code}`));
setTimeout(() => {
bat.stdin.write('pwd -P\n');
bat.stdin.write('cd someDir\n');
bat.stdin.write('npm install\n');
setTimeout(() => bat.stdin.write('pwd -P\n'), 2000);
}, 2000);
This will break/terminate the forked SSH process after npm install, so the delayed pwd -P will also fail. Removing the npm install command will make the SSH process stay intact until the app is terminated by the user.
I have actually faced this problem when I was working with the c library libssh, which had the very same issue, although I failed to notice that the npm install command seems to actually trigger the problem. See this related post: Channel in libssh gets closed for no obvious reason
What I found out is:
1. I am using a non-pty SSH shell
2. The libsshpacket-level debug output shows a packet 98 sent by the server just before the connection is closed
3. According to the RFC, packet 98 is SSH_MSG_CHANNEL_REQUEST, which can also be used to request a pty
So my asumption is, that I am working on a non-pty shell over SSH, and that something in the npm programm directly or indirectly leads to a server-side request for a pty, which cannot be handled by the non-pty shell I am working on, and thus, the SSH connection is closed on protocol-level.
Now my question is, what could be causing this, and is there a way to get rid of this problem?
Update may 29th
Actually, I was able to investigate this issue further. I started editing npm-cli.js and commented out everything, then step-by-step uncommented the lines, to see what is going to trigger the above behaviour.
At first, it seemed like the set-blocking module included via npmlog was causing the issue, but after also commenting out the actual code of set-blocking in index.js:4 (which is only stream._handle.setBlocking(blocking)), the bad behaviour still occurs, which confused the fuck out of me. Experimenting further revealed that actually the single piece of process.stdout is causing the whole issue.
To verify, I did the following:
Comment-out lines 22-94 in npm-cli.js. Executing npm install now will essentially do nothing. Also, running my example program above will not have the error.
Add the following code to npm-cli.js:19: if (process.stdout) ;. This also essentially does nothing, but it leads to the error occur again if executing the above test program.
Do the opposite test and change if (process.stdout) ; to if (process) ; - the test program will now run again without error.
So basically the above Node.js testprogram which demonstrates the error can be changed so that instead of npm install a simple oneline script is invoked, which results in the same error:
const spawn = require('child_process').spawn;
const bat = spawn('ssh', ['user#host']);
setTimeout(() => {
bat.stdin.write('node test.js\n'); // this breaks it
setTimeout(() => bat.stdin.write('pwd -P\n'), 2000);
}, 2000);
With test.js containing:
if (process.stdout) ; // only this line
I dont know how the process global object is constructed, or what is going on here, but something in Node.js' process/process.stdout object is somehow breaking SSH connections. I therefore think this is not an actual issue of npm, only indirectly.
Could anyone help to clarify?
Using mocha-phantomjs-core with slimerjs
I manage to run my tests successfully from CMD:
slimerjs mocha-phantomjs-core.js tests.html tap
Slimerjs window opens, I see the a browser window and all seems good, but the CMD doesn't finish (seems to wait for something). nothing is happening until I close the slimerjs window. I want to output the test result (using TAP reporter) as a file.
is that possible?
https://github.com/nathanboktae/mocha-phantomjs-core/issues/25
system.stderr.writeLine doesn't work on CMD or GIT bash... I've changed mocha-phantomjs-core.js fail function stderr to do stdout instead. now I get the error:
Likely due to external resource loading and timing, your tests require
calling window.initMochaPhantomJS() before calling any mocha setup
functions. See #12
So I had to add window.initMochaPhantomJS() before the setup function.. how silly! all this because I couldn't see any error due to the stderr issue not printed
I installed the Freeswitch on Ubuntu Image in the Docker, referring to the documentation mentioned here.
When I did the following:
Start FreeSWITCH
First Time
cd /usr/local/freeswitch/bin
./freeswitch
I got to the following screen on my command prompt.
And as the last line says, [WARNING] switch_console.c:1053 We've become an orphan, no more console for us., something is wrong here I believe.
As per the documentation, I was expecting the prompt, like freeswitch#domain> .
Does anyone know what could be the problem? Upon researching this error I landed at the source file many times at different places, for example, one mentioned here
I had the same problem.
If we look in the source code of Freeswitch, we see
if (getppid() == 1) {
switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_WARNING, "We've become an orphan, no more console for us.\n");
break;
}
We see that we had pid == 1, this mean that parent process for freeswitch is init process but we launched it in bash
docker run -it freeswitch_container bash
Problem described here
To solve this you just need to run another bash in running bash, so it will have pid != 1.