I'm trying to use rabbitmq for a django tutorial but when I want to start the server I get this error:
~$ sudo rabbitmq-server
Configuring logger redirection
14:49:57.041 [error]
14:49:57.044 [error] BOOT FAILED
BOOT FAILED
14:49:57.044 [error] ===========
===========
14:49:57.044 [error] ERROR: could not bind to distribution port 25672, it is in use by another node: rabbit#wss
ERROR: could not bind to distribution port 25672, it is in use by another node: rabbit#wss
14:49:57.045 [error]
14:49:58.046 [error] Supervisor rabbit_prelaunch_sup had child prelaunch started with rabbit_prelaunch:run_prelaunch_first_phase() at undefined exit with reason {dist_port_already_used,25672,"rabbit","wss"} in context start_error
14:49:58.046 [error] CRASH REPORT Process <0.153.0> with 0 neighbours exited with reason: {{shutdown,{failed_to_start_child,prelaunch,{dist_port_already_used,25672,"rabbit","wss"}}},{rabbit_prelaunch_app,start,[normal,[]]}} in application_master:init/4 line 138
{"Kernel pid terminated",application_controller,"{application_start_failure,rabbitmq_prelaunch,{{shutdown,{failed_to_start_child,prelaunch,{dist_port_already_used,25672,\"rabbit\",\"wss\"}}},{rabbit_prelaunch_app,start,[normal,[]]}}}"}
Kernel pid terminated (application_controller) ({application_start_failure,rabbitmq_prelaunch,{{shutdown,{failed_to_start_child,prelaunch,{dist_port_already_used,25672,"rabbit","wss"}}},{rabbit_prelau
Crash dump is being written to: erl_crash.dump...done
I've searched for port to see that if it's in use or not and I used lsof -i :25672 and I get nothing.
I don't know too much about these things so if you need anything please tell me.
Try:
sudo lsof -i :25672
sudo kill <PID>
sudo rabbitmq-server
Where <PID> is the process ID that is occupying port 25672
I have encountered this issue. I figured out that this issue is coming because the rabbitmq-server is already running on the machine.
I have used the following command
rabbitmqctl.bat status to know the status of the rabbitmq-server. This helped me to know if the server is up or down.
If it is up, this could the reason you are getting the error that you have specified in your post.
You can issue the following command to make the server down
rabbitmqctl.bat stop
Now you can try starting the rabbitmq-server by issuing the following command
rabbitmq-server start
Note that I am using Windows. And I have executed these commands by pointing the command prompt to C:\Program Files\RabbitMQ\rabbitmq_server-3.8.14\sbin as my rabbitmq installation directory is C:\Program Files\RabbitMQ\rabbitmq_server-3.8.14.
I have encountered this before. Here is what caused it and how I fixed it:
This is one of those commands which requires the magic word sudo (i.e it needs a superuser privilege).
If you forget to add sudo to the command, it begins the process but later fails when it hits a superuser-only roadblock. This leaves you with an incomplete process. Now when you decide to add sudo, it attempts the same process again but finds out that someone without the right privilege has made a mess or is still messing around.
Then the solution will be to cancel out whatever the first command has started and try again.
sudo lsof -i :25672
This list out details about the port 25672
You will see the PID (process ID) e.g 1301
Then stop the process on that port with:
sudo kill <PID>
for example, sudo kill 1301
And make sure you are killing the right process if not you may get into trouble.
Now, retry the command with sudo:
sudo rabbitmq-server
ALSO,
In most cases, this error occurs because without deliberately stopping the rabbitmq-server, it always keeps running even after you restart you system.
another way to stop rabitmq server windows+R then type "services.msc" and then find for RabitMq.slelect and stop from left top corner.
Then re run your rabitmq server.
-Hi guys, I am putting up an answer that can help Googlers to run multiple rabbitmq-server on the same machine. Trying to achieve the latter, I ran into a similar error reported in the first place and solved that by defining:
export RABBITMQ_DIST_PORT=anything_other_than_25672
as stated in the documentation:
https://www.rabbitmq.com/networking.html#epmd-inet-dist-port-range
if you are using windows go to task manager and stop rabbitmq from running...
then reload the rabbitmq-server
For Linux others answered but in Windows you should press Ctrl+Alt+delete and select task management and in that end proccess that depends on erlang.
Note that it requires Administrator previlage.
Now enter this command to start rabbitmq-server:
rabbitmq-server start
Every time you restart your computer you should do these steps.For prevent do them again you should stop rabbitmq service from startup services.
went through same problem in windows, it is already running after installation as a service
so just enable the plugins from the rabbitmq commandline by entering the code as
rabbitmq-plugins enable management_plugin
than go to the localhost:15672 and good to go.
This means that your port 25672 is already in use
try: -
sudo lsof -i :25672
sudo kill <PID>
and now start your rabbitmq server using
sudo rabbitmq-server
I have setup a new blank react native app.
After installing few node modules I got this error.
Running application on PGN518.
internal/fs/watchers.js:173
throw error;
^
Error: ENOSPC: System limit for number of file watchers reached, watch '/home/badis/Desktop/react-native/albums/node_modules/.staging'
at FSWatcher.start (internal/fs/watchers.js:165:26)
at Object.watch (fs.js:1253:11)
at NodeWatcher.watchdir (/home/badis/Desktop/react-native/albums/node modules/sane/src/node watcher. js:175:20)
at NodeWatcher.<anonymous> (/home/badis/Desktop/react-native/albums/node modules/sane/src/node watcher. js:310:16)
at /home/badis/Desktop/react-native/albums/node modules/graceful-fs/polyfills.js:285:20
at FSReqWrap.oncomplete (fs.js:154:5)
I know it's related to no enough space for watchman to watch for all file changes.
I want to know what's the best course of action to take here ?
Should I ignore node_modules folder by adding it to .watchmanconfig ?
Linux uses the inotify package to observe filesystem events, individual files or directories.
Since React / Angular hot-reloads and recompiles files on save it needs to keep track of all project's files. Increasing the inotify watch limit should hide the warning messages.
You could try editing
# insert the new value into the system config
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
# check that the new value was applied
cat /proc/sys/fs/inotify/max_user_watches
# config variable name (not runnable)
fs.inotify.max_user_watches=524288
The meaning of this error is that the number of files monitored by the system has reached the limit!!
Result: The command executed failed! Or throw a warning (such as executing a react-native start VSCode)
Solution:
Modify the number of system monitoring files
Ubuntu
sudo gedit /etc/sysctl.conf
Add a line at the bottom
fs.inotify.max_user_watches=524288
Then save and exit!
sudo sysctl -p
to check it
Then it is solved!
You can fix it, that increasing the amount of inotify watchers.
If you are not interested in the technical details and only want to get Listen to work:
If you are running Debian, RedHat, or another similar Linux distribution, run the following in a terminal:
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
If you are running ArchLinux, run the following command instead
$ echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/40-max-user-watches.conf && sudo sysctl --system
Then paste it in your terminal and press on enter to run it.
The Technical Details
Listen uses inotify by default on Linux to monitor directories for changes. It's not uncommon to encounter a system limit on the number of files you can monitor. For example, Ubuntu Lucid's (64bit) inotify limit is set to 8192.
You can get your current inotify file watch limit by executing:
$ cat /proc/sys/fs/inotify/max_user_watches
When this limit is not enough to monitor all files inside a directory, the limit must be increased for Listen to work properly.
You can set a new limit temporary with:
$ sudo sysctl fs.inotify.max_user_watches=524288
$ sudo sysctl -p
If you like to make your limit permanent, use:
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p
You may also need to pay attention to the values of max_queued_events and max_user_instances if listen keeps on complaining.
From the official document:
"Visual Studio Code is unable to watch for file changes in this large workspace" (error ENOSPC)
When you see this notification, it indicates that the VS Code file watcher is running out of handles because the workspace is large and contains many files. The current limit can be viewed by running:
cat /proc/sys/fs/inotify/max_user_watches
The limit can be increased to its maximum by editing
/etc/sysctl.conf
and adding this line to the end of the file:
fs.inotify.max_user_watches=524288
The new value can then be loaded in by running
sudo sysctl -p
Note that Arch Linux works a little differently, See Increasing the amount of inotify watchers for details.
While 524,288 is the maximum number of files that can be watched, if you're in an environment that is particularly memory constrained, you may wish to lower the number. Each file watch takes up 540 bytes (32-bit) or ~1kB (64-bit), so assuming that all 524,288 watches are consumed, that results in an upper bound of around 256MB (32-bit) or 512MB (64-bit).
Another option
is to exclude specific workspace directories from the VS Code file watcher with the files.watcherExclude setting. The default for files.watcherExclude excludes node_modules and some folders under .git, but you can add other directories that you don't want VS Code to track.
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/*/**": true
}
delete react node_modules
rm -r node_modules
yarn or npm install
yarn start or npm start
if error occurs use this method again
Firstly you can run every time with root privileges
sudo npm start
Or you can delete node_modules folder and use npm install to install again
or you can get permanent solution
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
It happened to me with a node app I was developing on a Debian based distro. First, a simple restart solved it, but it happened again on another app.
Since it's related with the number of watchers that inotify uses to monitors files and look for changes in a directory, you have to set a higher number as limit:
I was able to solve it from the answer posted here
(thanks to him!)
So, I ran:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Read more about what’s happening at https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers#the-technical-details
Hope it helps!
Remembering that this question is a duplicated: see this answer at original question
A simple way that solve my problem was:
npm cache clear
best practice today is
npm cache verify
npm or a process controlled by it is watching too many files. Updating max_user_watches on the build node can fix it forever. For debian put the following on terminal:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
If you want know how Increase the amount of inotify watchers only click on link.
I use ubuntu 20 server and i add in the file : /etc/sysctl.conf the below line
fs.inotify.max_user_watches=524288
Then save the file and run sudo sysctl -p
After that all is works fine!
I solved this issue by using sudo
ie
sudo yarn start
or
sudo npm start
Use sudo to solve this issue will force the number of watchers to be increased without apply any modifications in system settings. Use sudo to solve this kind of issue is never recommended, although it's a choice that have to be made by you, hope you choose wisely.
Root cause
Most answers above talk about raising the limit, not about taking away the root cause which is typically just a matter redundant watches, typically for files in node_modules.
Webpack
The answer is in the webpack 5 docs:
watchOptions: { ignored: /node_modules/ }
Simply read here: https://webpack.js.org/configuration/watch/#watchoptionsignored
The docs even mention this as a "tip", quote:
If watching does not work for you, try out this option. This may help
issues with NFS and machines in VirtualBox, WSL, Containers, or
Docker. In those cases, use a polling interval and ignore large
folders like /node_modules/ to keep CPU usage minimal.
VS Code
VS Code or any code editor creates lots of file watches too. By default many of them are completely redundant. Read more about it here: https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
Generally we don't need to increase count of filewatchers
In this case we will have more watchers
We need to remove redundant watchers what became zombie
The issue is that we have many filewatchers that are filling out our memory
We just need remove these filewatchers (in case of node)
killall node
In react.js show me same error i fix this way hope work in react native too
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Now you can run npm start again.
npm start
Using the sysctl -p approach after setting fs.inotify.max_user_watches did not work for me (by the way this setting was already set to a high value, likely from me trying to fix this issue a while back ago, using the commonly recommended workaround(s) above).
The best solution to the problem I found here, and below I share the performed steps in solving it - in my case the issue was spotted while running visual studio code, but solving the issue should be the same in other instances, like yours:
Use this script to identify which processes are requiring the most file watchers in your session.
You can then query the current max_user_watches value with sysctl fs.inotify.{max_queued_events,max_user_instances,max_user_watches} and then set it to a different value (a lower value may do it)
sudo sysctl -w fs.inotify.max_user_watches=16384
Or you can simply kill the process you found in (1) that consumes the most file watchers (in my case, baloo_file)
The above, however, will likely need to be done again when restarting the system - the process we identified as responsible for taking much of the file watchers will (in my case - baloo_file) - will again so the same in the next boot. So to permanently fix the issue - either disable or remove this service/package. I disabled it: balooctl disable.
Now run sudo code --user-data-dir and it should open vscode with admin privileges this time. (by the way when it does not - run sudo code --user-data-dir --verbose to see what the problem is - that's how I figured out it had to do with file watchers limit).
Update:
You may configure VS code file watcher exclusion patterns as described here. This may prove to be the ultimate solution, I am just not sure you will always know beforehand which files you are NOT interested watching.
Easy Solution
I found, that a previous solution work well in my case. I removed node_modules and clear the yarn / npm cache.
Long Tail Solution
If you want to have a long-tail solution - e.g. if you often be catched by this error - you can increase the value of allowed watchers (depending on your available memory)
To figure out the current used amount of watchers, instead of only guessing, you can use this handy bash-script:
https://github.com/fatso83/dotfiles/blob/master/utils/scripts/inotify-consumers
I suggest to set the max_user_watches temporary to a high value:
sudo sysctl fs.inotify.max_user_watches=95524288 and run the script.
How to calculate how much you can use
Each watcher needs
540 bytes (32-bit system), or
1 kB (double - on 64-bit OS
So if you will allow to use 512MB (on 64Bit), you set something 524288 as value.
Other way around, you can take the amount of memory you will set, and multiply it by 1024.
Example:
512 * 1024 = 52488
1024 * 1024 = 1048576
It shows you the exact amount of the current used inotify-consumers. So you might have an better Idea, how much you should increase the limit.
If you are running your project in Docker, you should do the echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf and all other commands in the host machine, since the container will inherit that setting automatically (and doing it directly inside it will not work).
Late answer, and there are many good answers already.
In case you want a simple script to check if the maximum file watches is big enough, and if not, increase the limit, here it is:
#!/usr/bin/env bash
let current_watches=`sysctl -n fs.inotify.max_user_watches`
if (( current_watches < 80000 ))
then
echo "Current max_user_watches ${current_watches} is less than 80000."
else
echo "Current max_user_watches ${current_watches} is already equal to or greater than 80000."
exit 0
fi
if sudo sysctl -w fs.inotify.max_user_watches=80000 && sudo sysctl -p && echo fs.inotify.max_user_watches=80000 | sudo tee /etc/sysctl.d/10-user-watches.conf
then
echo "max_user_watches changed to 80000."
else
echo "Could not change max_user_watches."
exit 1
fi
The script increases the limit to 80000, but feel free to set a limit that you want.
As already pointed out by #snishalaka, you can increase the number of inotify watchers.
However, I think the default number is high enough and is only reached when processes are not cleaned up properly. Hence, I simply restarted my computer as proposed on a related github issue and the error message was gone.
Another simple and good solution is just to add this to jest configuration:
watchPathIgnorePatterns: ["<rootDir>/node_modules/", "<rootDir>/.git/"]
This ignores the specified directories to reduce the files being scanned
In my case in Angular 13, I added in tsconfig.spec.json
"exclude": [
"node_modules/",
".git/"
]
thanks #Antimatter it gaves me the trick.
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Run This Code In Project Terminal After Run Npm Run Dev
Please refer this link[1]. Visual Studio code has mentioned a brief explanation for this error message. I also encountered the same error. Adding the below parameter in the relavant file will fix this issue.
fs.inotify.max_user_watches=524288
[1] https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
While almost everyone suggests to increase a number of watchers, I couldn't agree that it is a solution.
In my case I wanted to disable watcher completely, because of the tests running on CI using vui-cli plugin which starts web-pack-dev server for each test.
The problem was: when a few builds are running simultaneously they would fail because watchers limit is reached.
First things first I've tried to add the following to the vue.config.js:
module.exports = {
devServer: {
hot: false,
liveReload: false
}
}
Ref.: https://github.com/vuejs/vue-cli/issues/4368#issuecomment-515532738
And it worked locally but not on CI (apparently it stopped working locally the next day as well for some ambiguous reason).
After investigating web-pack-dev server documentation I found this:
https://webpack.js.org/configuration/watch/#watch
And then this:
https://github.com/vuejs/vue-cli/issues/2725#issuecomment-646777425
Long story short this what eventually solved the problem:
vue.config.js
module.exports = {
publicPath: process.env.PUBLIC_PATH,
devServer: {
watchOptions: {
ignored: process.env.CI ? "./": null,
},
}
}
Vue version 2.6.14
if you working with vs code editor any editor that error due to large number of files in projects. node_modules and build not required in it so remove in list. that all open in vs code files menu
You have to filter unnecessary folders file sidebar
Goes to Code > Preferences > settings
in search setting search keyword "files:exclude"
Add pettern
**/node_modules
**/build
That's it
Try this , I was facing it for very long time but at the end it is solved by this,
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
The most important step after that is restart your system.
2 fixes if you've already added: fs.inotify.max_user_watches=524288
Reboot the machine, things will work again
Rename the folder that is causing the issue (for me node_modules) to an arbitrary name (node_modilesa) and then rename right back. This will remove the watches that linux had put on those folders. Allowing you code as normal again.
I encountered this issue on a linuxmint distro. It appeared to have happened when there was so many folders and subfolders/files I added to the /public folder in my app.
I applied this fix and it worked well...
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
change directory into the /etc folder:
cd /etc
then run this:
sudo systcl -p
You may have to close your terminal and npm start again to get it to work.
If this fails i recommend installing react-scripts globally and running your application directly with that.
$ npm i -g --save react-scripts
then instead of npm start run react-scripts start to run your application.
I tried increasing number as suggested but it didn't work.
I saw that when I login to my VM, it displayed "restart required"
I rebooted VM and it worked
sudo reboot
it is to easy to fix this
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
and run your project.
if there is fs.inotify.max_user_watches=524288 in your /etc/sysctl.conf,
run same command(echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf). and run your project
For vs code, see detailed instructions here:
https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc
Previously, I had the agent working properly, but after a recent power outage, I keep getting this issue.
I run puppet agent -t and get this error:
Error: Could not request certificate: Neither PUB key nor PRIV key: header too long
I've googled the issue, and it sounded like a clock issue (also suspected due to power outage). The time was off by 4 hours, but BIOS time seemed correct when I checked it. ntpdate didn't seem to work, so I synchronized them manually. Additionally, I've looked at the public and private keys after someone mentioned stray characters in their post, but haven't found anything of the sort.
Both master and agent are running Ubuntu, 15.04.
Fixed with help from Puppet IRC
rm -rf $ssldir ON THE AGENT; puppet cert clean $certname on the master
then puppet agent -t on the agent and get new certs
Due to corruption from power loss.
I had the exact same error, but only removing the ssl directory wan't enough for me... but this fixed it:
apt-get purge puppet puppet-common puppetlabs-release hiera facter
rm -rf /var/lib/puppet /etc/puppet
apt-get purge augeas-lenses libaugeas-ruby libaugeas0 ruby-augeas ruby-json ruby-shadow virt-what
Then reinstall it. This puppet agent is version 3.8.7 on Ubuntu 14.04.
Also just the first purge line and rm -rf ... didn't fix it alone. I guess some file got corrupted (although the disks were never replaced and look fine, and it has ECC RAM) or something was generated and was wrong due to some bugs.
In my case the issues was was from lack of disk space on master and cert on master that needed to be deleted from /etc/puppetlabs/puppet/ssl/ca/requests
Redis went quite on me.
user#mycomputer:~$ redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
I try to restart the service by doing this
sudo /etc/init.d/redis_6379 stop
/var/run/redis/redis.pid exists, process is already running or crashed
But no luck. Logs didn't show an error as well.
Got it fixed by backing up the redis.rdp file mine is located at
/var/lib/redis
check your config file "/etc/redis/redis.conf" for the rdp file's location and do this
sudo mv /var/lib/redis/redis.rdp /var/lib/redis/redis_backup.rdp
Then recreate the the redis.rdp file
sudo touch redis.rdp
Run the redis-server with the conf and it should work
sudo redis-server /etc/redis/redis.conf
Get it fixed in a tidy way: Recreate the the redis.rdp file as suggested here in one of answer, will purge all the cache recorded so far and redis will start up fresh with no cache data.
This is a warning message to notify system crash / improper shutdown: "/var/run/redis/redis.pid exists, process is already running or crashed"
Just delete /var/run/redis/redis.pid file and restart the server again.
Note: You might have lost latest cache changes due to untidy shutdown, which weren't flushed into the disk. This data loss can be minimized using frequent disk flush configuration in redis conf file(in my case it is #/etc/redis/6379.conf)
save 900 1
save 300 10
save 60 10000
Or try AOF persistence, more details [here][1]
Depends on how you installed redis, the pid can be found on /var/run/redis_6379.pid.
What happened is that redis crashed, but the pid is still there. So you just have to delete it.
sudo rm -f /var/run/redis_6379.pid
Then start redis again:
sudo /etc/init.d/redis_6379 start
If you can't find it, I suggest installing redis "more properly". Follow redis quickstart guide in the Installing Redis more properly section.
You can find it here:
https://redis.io/topics/quickstart
Run the redis-server with config.
sudo redis-server redis.conf
I have installed rabbitmq on ubuntu and trying to start it using rabbitmq-server start, however, I'm getting this error:
Activating RabbitMQ plugins ...
0 plugins activated:
node with name "rabbit" already running on "mybox"
diagnostics:
- nodes and their ports on mybox: [{rabbit,38618},
{rabbitmqprelaunch13346,41776}]
- current node: rabbitmqprelaunch13346#mybox
- current node home dir: /var/lib/rabbitmq
- current node cookie hash: 8QRKGluOJOcZ4AAkEdFwQg==
so I try to stop it or restart it using service rabbitmq-server restart but I get the following error: Restarting rabbitmq-server: RabbitMQ is not running
The server's host name hostname -s is mybox.
How do I stop the currently running instance, or at least, how do I manage it? I have no access to it and yet I'm not able to run rabbitmq properly.
Thank you.
Rabbitmq is set to start automatically after it's installed.
I don't think it is configured run with the service command.
To see the status of rabbitmq
sudo rabbitmqctl status
To stop the rabbitmq
sudo rabbitmqctl stop
(Try the status command again to see that it's stopped).
To start it again, the recommended method is
sudo invoke-rc.d rabbitmq-server start
These all work with the vanilla ubuntu install using apt-get
Still not working?
If you've tried unsuccessfully to start or restart rabbitmq, check to see how many processes are running.
ps -ef | grep rabbit
There should be 5 processes running as the user rabbitmq.
If you have more, particularly if they're running as other users (such as root, or your own user) you should stop these processes.
The cleanest way is probably to reboot your machine.
rabbitmq-server refuses to start if the hostname -s value has changed.
The solution suggested here is only for test/development environments.
I had to delete the database to fix it locally.
i.e empty folder /var/lib/rabbitmq (ubuntu) or /usr/local/var/lib/rabbitmq/(mac)
I had similar problem but these suggestions didn't work for me(restart too). When I run rabbitmq-server command, I get a response like that:
$/ rabbitmq-server
BOOT FAILED
===========
Error description:
{error,{cannot_log_to_file,"/var/log/rabbitmq/rabbit#haber01.log",
{error,eacces}}}
....
When I checked permissions of /var/log/rabbitmq/rabbit#haber01.log file, I saw that group has not write permisson for that file. So I gave permission to group with that command:
/var/log/rabbigmq/$ chmod g+w *
then problem has gone!
Maybe this answer help someone.
Seems like the Mnesia database was corrupted. Had to delete it to get sudo service rabbitmq-server start going again !
$ sudo rm -rf /var/lib/rabbitmq/mnesia/
Also make sure that any stray rabbit processes are killed before clearing out
$ ps auxww | grep rabbit | awk '{print $2}' | sudo xargs kill -9
And then
$ sudo service rabbitmq-server start
If you use celery, your queues could reach max size and rabbit won't start because of that. Maybe you wouldn't even able to use rabbitmqctl, so if you can afford to clean the queues, just remove
/var/lib/rabbitmq/mnesia/rabbit#<host>/queues
on unix (look for mnesia DB path on your system).
Be careful: this will remove everything you have in rabbit, so this is a last solution ever.
Have a look what is in the log of the node that you are trying to start. It will be in /var/log/rabbitmq/
It was selinux in my case, rabbit could not bind to its ports.
My brew version of rabbitmq refused to start (after working fine for years without modification by me) too.
$ cat /usr/local/etc/rabbitmq/rabbitmq-env.conf
CONFIG_FILE=/usr/local/etc/rabbitmq/rabbitmq
NODE_IP_ADDRESS=127.0.0.1
NODENAME=rabbit#localhost
RABBITMQ_LOG_BASE=/usr/local/var/log/rabbitmq
I edited out rabbit# on NODENAME and brew services restart rabbitmq started working again.
If the standard stop and start are not working, list the rabbitmq processes that are running using
ps aux | grep rabbitmq
Kill the beam.smp process using
kill -9 {process id}
and start the rabbitmq-server again.