I was exploring thIS cordapp example
https://github.com/corda/corda-training-template.git
There is a total of 4 nodes (Notary, A, B, and C) in this example. I am trying to open all the nodes in a single run using runnodes script from the terminal.
But all the nodes are not opening at a time. It's like alternatively they are opening, onetime only Notary and C nodes are opening and another time A and B nodes are opening.
Any specific reason?
And also I am getting this message in the webserver terminal. Please explain.
"The Corda specific webserver is deprecated and will be removed in future".
The runnodes script is not a very reliable way of starting up the nodes. Its mostly used for development purposes to make development faster.
It might sometimes not work as expected. The script works by opening up a terminal window and running the command to start the node in that particular terminal. Depending on the speed of the system, the command sometimes gets executed before the new terminal is opened up.
The reliable way to start a Corda node, however, is to use the java -jar corda.jar command. So just go into each individual nodes folder and run the command to start the node.
Here's the script :
#!/usr/bin/env bash
set -eo pipefail
# Allow the script to be run from outside the nodes directory.
basedir=$( dirname "$0" )
cd "$basedir"
if [ -z "$JAVA_HOME" ] && which osascript >/dev/null; then
# use default version of java installed on mac
/usr/libexec/java_home --exec java -jar runnodes.jar "$#"
else
"${JAVA_HOME:+$JAVA_HOME/bin/}java" -jar runnodes.jar "$#"
fi
Its the same one that you use to start the node, found in build/nodes folder
Related
I am using Ubuntu via WSL 2.0 on Windows 10 and would like to run Texlive from the Windows command line. To do so I prepended the Texlive folder to the path in /etc/environment (I also tried a number of other locations eg. $HOME/.bashrc):
C:\Users\scott\Documents>wsl echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
C:\Users\scott\Documents>wsl
scott#SCOTT-PC:/mnt/c/Users/scott/Documents$ echo $PATH
/usr/local/texlive/2020/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Windows/system32:...
Why is there a difference between these two paths? Is it possible to change the first PATH variable?
To be honest, when I first looked at this question, I thought it would be an easy answer. Oh how wrong I was. There are a lot of nuances to how this works.
Let's start with the fairly "easy" part, though. The main difference between the first method and the second:
wsl by itself launches into a login (and interactive) shell
the shell launched with wsl echo $PATH is neither a login shell nor an interactive shell
So the first will source both login scripts (e.g. ~/.profile) and interactive startup scripts (e.g. ~/.bashrc). The second form does not get to source either of these.
You can see this a different way (and get to the solution) with the following commands:
wsl -e bash -c 'echo $PATH'
wsl -e bash -li -c 'echo $PATH'
The -li forces bash to run as a login and interactive shell, thus sourcing all of the applicable startup scripts. And, as #bovquier points out in the comments, a single quote is needed here to prevent PowerShell from interpolating the $ before it gets to Bash. That, or escape it.
You should be able to run TeX Live the same way, just replacing the "echo $PATH" with the startup command you need for TeX Live.
A second option would be to create a script that both adds the path and runs the command, and just launch that script through wsl /path/to/script.sh
That said, I honestly don't think that your current login/interactive PATH is coming from /etc/environment. In my testing, at least, /etc/environment has no use in WSL, and that's to be expected. /etc/environment is only sourced by PAM modules, and with no login check performed by WSL, there's no reason to invoke PAM in either the wsl nor the wsl echo $PATH commands.
I'd expect that you still have the PATH setting in ~/.bashrc or somewhere similar), and that's where the shell is picking it up from at the moment.
While this isn't necessarily critical to understanding the answer, you might also wonder, if /etc/environment isn't used for setting the default (non-login, non-interactive) path in WSL, what is? The answer seems to be that it is hard-coded into the init that starts up WSL. That init is also what appends the Windows path (assuming you don't have that feature disabled in /etc/wsl.conf).
I want to execute a Linux binary from a QT application running on W10.
In QT we have QProcess to launch additional processes. However, since my binary is for Linux, I've thought of two possible approaches:
Running the binary in a container (i.e.: Docker, Kubernetes, Singularity...).
Executing the binary through WSL (Ubuntu) bash.
In any case, the QT application should initiate the process (the container or the bash) and, in turn, this process should launch my binary.
I've been searching on the web and I could not find something related, what makes me think that it will be difficult. For this reason, I am posting the question in order to know the viability of the proposed approaches.
EDITED
It looks like the WSL is easier, the problem is that the user has to have install ed it. Apart from requiring the sudo password when installing new software via apt-get.
The binary that I have to execute only exists for Linux, and let's say that cross-compiling is dismissed because of its complexity. Furthermore, this application needs CGAL, BOOST, MPI, among other pieces of software.
If you want to go with WSL, you can just run wsl myLinuxProgram --options.
Using WSL is the easiest way I believe as the current directory (PWD), is the current one i.e. the same as the PWD of your Qt app.
You can read Microsoft documenation for more info: https://learn.microsoft.com/en-us/windows/wsl/interop
If your linux binary depends on a lots of things, I really suggest you use docker for windows. Then, you have chance to pre-build an own docker image which put all dependency software also the linux binary you need to run in it.
Of course, to let your customer to use it, you should put it to dockerhub, register an account for yourself.
Then, the solution is simple: let the QT application to call docker run to setup a container base on your own image, execute it, and also let the linux binary to write the log or others to the bind mount volume among linux container & windows. After it run, the QT application fetch the linux binary output from this shared folder.
Finally, I give a minimal workable example for your reference:
Suppose the shared folder between windows & linux container is: C:\\abc\\log_share, it will mapped to linux container as /tmp folder. Of course you need to allow volume share by right click the docker icon in windows tray area & choose settings, like described here
Simplify the windows application as bat file, and simplfy the docker image as ubuntu, you should use your own prebuilt docker image with all dependency in it:
win_app.bat:
ECHO OFF
::New a shared folder with linux container
RD /s/q C:\\abc\\log_share > NUL 2>&1
MKDIR C:\\abc\\log_share
::From windows call docker to execute linux command like 'echo'
echo "Start to run linux binary in docker container..."
docker run -it -v C:\\abc\\log_share:/tmp ubuntu:16.04 bash -c "echo 'helloworld' > /tmp/linux_log_here.txt"
::In windows, get the log from shared bind mount from linux
echo "Linux binary run finish, print the log generated by the container..."
type C:\\abc\\log_share\linux_log_here.txt
Simplify the linux binary just as echo command in linux, the output things should be all write to shared directory:
echo 'helloworld' > /tmp/linux_log_here.txt
Now, execute the bat file with command win_app.bat:
C:\abc>win_app.bat
C:\abc>ECHO OFF
"Start to run linux binary in docker container..."
"Linux binary run finish, print the log generated by the container..."
helloworld
You can see the windows application already could fetch things(here is helloworld) which generated by linux binary from docker container.
I have been fighting with udev all afternoon. Basically I have created a rule that detects when a mass storage device is plugged into the system. This rule works and I can get it to execute a script without any issues, here it is for review purposes:
ACTION=="add", KERNEL=="sd?*", SUBSYSTEM=="block", RUN+="/usr/local/bin/udevhelper.sh"
The problem I am running into is that the script is executed as some sort of strange user that has read-only permissions to the entire system. The script I am executing is quite simple:
#!/bin/sh
cd /usr/local/bin
touch .drivedetect
echo "1" > .drivedetect
exit
Basically I would like udev to run this script and simply output a 1 to a file named .drivedetect within the /usr/local/bin folder. But as I mentioned before it sees the rule and executes the rule when I plug in a drive however when it tries to run the script it comes back with file system is read-only script quit with error code 1.
I am currently running this on a raspberry pi zero and the latest Debian image. udev is still being run from init.d from what I can tell because there is no systemd service for it registered. Any help would be great and if you need any more information just ask.
Things I've tried:
MODE="0660"
GROUP="plugdev"
Various combinations of RUN+="/bin/sh -c '/path/to/script'" and /bin/bash
OPTIONS="last_rule"
And last but not least I tried running the script under the main username as well
#!/bin/sh
su pi drivedetect
I had same issue, when I just used
udevadm control --reload-rules
after editing a udev rule. But, if I do:
sudo /etc/init.d/udev restart
The script can edit a file.
It's not enough to reboot. I have to do the restart after booting. It then works as expected until the next reboot.
This is on an rpi with stretch-lite.
Let's say you run a command like grunt serve on a tmux pane,
and you kill the pane on which the command is running. I found that
the process is not killed:
ps aux | grep grunt
still shows that grunt is running even though the pane is gone.
How do you kill a tmux pane along with the process(es)?
To stop the program running you can close the pane by entering <C-B> x and then entering y.
Just do: <CTRL-B>:kill-pane
Use Ctrl + b¹, > to get a menu with this and other useful commands:
This is what uses the Spotify plugin.
¹ Or the chosen tmux escape sequence.
Other notes and sources
tmux list-keys | grep display-menu #
curl cht.sh/tmux # Online cheatsheet
https://wiki.archlinux.org/title/tmux
You may find the tmux-safekill plugin useful.
I wanted it to kill Ruby processes, so I had to fork the repo to add that functionality in, so I'm sure you could do the same for grunt processes if you don't get all the functionality you need from the repo directly.
My Mac OS command line application is making Unix calls such as:
system("rm -rf /Users/stu/Developer/file);
perfectly successfully.
So why is the following not changing the current directory?
system("cd /Users/me/whatever");
system("pwd"); //cd has not changed
Because
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.
So each command is executed independently, each in a new instance of the shell.
So your first call spawns a new sh (with your current working directory), changes directories, and then exits. Then the second call spawns a new sh (again in your CWD).
See the man page for system().
The better solution is to not use system. It has some inherent flaws that can leave you open to security vulnerabilities. Instead of executing system() commands, you should use the equivalent POSIX C functions. Everything that you can do from the command-line, you can do with C functions (how do you think those utilities work?)
Instead of system("rm -rf ...") use this.
Instead of system("cd ...") use chdir().
Instead of system("pwd ...") use getcwd().
There are some differences, of course, but these are the fundamental equivalents of what you're trying to do.