I'm getting the following issue when I do
rabbitmq-server
I'm running on mac os x. rabbitmq version 3.5.4.
I tried to uninstall and reinstall rabbitmq without issues with brew, but end up here with the following error every time. Guidance is appreciated.
Thanks for the help!
BOOT FAILED
===========
Error description:
{could_not_back_up_mnesia_dir,{"/usr/local/var/lib/rabbitmq/mnesia/rabbit#localhost",
"/usr/local/var/lib/rabbitmq/mnesia/rabbit#localhost-upgrade-backup",
eacces}}
Log files (may contain more information):
/usr/local/var/log/rabbitmq/rabbit#localhost.log
/usr/local/var/log/rabbitmq/rabbit#localhost-sasl.log
Stack trace:
[{rabbit_upgrade,take_backup,0,
[{file,"src/rabbit_upgrade.erl"},{line,111}]},
{rabbit_upgrade,ensure_backup_taken,0,
[{file,"src/rabbit_upgrade.erl"},{line,100}]},
{rabbit_upgrade,maybe_upgrade_mnesia,0,
[{file,"src/rabbit_upgrade.erl"},{line,142}]},
{rabbit,'-boot/0-fun-0-',0,[{file,"src/rabbit.erl"},{line,328}]},
{rabbit,start_it,1,[{file,"src/rabbit.erl"},{line,353}]},
{init,start_it,1,[]},
{init,start_em,1,[]}]
{"init terminating in do_boot",{could_not_back_up_mnesia_dir,{"/usr/local/var/lib/rabbitmq/mnesia/rabbit#localhost","/usr/local/var/lib/rabbitmq/mnesia/rabbit#localhost-upgrade-backup",eacces}}}
init terminating in do_boot ()
eacces is a permission problem.
Try to execute it using sudo rabbitmq-server
Edit
RabbitMQ does not need the sudo rights.
The default folders where RMQ writes (in this case) need the sudo rights.
But you can overload the default folders reading the documentation.
I usually override this:
export RABBITMQ_PID_FILE=/Users/gabriele/programs/rabbitmq_server-3.5.4/data/rmq.pid
export RABBITMQ_BASE=/Users/gabriele/programs/rabbitmq_server-3.5.4
export RABBITMQ_LOG_BASE=/Users/gabriele/programs/rabbitmq_server-3.5.4/data/logs
export RABBITMQ_MNESIA_BASE=/Users/gabriele/programs/rabbitmq_server-3.5.4/data/db
export RABBITMQ_PLUGINS_DIR=/Users/gabriele/programs/rabbitmq_server-3.5.4/plugins
export RABBITMQ_PLUGINS_EXPAND_DIR=/Users/gabriele/programs/rabbitmq_server-3.5.4/plugins/expands
export RABBITMQ_ENABLED_PLUGINS_FILE=/Users/gabriele/programs/rabbitmq_server-3.5.4/enabled_plugin
and I don't need to use sudo
Please read this https://www.rabbitmq.com/relocate.html for more info about.
Related
(I have seen other solutions to "Errno 48" issues on StackOverflow, but none have been successful yet.)
I am trying to develop a botnet using byob on github here: https://github.com/malwaredllc/byob
I am encountering a address in use error every time I run the command sudo ./startup.sh. It returns OSError: [Errno 48] Address already in use.
However when I attempt to use the ps -fA | grep python and kill the associated 502 18126 16973 0 9:16PM ttys000 0:00.00 grep python by using kill -9 181216, I get this error: kill: kill 18126 failed: no such process.
Does anyone have any idea what to do?
I am using a "MacOS M1Pro Chip OS V12.0.1 Monterey". Also the program byob is trying to run on port 5000 of IPv4 127.0.0.1 (this is a generic IP not specifically mine). http://127.0.0.1/5000.
In case you try to duplicate the problem you need to install docker.io or the docker desktop app depending on os then navigate to cd <outer-dir>/byob-master/web-gui then execute sudo ./startup.sh. The code will not work without access to docker, and the program needs to be ran with admin perms using the prefix sudo. The actual downloads take a while and it will prompt you to restart once. Then when you run it again, I encounter this problem...
Please let me know if someone was able to fix this. Thanks!
I'm attempting to learn how to create a Laravel Docker image by following a tutorial on DigitalOcean using WSL. Following the instructions on the Docker Hub page, however, yields an error:
❯ docker run --rm --interactive --tty -v $(pwd):/app composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 94 installs, 0 updates, 0 removals
- Installing voku/portable-ascii (1.4.10): Failed to download voku/portable-ascii from dist: Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
Now trying to download from source
- Installing voku/portable-ascii (1.4.10):
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...
How can I diagnose what I'm doing wrong?
It turns out that the underlying problem had nothing to do with Docker at all. In fact, Composer was trying to tell me what the problem was all along, but I dismissed it as just a symptom of a deeper issue:
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
This message was the crux of it all. I noticed that the directory mentioned, [...]/helper, was empty, so I tried to remove it by hand with rmdir. Instead, I got a No such file or directory error message. I attempted many other was to kill this directory, the entire project directory with rm -rf ~/laravel-app from the home folder, etc. Nothing worked.
Some digging around on the internet suggested that it could be an NTFS corruption if I was running into this issue on Windows. Since I am, indeed, attempting this on WSL (Windows Subsystem for Linux), I gave their suggested fix a try: running chkdsk /F in CMD/PowerShell. A reboot was necessary to complete this task, but after getting everything back up and trying those first few tutorial steps again, I was able to get composer to install the Laravel dependencies without a hitch.
Bottom line: If you run into this sort of issue on WSL, please try running chkdsk /F and reboot. You might just have a similar file system corruption.
We have two possibilities for this error:
1 - You did not execute the command inside the directory :
cd ~/laravel-app
2 - I'm sure there is an internal proxy that is blocking the download of packages.
I am getting the following error while running my rails app in Ubuntu server
FATAL: Listen error: unable to monitor directories for changes. Visit
https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers
for info on how to fix this.
I have followed the above GitHub page, but I was unable to write in max_user_watches which were set in 8192 and I want to set that to 524288.
in cat /proc/sys/fs/inotify/max_user_watches the file was in only read mode.I tried to grant write permissions, but I was getting permission denied error even with root access.
Thanks in Advance!!!
1000 is way too small, try with 524288 as explained in the wiki page: https://github.com/guard/listen/blob/master/README.md#increasing-the-amount-of-inotify-watchers
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.
and
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
Just try to execute this from your console
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Hope this will work for you .
References: click here
For others who may have this issue. I had a VM disconnect which left the previous rails server running. Running below resolved the issue without needing to up the number of watcher.
kill -9 $(lsof -i tcp:3000 -t)
In my case, I just need to turn off the terminal and then start it back again. It works when I try to run rails c command :)
Deleting Gemfile.lock and running 'bundle' in the project directory terminal worked for me.
This error occurred for me as I had a number of ruby processes currently running that I was unaware of. Just need to terminate them and all is good
I had this issue during development while running rake (even with rake -h), and the solution from https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers did not work, neither did killing the running ruby processes, killing the terminal or even restarting the computer.
To avoid this error I did a new and clean clone of my project and then rake was working (maybe git clean -fdx could have worked but I did not try it).
I was running rake version 13.0.3, rails 6.1.1, ruby 2.7.2p137.
Adding to #mayur-shah's answer,
It worked for me after closing the server and console. So, if you are running rails server/console, close that first.
After upgrading my macOS to Sierra, when I start Jenkins using launchctl load I cannot connect to localhost:8080. If I call launchctl load again, I see response "service already loaded". There is no log file at the default location /var/log/jenkins/ (as set in jenkins-ci.plist). I also tried to create jenkins.log there and chown to jenkins user, but still nothing is printed there.
If I try to start Jenkins using java -jar jenkins.war, I can connect to localhost, but Jenkins runs as a new installation.
I have the latest JRE 1.8.0_102 installed.
How to diagnose the problem?
Seems that Sierra changed the permission of Jenkis folder. So the best solution is:
1. Add execute permissions to org.jenkins-ci.plist:
sudo chmod +x /Library/LaunchDaemons/org.jenkins-ci.plist
2. Set jenkins as the owner of /var/log/jenkins:
sudo chown jenkins /var/log/jenkins
3. Start Jenkins:
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
This happened to me when I upgraded to Sierra and I managed to solve it with the answer from #mac.slusarek . But it happened again recently. This time I had allowed a minor update of the OS and I had also been playing around with SDK Man to switch JDK's. Not sure which one broke my Jenkins but this time around it was not a permissions issue.
I noticed from the logs Jenkins was trying to run on Java 9-ea, which is apparently not supported yet. I had installed Jenkins using the Jenkins installer for Mac, so tried uninstalling:
/Library/Application\ Support/Jenkins/Uninstall.command
and installing again but the issue didn't go away.
Then I found this article suggesting to instead install it using Homebrew. It was as easy as running:
$brew install jenkins
Since I only run it locally for development I don't need to start it as a daemon, so now I just run it by typing
$jenkins
Problem solved. I hope this helps others.
I fixed it by setting the appropriate JAVA_HOME variable. The way I diagnosed it was to look at the errors that were thrown as Jenkins was trying to run:
tail -f /var/log/jenkins/jenkins.log
Then I tried to run it:
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist
If it says it's already loaded, unload it first:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
Then run it:
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist
The error I saw was that Jenkins needed Java 8, not Java 10. So I unloaded:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
and then installed Java 8. Then I edited the plist file:
sudo nano /Library/LaunchDaemons/org.jenkins-ci.plist
and added the appropriate JAVA_HOME environment variable:
<dict>
<key>JENKINS_HOME</key>
<string>/Users/Shared/Jenkins/Home</string>
<key>JAVA_HOME</key>
<string>/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home</string>
</dict>
Finally, I tried the launchctl command again:
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist
and voilà!
I had the same issue, installing the JDK didn't made the trick
However changing the rights of the log directory (in my case /var/log/jenkins) and restarting Jenkins worked.
Seems that moving to Sierra changed the rights on this folder.
In my case, the install on Catalina (OSX 10.15) somehow didn't even create the /var/log/jenkins file. I had to
sudo mkdir /var/log/jenkins
and then take ownership and then Jenkins started normally. Just did the normal OSX installer so not sure why the install was corrupt.
As I mentioned in the question, I had JRE installed. After I installed JDK, Jenkins is able to start normally.
This same thing happened to me when I upgraded from Sierra to High Sierra. I followed the instructions outlined above by mac.slusarek, however the jenkins ID no longer existed on my computer. I created the jenkins id as a Standard user.
Also, the files under /Users/Shared/Jenkins were no longer owned by jenkins. After I cat out the error log with the command:
sudo cat /var/log/jenkins/jenkins.log
After seeing the error:
Exception in thread "main" java.io.IOException: Jenkins has failed to create a
temporary file in /Users/Shared/Jenkins/tmp
at Main.extractFromJar(Main.java:368)
at Main._main(Main.java:210)
at Main.main(Main.java:112)
Caused by: java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at Main.extractFromJar(Main.java:365)
... 2 more
I fixed the ownership with the command:
sudo chown -R jenkins /Users/Shared/Jenkins
I had the same problem.
I manually enabled the read + write access to the
/Users/Shared/Jenkins
Folder.
I was facing issue in loading jenkins-cli.plist command on my MacOs(Mojave version).
Mac Version : Mojave 10.14.6
Jenkins Version : 2.190.1
I installed jenkins using .pkg file.
Reference link : https://java2blog.com/install-jenkins-mac-os-x/
When executing below command,
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
I was facing error saying "already loaded".
Solution:
step 1. Check jenkins logs for exact error.
tail -f /var/log/jenkins/jenkins.log
(In my case, it was port binding issue, port 8080 was already being used by some other application)
step 2. So I decided to start jenkins on some other port (say 7070).You can do this by using below commands.
sudo defaults write /Library/Preferences/org.jenkins-ci.plist httpPort 7070
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
step 3. Try to access it in browser, http://localhost:7070. It should work!!
I am trying to run the following command
rabbitmq-plugins.bat enable rabbitmq_management
and its giving me an error like this:
11:36:55.464 [error] Failed to create cookie file 'h:/.erlang.cookie': enoent
I am using windows 7, Erlang Version R16B01 and RabbitMQ-Server version 3.1.5
I am using my work PC and our Corporate policy sets the HOMEDRIVE to h: and HOMEPATH to /
and i dont think they will let me change this.
I can see the .erlang.cookie file under C:\Windows.
Could someone let me know of a workaround for this ?
Thanks in advance !
Had the same H: problem. Set the home drive to some dir in the dos shell before executing the cli.
set HOMEDRIVE=C:/conf/rabbitmq :: Or your favorite dir
rabbitmq-plugins.bat enable rabbitmq_management
Use a folder in C drive. The rabbitmq system will write the cookie file there.
I solved the problem by following the steps below:
Open the file: "Program Files/RabbitMQ Server/rabbitmq_server-/sbin/rabbitmq-env"
At the end of the file, append the line:
REM Environment cleanup
set BOOT_MODULE=
set CONFIG_FILE=
set FEATURE_FLAGS_FILE=
set ENABLED_PLUGINS_FILE=
set LOG_BASE=
set MNESIA_BASE=
set PLUGINS_DIR=
set SCRIPT_DIR=
set SCRIPT_NAME=
set TDP0=
set HOMEDRIVE=C: <<< the new path of the .erlang.cookie
Open the RabbitMQ console
write:
4.1. rabbitmq-service stop
4.2. rabbitmq-service remove
4.3. rabbitmq-service install
4.4. rabbitmq-service start
Find location of ".erlang.cookie" in your PC and run the commands bellow:
set HOMEDRIVE=[location of ".erlang.cookie"]
rabbitmq-plugins.bat enable rabbitmq_management
There are cases when your HOMEDRIVE and HOMEPATH get overridden by group policy (active directory user) and than you'll need to set your HOMEDRIVE variable each time you want to start RabbitMQ service. In this case what you can do is:
rabbitmq-service remove service
edit rabbitmq-service.bat file:
"!ERLANG_HOME!\bin\erl.exe" ^
-pa "!RABBITMQ_EBIN_ROOT!" ^
-boot !CLEAN_BOOT_FILE! ^
-noinput -hidden ^
-s rabbit_prelaunch ^
-setcookie "C:\Users\userName\" ^ <<< this is a place of your cookie
!RABBITMQ_NAME_TYPE! rabbitmqprelaunch!RANDOM!!TIME:~9!#localhost ^
-conf_advanced "!RABBITMQ_ADVANCED_CONFIG_FILE!" ^
..."
save the script
set HOMEDRIVE=C:\Users\userName change homedrive before installing service
rabbitmq-service install reinstall the service
now each time your reboot your service starts automatically and all paths are OK!
While this may seem totally obvious, you do need to run cmd "as administrator" - I was getting the above error until I remedied that. :-)
We had the same issue where group policies have set HOMEDRIVE to h: and HOMEPATH to /.
None of the other solutions here worked (even though we have seen that modifying the sys vars did work for us in a different environment).
Today we solved this by creating a new local Administrator account and installing from there.
I got the same error for Z:/ drive which didn't exist on my system. On checking %HOMEDRIVE%, it was mapped to Z:/.
The solution that worked for me was to execute below commands in CMD/Powershell(Admin mode).
mkdir c:/home
net use z: /delete <<--- This might fail as drive z:/ doesn't exist. Just ignore it.
subst z: c:/home