After modifying /lib/udev/rules.d/99-tpm.rules file, am trying to reload using below commands
sudo udevadm control --reload-rules
sudo udevadm trigger
But getting error as below:
edge#edge:~$ sudo udevadm control --reload-rules
Failed to wait for daemon to reply: Connection timed out
What is the solution for this?
Related
I want to be able to view MUI's components library and api docs on my mac while I'm offline. I was given the below instructions by MUI support
This is what I put into my terminal.
git clone https://github.com/mui-org/material-ui.git
cd material-ui
yarn
yarn docs:build
yarn docs:start
this is what I get out of my terminal
apple2#apple2s-iMac material-ui % yarn docs:start
yarn run v1.22.10
$ yarn workspace docs start
$ next start
Error: listen EADDRINUSE: address already in use 0.0.0.0:3000
at Server.setupListenHandle [as _listen2] (node:net:1330:16)
at listenInCluster (node:net:1378:12)
at doListen (node:net:1516:7)
at processTicksAndRejections (node:internal/process/task_queues:84:21) {
code: 'EADDRINUSE',
errno: -48,
syscall: 'listen',
address: '0.0.0.0',
port: 3000
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed.
Exit code: 1
Command: /usr/local/Cellar/node/17.3.0/bin/node
Arguments: /Users/apple2/Desktop/Code/material-ui/.yarn/releases/yarn-1.22.10.js start
Directory: /Users/apple2/Desktop/Code/material-ui/docs
Output:
info Visit https://yarnpkg.com/en/docs/cli/workspace for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
apple2#apple2s-iMac material-ui %
should I add the terminal outputs for each command input? (yarn docs:build is a large number of lines)
The error message EADDRINUSE is telling you that you already have something listening on port 3000. You need to stop the process/application currently using port 3000 so you can run MUI docs or tell MUI docs to use another port.
You can do one of the following:
Tell MUI docs to run on a different port: yarn docs:start --port=3001 (This is probably your best option.)
Look for the application (probably another terminal window -- your other React app?) and stop it (Ctrl + C)
Reboot your machine and make sure that nothing starts up listening on port 3000.
Find the process id in terminal and kill it manually.
To find the process id in terminal and kill it manually, open up terminal on your Mac and type the following commands:
Get a list of any processes listening on port 3000 (sudo will require you to enter your password)
sudo lsof -i :3000
A list of processes currently listening on port 3000 will be displayed. For example:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 53763 [your username] 28u IPv4 0x6c9dbf461b729ff1 0t0 TCP *:hbci (LISTEN)
Find the process id (PID) in the list for the process you want to kill -- in the example above, the process id is "53763".
Kill the process:
kill -9 53763
Now try to re-run MUI docs:
yarn docs:start
I am running the latest version of macOS Sierra and I installed PostgreSQL via brew. Then I ran the command:
pg_ctl -D /Users/tmo/PSQL-data -l logfile start
but received for output:
waiting for server to start..../bin/sh: logfile: Permission denied
stopped waiting
pg_ctl: could not start server
Examine the log output.
EDIT: After restarting my operating system and rerunning the command... I'm now receiving a slightly modified output... but the modification is significant.
waiting for server to start.... stopped waiting
pg_ctl: could not start server
Examine the log output.
Where is the "log output" stored?
How do I make this command work?
The problem could be one of two things, that I can see:
A typo in your database path:
/Users/tmo/PSQL-data --> /Users/tmp/PSQL-data
If the above was just a transcription error, I would guess that your postgres user doesn't have write access to the directory where you are setting the logfile. The argument following the -l switch tells PG where to save the logfile. When you don't provide the -l switch with a path, but just a filename, it will use the same dir you use to specify the database cluster (with the -D flag). So in this case, PG is trying to write to /Users/tmp/PSQL-data/logfile, and getting a permission error.
To fix this, I would try:
If the directory /Users/tmp/PSQL-data/ doesn't exist:
sudo mkdir /Users/tmp/PSQL-data
Then create the logfile manually:
sudo touch /Users/tmp/PSQL-data/logfile
Then make the postgres user own the file (I'm assuming user is postgres here)
sudo chown postgres /Users/tmp/PSQL-data/logfile
Try again, and hopefully you can launch the server.
Caveat: I'm not a macOS user, so I'm not sure how the /tmp folder behaves. If it is periodically cleared, you may want to specify a different logfile location, so that you don't need to create and chown the file each time you need to launch the cluster.
I am following this tutorial on using docker images, and I am at the stage to run the example docker image like follows:
docker run -p 4000:80 friendlyhello
On the command line it seems ok:
>docker run -p 4000:80 friendlyhello
* Running on http://0.0.0.0:80/ (Press CTRL+C to quit)
but when I try to open the page http://localhost:4000 on a web browser, it seems to be unable to connect (Safari and Firefox). On Firefox the error message is
Unable to connect
Firefox can't establish a connection to the server at localhost:4000.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.
I also checked the file /etc/hosts and it contains the following entry
127.0.0.1 localhost
So what could be the problem?
I found this solution and tried the following command:
docker run -p 127.0.0.1:4000:80 friendlyhello
which still leads to the same problem. I also tried to open
`http://localhost:80`
again without success.
I'm trying to install a custom Hadoop implementation (>2.0) on Google Compute Engine using the command line option. The modified parameters of my bdutil_env.sh file are as follows:
GCE_IMAGE='ubuntu-14-04'
GCE_MACHINE_TYPE='n1-standard-1'
GCE_ZONE='us-central1-a'
DEFAULT_FS='hdfs'
HADOOP_TARBALL_URI='gs://<mybucket>/<my_hadoop_tar.gz>'
The ./bdutil deploy fails with a exit code 1. I find the following errors in the resultant debug.info file:
ssh: connect to host 130.211.161.181 port 22: Connection refused
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
ssh: connect to host 104.197.63.39 port 22: Connection refused
ssh: connect to host 104.197.7.106 port 22: Connection refused
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
.....
.....
Connection to 104.197.7.106 closed.
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [123].
Connection to 104.197.63.39 closed.
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [123].
Connection to 130.211.161.181 closed.
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [123].
...
...
hadoop-w-1: ==> deploy-core-setup_deploy.stderr <==
....
....
hadoop-w-1: dpkg-query: package 'libsnappy1' is not installed and no information is available
hadoop-w-1: Use dpkg --info (= dpkg-deb --info) to examine archive files,
hadoop-w-1: and dpkg --contents (= dpkg-deb --contents) to list their contents.
hadoop-w-1: dpkg-preconfigure: unable to re-open stdin: No such file or directory
hadoop-w-1: dpkg-query: package 'libsnappy-dev' is not installed and no information is available
hadoop-w-1: Use dpkg --info (= dpkg-deb --info) to examine archive files,
hadoop-w-1: and dpkg --contents (= dpkg-deb --contents) to list their contents.
hadoop-w-1: dpkg-preconfigure: unable to re-open stdin: No such file or directory
hadoop-w-1: ./hadoop-env-setup.sh: line 612: Package:: command not found
....
....
hadoop-w-1: find: `/home/hadoop/hadoop-install/lib': No such file or directory
I don't understand why the initial ssh error is given; I can see the VMs and login to them properly from the UI; my tar.gz is also copied in the proper places.
I also do not understand why libsnappy wasn't installed; is there anything particular I need to do? The shell scripts seem to be having commands to install it, but it's failing somehow.
I checked all the VMs; Hadoop is not up.
EDIT : For solving the ssh problem, I ran the following command:
gcutil --project= addfirewall --allowed=tcp:22 default-ssh
It made no difference.
In this case, the ssh and libsnappy errors are red herrings; when the VMs weren't immediately SSH-able, bdutil polled for awhile until it should've printed out something like:
...Thu May 14 16:52:23 PDT 2015: Waiting on async 'wait_for_ssh' jobs to finish. Might take a while...
...
Thu May 14 16:52:33 PDT 2015: Instances all ssh-able
Likewise, the libsnappy error you saw was a red herring because it's coming from a call to dpkg -s trying to determine whether a package is indeed installed, and if not, to apt-get install it: https://github.com/GoogleCloudPlatform/bdutil/blob/master/libexec/bdutil_helpers.sh#L163
We'll work on cleaning up these error messages since they can be misleading. In the meantime, the main issue here is that Ubuntu hasn't historically been one of the supported images for bdutil; we thoroughly validate CentOS and Debian images, but not Ubuntu images, since they were only added as GCE options in November 2014. Your deployment should work fine with your custom tarball for any debian-7 or centos-6 image. We've filed an issue on GitHub to track Ubuntu support for bdutil: https://github.com/GoogleCloudPlatform/bdutil/issues/29
EDIT: The issue has been resolved with Ubuntu now supported at head in the master repository; you can download at this most recent commit here.
Looking at your error code, it seems like you have to download snappy libraries in your classpath. If you are using java then you can download your libraries from this path https://github.com/xerial/snappy-java. OR try this link https://code.google.com/p/snappy/.
I tried to install mongoDB on my macbook air.
I've downloaded zipped file from official website and extract that file and move to root directory.
After that, under that directory, I've made /data/db and /log folder.
Here is my mongodb.config which describes the basic config for my DB.
dbpath = /mongodb/data/db
logpath = /mongodb/log/mongo.log
logappend = true
#bind ip = 127.0.0.1
port = 27017
fork = true
rest = true
verbose = true
#auth = true
#noauth = true
Additionally, I want to know what the # means in the config file.
I put this file to /mongodb/bin, /mongodb is the directory I extracted the files into.
I opened terminal and entered ./mongod --config mongodb.config and I got this back.
Juneyoung-ui-MacBook-Air:bin juneyoungoh$ ./mongod --config mongodb.config
about to fork child process, waiting until server is ready for connections.
forked process: 1775
all output going to: /mongodb/log/mongo.log
ERROR: child process failed, exited with error number 100
How can I handle this error and what this means?
The data folders you created were very likely created with sudo, yes? They are owned by root and are not writable by your normal user. If you are the only user of your macbook, then change the ownership of the directories to you:
sudo chown juneyoungoh /data
sudo chown juneyoungoh /data/db
sudo chown juneyoungoh /data/log
If you plan on installing this on a public machine or somewhere legit, then read more about mongo security practices elsewhere. I'll just get you running on your macbook.
I had a similar issue and it was not related to any 'sudo' problem. I was trying to recover from a kernel panic!
When I look at my data folder I found out a mongod.lock file was there. In my case this page helped a lot: http://docs.mongodb.org/manual/tutorial/recover-data-following-unexpected-shutdown/. As they explain,
if the mongod.lock is not a zero-byte file, then mongod will refuse to start.
I tested this solution in my environment and it works perfectly:
Remove mongod.lock file.
Repair the database: mongod --dbpath /your/db/path --repair
Run mongod: mongod --dbpath /your/db/path
There was the same problem on my machine. In the log file was:
Mon Jul 29 09:57:13.689 [initandlisten] ERROR: Insufficient free space for journal file
Mon Jul 29 09:57:13.689 [initandlisten] Please make at least 3379MB available in /var/mongoexp/rs2/journal or use --smallfiles
It was solved by using mongod --smallfiles. Or if you start mongod with --config option than in a configuration file disable write-ahead journaling by nojournal=true (remove the beginning #). Some more disk space would also solve the above problem.
It's because you probably didn't shutdown mongodb properly and you are not starting mongodb the right way. According your mongodb.config, you have dbpath = /mongodb/data/db - so I assume you created the repository /mongodb/data/db? Let me clarify all the steps.
TO START MONGODB
In your mongodb.config change the dbpath = /mongodb/data/db to dbpath = /data/db. On your terminal create the db repository by typing: mkdir /data/db. Now you have a repository - you can start your mongo.
To start mongo in the background type: mongod --dbpath /data/db --fork --logpath /dev/null.
/data/db is the location of the db.
--fork means you want to start mongo in the background - deamon.
--logpath /dev/null means you don't want to log - you can change that by replacing /dev/null to a path like /var/log/mongo.log
TO SHUTDOWN MONGODB
Connect to your mongo by typing: mongo and then use admin and db.shutdownServer(). Like explain in mongoDB
If this technique doesn't work for some reason you can always kill the process.
Find the mongodb process PID by typing: lsof -i:27017 assuming your mongodb is running on port 27017
Type kill <PID>, replace <PID> by the value you found the previous command.
Similar issue with the same error - I was trying to run the repair script
sudo -u mongodb mongod -f /etc/mongodb.conf --repair
Checked ps aux | grep mongo and see that the daemon was running. Stopped it and then the repair script run without an issue.
Hope that could be helpful for someone else.
I had the same error on linux (Centos) and this worked for me
Remove mongod.lock from the dbpath
$ rm /var/lib/mongo/mongod.lock
Repair the mongod process
$ mongod --repair
Run mongod config
$ mongod --config /etc/mongod.conf
I had the same error. I ran it interactively to see the log.
2014-10-21T10:12:35.418-0400 [initandlisten] ERROR: listen(): bind() failed errno:48 Address already in use for socket: 0.0.0.0:27017
Then I used lsof to find out which process was using my port.
$ lsof -i:27017
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mongod 2106 MYUSERID 10u IPv4 0x635b71ec3b65b4a1 0t0 TCP *:27017 (LISTEN)
It was a mongod that I had forked previously and forgot to turn off (since I hadn't seen it running in my bash window).
Simply killing it by running kill 2106, enabled my process to run without the error 100.
Generally, this error comes when the mongod.conf file is not able to
find a certain path for
Database store
or log store
or maybe processid store
or maybe it's not getting the file permission to access the config directories and files which has been declared in mongod.conf
to resolve this error we need to observe the log generated by the MongoDB
it will clearly indicate whether which file or directory you MongoDB is not able to access
the above error may look like below screenshot
create folder "data" and "db" inside it, in "/" path of your server.
actually you should create or modify permissions of folder that the data is going to be stored!