forge start hangs for hours without printing any success or error message.
I have no idea what happened behind the scene, steps to reproduce the issue:
npm install -g #arcblock/forge-cli
forge init
forge start
It should start a local forge chain node in some reasonable time.
Related
I've been attempting to install virtuoso-opensource as per the README here: https://github.com/openlink/virtuoso-opensource
The first time I ran make, it breezed passed "VAD Sticker vad_dav.xml creation" to "Starting Virtuoso Server" and then complained netstat: command not found.
I installed netstat via sudo apt-get install net-tools, ran make again and now it's always stuck on "VAD Sticker vad_dav.xml creation" even after starting from scratch after deleting the repo folder and re-cloning it again. make install gets stuck at the same point.
Does anyone have any ideas as to how to get past this?
I'm running Ubuntu Server 20.04.1 LTS on an AWS EC2 instance.
I'll note the requirement for netstat to build VADs.
By far the most common cause of hang at that stage is a stagnant virtuoso pid lurking.
pkill virtuoso and run make again.
HTH
I use flow for a large JS project of mine. It used to work fine, showing errors in vim. But something happened in the last few months where it stopped reporting any errors (but still compiling fine using babel). When I started investigating, the issue seems to be that the flow server never finishes starting, for whatever reason. I have updated my flow-bin and flow-typed (sudo npm install -g flow-bin && sudo npm install -f flow-typed). When I attempt to start flow, I see the following message indefinitely (as number of parsed files keeps climbing to ridiculously high numbers):
Please wait. Server is initializing (parsed files 132568): /
It seems that both vim and atom editors I tried keep running into the same exact issue (vim silently, and atom actually shows a spinner claiming that flow is initializing. This is what my .flowconfig looks like:
[ignore]
.*\.git/.*
.*/public/*
.*/scripts/*
.*/dist/*
.*/cypress/*
.*/uploads/*
[untyped]
.*/node_modules/*
.*/lib/*
[libs]
flow-typed
[lints]
sketchy-null=warn
[options]
suppress_comment= \\(.\\|\n\\)*\\#flow-ignore
Currently installed versions:
❯❯❯ flow --version
Flow, a static type checker for JavaScript, version 0.116.1
❯❯❯ flow-typed --version
3.2.1
Try to update [options] section in .flowconfig with:
sharedmemory.hash_table_pow=21
I don't know why this is so difficult, but everytime I update a file in my flask application I have to restart gunicorn so that the file updates on the server. I am mostly a front-end developer and don't play with servers enough to remember these things, and I have to spend hours google searching various phrases to find the right commands. This time I can't seam to find anything, and the file I created to save these things has conveniently disappeared.
My server:
Ubuntu 18.04
nginx
gunicorn
supervisor
I am updating a .py file. I placed the updated version on the server using ftp. I'm logged into the server, using ssh, through a git bash shell. sudo systemctl gunicorn restart give me the error Failed to restart gunicorn.service: Unit gunicorn.service not found.. Rereading and restarting supervisor does not do the trick, and neither does restarting nginx. Is there not a simple command to apply updates? I'm use to using servers on general hosting sites, and updating a file via ftp just works. I was really enjoying learning flask up until this point, but now I regret it. I keep thinking that there has to be some kind of simple trick to make such a simple thing go smoothly, but I'm at the end of my rope trying to figure this out. Any suggestions?
I finally found it.
sudo supervisorctl stop app_name
sudo supervisorctl start app_name
I am running 5.1.0 of react-native-firebase-starter (https://github.com/invertase/react-native-firebase-starter/blob/master/package.json)
I have triple checked that I have followed the Getting Started instructions (from the readme) exactly. However, when I run the project I get "No Bundle URL Present".
I have searched for this error elsewhere and seen rm -rf ios/build/; kill $(lsof -t -i:8081); as the answer. I've tried this, and variations, several times but I cannot get the project to run.
I fixed it by adding 127.0.0.1 localhost to my /etc/hosts file
This worked for me:
Open a terminal window
cd into YOUR_PROJECT/ios
Remove the build folder with rm -r build
Run react-native run-ios again
I know its an old question but in Future if someone face this issue i have found a work around to this problem.
after running "react-native run-ios" command
Run another command "npm start"
after running above command you will "Loading dependency graph" wait
for 2 or three seconds and you will see thisLoading dependency
graph, done.
now press cmd+R OR you may tap on reload on screen if problem not
solved do step 4, 2 to 3 times
I run my meteor app on EC2 like this: node main.js (in tmux session)
Here are the steps I use to update my meteor app:
1) meteor bundle app.tgz
2) scp app.tgz EC2-server:/path
3) ssh EC2-server and attach to tmux
4) kill the current meteor-node process by C-c
5) extract app.tgz
6) run "node main.js" of the extracted app.tgz
Is this the standard practice?
I realize forever can be used too but still do you have to kill the old node process and start a new one every time I update my app? Can the upgrade be more seamless without killing the Node process?
You can't do this without killing the node process, but I haven't found that really matters. What's actually more annoying is the browser refresh on the client, but there isn't much you can do about that.
First, let's assume the application is already running. We start our app via forever with a script like the one in my answer here. I'd show you my whole upgrade script but it contains all kinds of Edthena-specific stuff, so I'll outline the steps we take below:
Build a new bundle. We do this on the server itself, which avoids any missing fibers issues. The bundle file is written to /home/ubuntu/apps/edthena/edthena.tar.gz.
We cd into the /home/ubuntu/apps/edthena directory and rm -rf bundle. That will blow away the files used by the current running process. Because the server is still running in memory it will keep executing. However, this step is problematic if your app regularly does uncached disk operatons like reading from the private directory after startup. We don't, and all of the static assets are served by nginx, so I feel safe in doing this. Alternatively, you can move the old bundle directory to something like bundle.old and it should work.
tar xzf edthena.tar.gz
cd bundle/programs/server && npm install
forever restart /home/ubuntu/apps/edthena/bundle/main.js
There really isn't any downtime with this approach - it just restarts the app in the same way it would if the server threw an exception. Forever also keeps the environment from your original script, so you don't need to specify your environment variables again.
Finally, you can have a look at the log files in your ~/.forever directory. The exact path can be found via forever list.
David's method is better than this once, because there's less downtime when using forever restart compared to forever stop; ...; forever start.
Here's the deploy script spelled out, using the latter technique. In ~/MyApp, I run this bash script:
echo "Meteor bundling..."
meteor bundle myapp.tgz
mkdir ~/myapp.prod 2> /dev/null
cd ~/myapp.prod
forever stop myapp.js
rm -rf bundle
echo "Unpacking bundle"
tar xzf ~/MyApp/myapp.tgz
mv bundle/main.js bundle/myapp.js
# `pwd` is there because ./myapp.log would create the log in ~/.forever/myapp.log actually
PORT=3030 ROOT_URL=http://myapp.example.com MONGO_URL=mongodb://localhost:27017/myapp forever -a -l `pwd`/myapp.log start myapp.js
You're asking about best practices.
I'd recommend mup and cluster
They allow for horizontal scaling, and a bunch of other nice features, while using simple commands and configuration.