autofs not working on Ubuntu 14.04 - init.d

Hi I am trying to automount remote file system using autofs. For this I installed autofs
% sudo apt-get install cifs-utils autofs
Then I edited /etc/auto.master to have the following line:
/ufs /etc/auto.ufs
Then I created a file /etc/auto.ufs and edited it with the following line:
cad -rw,soft,intr,rsize=8192,wsize=8192 fiji.csl.cornell.edu:/usr/local/cad
Then I restarted autofs using:
sudo /etc/init.d/autofs restart
and I got following message:
Stopping automount... [ OK ]
Starting automount...
/usr/sbin/automount: program is already running.
[ OK ]
But still when I try to do ls in the /ufs folder it does not show anything. Can somebody tell what could be the issue?

Related

xampp installed in ubuntu but php and mysql shows not found

I have installed XAMPP version 7.4 in UBUNTU OS,
now when I go to the terminal and type php -v command,
it shows
root#roy:/opt/lampp/htdocs/magento242# php -v
Command 'php' not found, but can be installed with:
apt install php7.4-cli
also when i type mysql -u root -p it shows like below,
root#roy:/opt/lampp/htdocs/magento242# sudo mysql -u root -p
sudo: mysql: command not found
root#roy:/opt/lampp/htdocs/magento242# mysql -u root -p
Command 'mysql' not found, but can be installed with:
apt install mysql-client-core-8.0 # version 8.0.23-0ubuntu0.20.04.1, or
apt install mariadb-client-core-10.3 # version 1:10.3.25-0ubuntu0.20.04.1
I don't understand that what is the problem exactly.
but when I run localhost/phpmyadmin then phpmyadmin is open.
so what is the problem with that?
please provide me some suggestions on that,
thanks.
You need to start Lampp first then mysql. Follow these steps:
Open up terminal using CTRL+ALT+T
type
sudo /opt/lampp/lampp start
3.Switch to the XAMPP installation directory. Type in
cd /opt/lampp
4.Then you just need to type this command in order to run lampp properly
sudo ./manager-linux-x64.run
if you need to use mysql in terminal do the next step
5.cd /opt/lampp/bin
./mysql -u root

Supervisor no such file socket.py

I am trying to setup a queue listener for laravel and cannot seem to get supervisor working correctly. I get the following error when I run supervisorctl reload:
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 228
The file DOES exist. If try to run sudo supervisorctl I get this
unix:///var/run/supervisor.sock no such file.
I've tried reinstall supervisor and that did not work either. Not sure what to do here.
I'm running Laravel Homestead (Ubuntu 16.04).
Result of service supervisor status:
vagrant#homestead:~/Code$ sudo service supervisor status
● supervisor.service - Supervisor process control system for UNIX
Loaded: loaded (/lib/systemd/system/supervisor.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2016-12-22 11:06:21 EST; 41s ago
Docs: http://supervisord.org
Process: 23154 ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown (code=exited, status=0/SUCCESS)
Process: 23149 ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf (code=exited, status=2)
Main PID: 23149 (code=exited, status=2)
You should run sudo service supervisor start when you are in the supervisor dir.
Worked for me.
2020 UPDATE
Try running sudo service supervisor start in your terminal before using the below solution. I found out that the issue sometimes occurs when supervisor is not running, nothing complicated.
I am using Ubuntu 18.04. I had the same problem and re-installing supervisor did not solve my problem.
I ended up completely removing the conf.d directory and recreating it with new configs. Make sure you back up your configurations before trying this:
sudo rm -rf /etc/supervisor/conf.d/
sudo mkdir /etc/supervisor/conf.d
sudo nano /etc/supervisor/conf.d/my-file.conf
Copy+Paste your configuration into your new file.
sudo supervisorctl reread started working again.
In Ubuntu 18.04 with distribution's package
You probably did the same mistake as me an created the config file /etc/supervisord.conf while my service manager (systemd) was using the config file /etc/supervisor/supervisord.conf
Solutions
Remove the config file created
sudo rm /etc/supervisord.conf
Move it to the correct location
sudo mv /etc/supervisord.conf /etc/supervisor/supervisord.conf
Now you can run sudo supervisorctl
Why?
when you run supervisorctl it first searches for the config file located at /etc/supervisord.conf, if it's not present, it will search for the package's default file /etc/supervisor/supervisord.conf this is the one systemd actually runs.
Systemd always use the file /etc/supervisor/supervisord.conf regardless of the other file's existence.
You can check which file is using systemd by running sudo systemctl status supervisor
You can see in the last line the command where the config file is hardcoded
I had a very similar problem (Ubuntu 18.04) and searched similar threads to no avail so answering here with some more comprehensive answers.
Lack of a sock file or socket error is only an indicator that supervisor is not running. If a simple restart doesn't work its either 1. not installed, or 2. failing to start. In my case nothing was being logged to the supervisor.log file for me to know why it was failing until I ran the following command (-n to run in foreground) only to find out that there was a leftover configuration file for a project that had been deleted that I missed.
/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
Once I deleted the bad/leftover file in the conf.d folder and started it back up with sudo service supervisor start everything worked.
Here are some comprehensive steps you can take.
Is supervisor installed? dpkg -l | grep supervisor If not reinstall sudo apt install supervisor
Are all instances of supervisor stopped? systemctl stop supervisor Lingering supervisor processes can be found ps aux | grep supervisor then kill -9 PID.
Is supervisor.conf in the right location /etc/supervisor/supervisor.conf and there are no syntax errors? Reinstall from package would correct this.
Move your specific files in conf.d/ temporarily out of the folder to try and start with no additional config files. If it starts right up sudo service supervisor start the likelihood of an error in your project .conf file exists.
Check status with sudo service supervisor status.
Move your .conf files one by one back into conf.d/ and restart sudo service supervisor restart. Be sure to check with sudo service supervisor status between. If it fails you know which .conf file has an issue and can ask for specific help.
check everything is running with supervisorctl status and if not start with supervisorctl start all.
None of about answers helped me.
the problem was i didn't follow supervisor documentation.
and a step i didn't do was run echo_supervisord_conf command that makes the configuration file.
Steps i did for Ubuntu 18.04:
Installing supervisor (without pip):
sudo apt-get install supervisor
echo_supervisord_conf > /etc/supervisord.conf (with root access: first run sudo -i then echo_supervisord_conf > /etc/supervisord.conf)
change python dependency to python2
(Depends: python-pkg-resources, init-system-helpers (>= 1.18~), python-meld3, python:any (<< 2.8), python:any (>= 2.7.5-5~)
in these files: /usr/bin/supervisord | /usr/bin/supervisorctl | /usr/bin/echo_supervisord_conf.
Just change the first line from #!/usr/bin/python to #!/usr/bin/python2
run supervisord
Finish
hope help !
Facing the python file not found an error, code=exited, status=2 once I try with the official document but still same.
I have tried so many solutions for my laravel application.
But at last, I have tried with my solution.
Here is an example for the code :
[program:dev-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/example.com/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
user=ubuntu
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/html/example.com/storage/logs/laravel.log
stopwaitsecs=3600
Ref: https://laravel.com/docs/7.x/queues#supervisor-configuration
I ended up just removing supervisor entirely, reinstalling and rewriting my config files. I must have just done something wrong in the process and wasn't able to catch it.
You can try by removing all of the related folder of supervisor & uninstall supervisor completely.
sudo rm -rf /var/log/supervisor/supervisord.log
sudo rm -rf /etc/supervisor/conf.d/
After doing this, reinstall supervisor by
sudo apt install supervisor
Now, you can run correctly. Check with
sudo systemctl status supervisor
If by running sudo service supervisor status you get the following:
ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf (code=exited, status=2)
Try running /usr/bin/supervisord, it will give you clear message to tell you where the error is.
On Centos 7 I use the following...
supervisord -c /path/to/supervisord.conf
followed by...
supervisorctl -c /path/to/supervisord.conf
This gets rid of the ".sock file not found" error. Now you have to kill old processes using...
ps aux|grep gunicorn
Kill the offending processes using...
kill <pid>
Then again...
supervisorctl -c /path/to/supervisord.conf
Supervisor should now be running properly if your config is good.
Check the supervisord.conf file.
Look for the following:
[unix_http_server]
file=/path/to/supervisor.sock/file ; (the path to the socket file)
chmod=0700 ; sockef file mode(default 0700)
Go to the path mentioned above and check if the file is present.
If it is present then try re-installing supervisor.
If not then search for supervisor.sock file either using the command line or file explorer GUI.
Copy the file found in the above step to the location specified in the [unix_http_server] by using the cp command or GUI.
For me, the supervisor.sock was present in the /run folder.
you can try
sudo touch /var/run/supervisor.sock
sudo chmod 777 /var/run/supervisor.sock
I ran into this issue because we were using supervisorctl to manage gunicorn. The root of my problem had nothing to do with supervisor (it was handling other processes just fine) or the python sock.py file (file was there, permissions were correct), but rather the gunicorn config file /etc/supervisor/conf.d/gunicorn.conf. This configuration file was managed by a source-controlled template with environment variables and when we updated the template on the server, the template variables were never replaced with the actual data. So for example something in the gunicorn.conf file read user={{ user }} instead of user=gunicorn. When supervisor tried to parse this config when running supervisorctl start gunicorn it would crash with this socket error. Repairing the gunicorn.conf file resolved the supervisor issue.
Source of answer : http://supervisord.org/installing.html
Run command : echo_supervisord_conf
Once you see the file echoed to your terminal, reinvoke the command as echo_supervisord_conf > /etc/supervisord.conf. This won’t work if you do not have root access.
If you don’t have root access, or you’d rather not put the supervisord.conf file in /etc/supervisord.conf, you can place it in the current directory (echo_supervisord_conf > supervisord.conf) and start supervisord with the -c flag in order to specify the configuration file location.
The error should've been resolved by now.
I did the following to solve the issue on CentOS Linux 7
sudo systemctl status supervisord.service
With the above command, I realise that the program was in active
sudo systemctl start supervisord.service
Now I use the command above to start the service and everything works well now

VirtualBox: mount.vboxsf: mounting failed with the error: No such device [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I'm using VirtualBox with OS X as host and CentOS on the guest VM.
In OS X I created folder myfolder, added it as shared folder to the VM, turned on the VM, in CentOS created folder /home/user/myfolder and typing:
sudo mount -t vboxsf myfolder /home/user/myfolder
and have output:
/sbin/mount.vboxsf: mounting failed with the error: No such device
What I'm doing wrong?
UPDATED:
Guest Additions installed.
My shared folder/clipboard stopped to work for some reason (probably due to a patch installation on my virtual machine).
sudo mount -t vboxsf Shared_Folder ~/SF/
Gave following result:
VirtualBox: mount.vboxsf: mounting failed with the error: No such device
The solution for me was to stop vboxadd and do a setup after that:
cd /opt/VBoxGuestAdditions-*/init
sudo ./vboxadd setup
You're using share folders, so you need to install VirtualBox Guest Additions inside your virtual machine to support that feature.
Vagrant
If you're using Vagrant (OS X: brew cask install vagrant), run:
vagrant plugin install vagrant-vbguest
vagrant vbguest
In case it fails, check the logs, e.g.
vagrant ssh -c "cat /var/log/vboxadd-install.log"
Maybe you're just missing the kernel header files.
VM
Inside VM, you should install Guest Additions, kernel headers and start the service and double check if kernel extension is running.
This depends on the guest operating system, so here are brief steps:
Install kernel include headers (required by VBoxLinuxAdditions).
RHEL: sudo apt-get update && sudo apt-get install kernel-devel
CentOS: sudo yum update && sudo yum -y install kernel-headers kernel-devel
Install Guest Additions (this depends on the operating system).
Ubuntu: sudo apt-get -y install dkms build-essential linux-headers-$(uname -r) virtualbox-guest-additions-iso
If you can't find it, check by aptitude search virtualbox.
Debian: sudo apt-get -y install build-essential module-assistant virtualbox-ose-guest-utils
If you can't find it, check by dpkg -l | grep virtualbox.
manually by downloading the iso file inside VM (e.g. wget) and installing it, e.g.
wget http://download.virtualbox.org/virtualbox/5.0.16/VBoxGuestAdditions_5.0.16.iso -P /tmp
sudo mount -o loop /tmp/VBoxGuestAdditions_5.0.16.iso /mnt
sudo sh -x /mnt/VBoxLinuxAdditions.run # --keep
Extra debug: cd ~/install && sh -x ./install.sh /mnt/VBoxLinuxAdditions.run
Double check that kernel extensions are up and running:
sudo modprobe vboxsf
Start/restart the service:
manually: sudo /opt/VBoxGuestAdditions*/init/vboxadd setup (add sudo sh -x to debug)
Debian: sudo /etc/init.d/vboxadd-service start
Fedora: sudo /etc/init.d/vboxdrv setup
CentOS: sudo service VBoxService start
Building the main Guest Additions module
If above didn't work, here are more sophisticated steps to fix it. This assumes that you've already VBoxGuestAdditions installed (as shown above).
The most common reason why mounting shared folder doesn't work may related to building Guest Additions module which failed. If in /var/log/vboxadd-install.log you've the following error:
The headers for the current running kernel were not found.
this means either you didn't install kernel sources, or they cannot be found.
If you installed them already as instructed above, run this command:
$ sudo sh -x /opt/VBoxGuestAdditions-5.0.16/init/vboxadd setup 2>&1 | grep KERN
+ KERN_VER=2.6.32-573.18.1.el6.x86_64
+ KERN_DIR=/lib/modules/2.6.32-573.18.1.el6.x86_64/build
So basically vboxadd script is expecting your kernel sources to be available at the following dir:
ls -la /lib/modules/$(uname -r)/build
Check if the kernel dir exists (symbolic link points to the existing folder). If it's not, please install them to the right folder (e.g. in /usr/src/kernels).
So vboxadd script can enter your kernel source directory and run make kernelrelease, get the value and compare with your current kernel version.
Here is the logic:
KERN_VER=`uname -r`
KERN_DIR="/lib/modules/$KERN_VER/build"
if [ -d "$KERN_DIR" ]; then
KERN_REL=`make -sC $KERN_DIR --no-print-directory kernelrelease 2>/dev/null || true`
if [ -z "$KERN_REL" -o "x$KERN_REL" = "x$KERN_VER" ]; then
return 0
fi
fi
If the kernel version doesn't match with the sources, maybe you've to upgrade your Linux kernel (in case the sources are newer than your kernel).
CentOS
Try:
vagrant plugin install vagrant-vbguest vagrant vbgues
If won't work, try the following manual steps for CentOS:
$ sudo yum update
$ sudo yum install kernel-$(uname -r) kernel-devel kernel-headers # or: reinstall
$ rpm -qf /lib/modules/$(uname -r)/build
kernel-2.6.32-573.18.1.el6.x86_64
$ ls -la /lib/modules/$(uname -r)/build
$ sudo reboot # and re-login
$ sudo ln -sv /usr/src/kernels/$(uname -r) /lib/modules/$(uname -r)/build
$ sudo /opt/VBoxGuestAdditions-*/init/vboxadd setup
I am able to resolved this by running below commmand
modprobe -a vboxguest vboxsf vboxvideo
In addition to #Mats answer, I'm adding some more info (it helped me on Debian 8).
My shared folder/clipboard stopped to work for some reason (probably due to a patch installation on my virtual machine).
sudo mount -t vboxsf Shared_Folder ~/SF/
Gave me following result:
VirtualBox: mount.vboxsf: mounting failed with the error: No such device
The solution for me was to stop vboxadd and do a setup after that:
cd /opt/VBoxGuestAdditions-*/init
sudo ./vboxadd setup
At this point, if you still get the following error:
No such device. The Guest Additions installation may have failed. The error has been logged in /var/log/vboxadd-install.log
You need to install linux headers:
apt-get install linux-headers-$(uname -r)
then you can install Guest Additions:
sh /media/cdrom/VBoxLinuxAdditions.run --nox11
and restart your Linux by:
reboot
then you will be able to mount your shared folder!
mount -t vboxsf Shared_Folder ~/SF/
More informations (in French), check this page.
This was the only solution what worked for me:
Install Vagrant plugin: vagrant-vbguest, which can keep your VirtualBox Guest Additions up to date.
vagrant plugin install vagrant-vbguest
Source: https://github.com/aidanns/vagrant-reload/issues/4#issuecomment-230134083
This was resolved by:
yum install gcc kernel-devel make
workaround is here: https://gist.github.com/larsar/1687725
Shared folder was earlier working for me but all f sudden it stopped working (Virualbox - host was Windows 7, Guest was OpenSuSe)
modprobe -a vboxguest vboxsf vboxvideo
then
mount -t vboxsf testsf /opt/tsf (testsf was the folder in Windows C drive which was added in Virtualbox shared folder --- and /opt/tsf is the folder in OpenSuse
My host is Windows10 my VM guest is ubuntu build by vagrant. This worked for me:
vagrant plugin install vagrant-winnfsd
The solution for me was to update guest additions
(click Devices -> Insert Guest Additions CD image)
I also had a working system that suddenly stopped working with the described error.
After furtling around in my /lib/modules it would appear that the vboxvfs module is no more. Instead modprobe vboxsf was the required incantation to get things restarted.
Not sure when that change ocurred, but it caught me out.
I am running VirtualBox 5.1.20, and had a similar issue. Here is a url to where I found the fix, and the fix I implemented:
# https://dsin.wordpress.com/2016/08/17/ubuntu-wrong-fs-type-bad-option-bad-superblock/
if [ "5.1.20" == "${VBOXVER}" ]; then
rm /sbin/mount.vboxsf
ln -s /usr/lib/VBoxGuestAdditions/mount.vboxsf /sbin/mount.vboxsf
fi
The link had something similar to /usr/lib/VBoxGuestAdditions/other/mount.vboxsf, rather than what I have in the script excerpt.
For a build script I use in vagrant for the additions:
https://github.com/rburkholder/vagrant/blob/master/scripts/additions.sh
Seems to be a fix at https://www.virtualbox.org/ticket/16670
For me, on a mac, it turned out I had an old VirtualBox image stored on my machine that didn't have metadata, so it wasn't being updated to the latest version.
That old image had an older version of the vbguest plugin installed in it, which the newer vbguest plugin on my machine couldn't work with.
So to fix it, I just removed the image that my Vagrant was based on, and then Vagrant downloaded the newer version and it worked fine.
# Remove an old version of the virtual box image that my vagrant was using
$ vagrant box remove centos/7
You can find out which boxes you have cached on your machine by running:
$ vagrant box list
I had also upgraded my vbguest plugin in my earlier attempts at getting this to work, using the following process, but I don't think this helped. FYI !
# Get rid of old plugins
vagrant plugin expunge
# Globally install the latest version of the vbguest plugin`
vagrant plugin install vagrant-vbguest
If you find bring the box fails on guest addtions, you can try doing the following to ensure the plugins install correctly. This downloads the latest based image for your system (for me CentOS), and may resolve the issue (it did for me!)
$ vagrant box update
There can be errors/incorrect approach in two scenarios. Check both of it and figure it out
SCENARIO 1 :
Once you are running the VBoxLinuxAdditions.run or VBoxSolarisAdditions.pkg or VBoxWindowsAdditions.exe , check if all the modules are getting installed properly.
1.1.a. In case of VBoxLinuxAdditions, if Building the VirtualBox Guest Additions kernel modules gets failed,
check the log file in /var/log/vboxadd-install.log . If the error is due to kernel version update your kernel and reboot the vm. In case of fedora,
1.1.b. yum update kernel*
1.1.c. reboot
1.2. If nothing gets failed, then all is fine. You are already having the expected kernel version
SCENARIO 2 :
If the VBoxGuestAdditions is installed (check for a folder /opt/VBoxGuestAdditions-* is present .... * represents version) you need to start it before mounting.
2.1. cd /opt/VBoxGuestAdditions-*/init && ./vboxadd start
You need to specify the user id and group id of your vm user as options to the mount command.
2.2.a. Getting uid and gid of a user:
id -u <'user'>
id -g <'user'>
2.2.b. Setting uid and gid in options of mount command:
mount -t vboxsf -o uid=x,gid=x shared_folder_name guest_folder
On Ubuntu this worked:
sudo apt-get install build-essential linux-headers-`uname -r` dkms
Had the same issue with VirtualBox 5.0.16/rXXX
Installed latest VirtualBox 5.0.18 and installed latest Vagrant 1.9.3, issue went toodles.
I added as root user
/etc/rc.d/rc.local
/root/mount-vboxsf.sh
then
chmod +x /etc/rc.d/rc.local
and the sample script /root/mount-vboxsf.sh (set your own the uid and gid options)
modprobe -a vboxguest vboxsf vboxvideo
mount -t vboxsf NAME_SHARED_DIRECTORY /media/sf_NAME_SHARED_DIRECTORY -o rw,uid=0,gid=0
you need add
chmod + /root/mount-vboxsf.sh
I have similar issue, check header if it's not match then run below command
CentOS: sudo yum update && sudo yum -y install kernel-headers kernel-devel
If you're on Debian:
1) remove all installed package through Virtualbox Guest Additions ISO file:
sh /media/cdrom/VBoxLinuxAdditions.run uninstall
2) install Virtualbox packages:
apt-get install build-essential module-assistant virtualbox-guest-dkms virtualbox-guest-utils
Note that even with modprobe vboxsf returning nothing (so the module is correctly loaded), the vboxsf.so will call an executable named mount.vboxsf, which is provided by virtualbox-guest-utils. Ignoring this one will prevent you from understanding the real cause of the error.
strace mount /your-directory was a great help (No such file or directory on /sbin/mount.vboxsf).
An update did the trick for me !
$ vagrant box update
$ vagrant plugin install vagrant-vbguest
Below two commands works for me.
vagrant ssh
sudo mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant
Okay everyone is missing a basic fact.
mkdir /test - Makes sub directory in current directory.
sudo mkdir /test - Make directory in Root.
So if your shared directory name is shared and you do the following:
mkdir /test
sudo mount -t vboxsf shared /test
It generates this error:
sbin/mount.vboxsf: mounting failed with the error: No such file or directory
Because the directory is in the wrong place! Yes that's what this error is saying. The error is not saying reload the VBOX guest options.
But if you do this:
sudo mkdir ~/test
sudo mount -t vboxsf shared ~/test
Then it works fine.
It really amazes me how many people suggest reloading the Vbox guest additions to solve this error or writing a complex program to solve a directory created in the wrong place.

RabbitMQ command doesn't exist?

OS: Mac OSX 10.9
I have rabbitmq installed via home brew and when I go to /usr/local/sbin and run rabbitmq-server it states that: rabbitmq-server: command not found even as sudo it states the same error.
How do I get rabbitmq to start if it's not a command? I have also tried chmod +x rabbitmq-server in that directory to get it be an executable, same issue.
From the docs:
The RabbitMQ server scripts are installed into /usr/local/sbin. This is not automatically added to your path, so you may wish to add
PATH=$PATH:/usr/local/sbin to your .bash_profile or .profile. The server can then be started with rabbitmq-server.
All scripts run under your own user account. Sudo is not required.
You should be able to run /usr/local/sbin/rabbitmq-server or add it to your path to run it anywhere.
Your command failed because, by default, . is not on your $PATH. You went to the right directory (/usr/local/sbin) and wanted to run the rabbitmq-server that existed and had exec permissions, but by typing rabbitmq-server as a command Unix only searches for that command on your $PATH directories - which didn't include /usr/local/sbin.
What you wanted to do can be achieved by typing ./rabbitmq-server - say, execute the rabbitmq-server program that is in the current directory. That's analogous to running /usr/local/sbin/rabbitmq-server from everywhere - . represents your current directory, so it's the same as /usr/local/sbin in that context.
My OS: macOS Sierra 10.12.5
My RabbitMQ was installed using:
brew install rabbitmq
And it was installed into /usr/local/Cellar, just in case if someone has same situation with me, you would need to do similarly:
In terminal:
ls /usr/local/Cellar/rabbitmq/
to check which version you have installed, and then add to .bash_profile:
export PATH=/usr/local/Cellar/rabbitmq/<version>/sbin:$PATH
On mac by this command you can start,restart or stop rabbitmq
brew services start rabbitmq
brew services stop rabbitmq
brew services restart rabbitmq
As rabbitmq-server resides in /usr/local/sbin, running this command will enable starting server from anywhere:
export PATH=/usr/local/sbin:$PATH
I installed using home brew and I did the following:
brew install rabbitmq.
encountered issues cause the installation happened under bin and not /usr/local/sbin
So I did the following:
1. chown -R `whoami`:admin /usr/local/sbin
2. chown -R `whoami`:admin /usr/local/share
3. brew install rabbitmq
4. /usr/local/sbin/rabbitmq-server
And then the server runs and you can login to the management console :
http://localhost:15672/
userame: guest
password: guest
Start the service like this:
brew services start rabbitmq
Or if you don't need to start it as service:
/usr/local/sbin/rabbitmq-server
In my case the paths /usr/local/sbin/ nor /usr/local/Cellar/rabbitmq/ etc., did not work as Homebrew was putting these all together in a different location.
I opened Finder in my Mac and searched for rabbitmq-server in the search textbox on top right corner of the Finder window.
rabbitmq-server was located under the path below:
/Users/${USER}/homebrew/Cellar/rabbitmq/3.7.15/sbin
So in my ~/.bash_profile , I updated the PATH as below:
export PATH=$PATH:/Users/${USER}/homebrew/Cellar/rabbitmq/3.7.15/sbin
After source ~/.bash_profile
~ $ rabbitmq-server
## ##
## ## RabbitMQ 3.7.15. Copyright (C) 2007-2019 Pivotal Software, Inc.
########## Licensed under the MPL. See https://www.rabbitmq.com/
###### ##
########## Logs: /Users/santoshsindham/homebrew/var/log/rabbitmq/rabbit#localhost.log
/Users/santoshsindham/homebrew/var/log/rabbitmq/rabbit#localhost_upgrade.log
Starting broker...
completed with 6 plugins.
Just add this in your ~/.bash_profile
export PATH=$PATH:/usr/local/opt/rabbitmq/sbin
I installed using HomeBrew I added this to my bash profile
PATH=$PATH:/usr/local/Cellar
This worked for me
I have Mac OS version 10.13.6 installed. Somehow I did not have sbin directory present under /usr/local/. On carefully looking I found that for me the rabbitmq-server binary was present here /usr/local/Cellar/rabbitmq/3.7.9/sbin/rabbitmq-server.
i have read a wonderful article to fix that
simply open your bash_profile or .profile.
sudo nano ./bash_profile
in the begin of the file add PATH=$PATH:/usr/local/sbin, close and save, then write source ~/.bash_profile and lastly restart your terminal.
problem fix it!
http://www.andrewcranston.me/en/engineering/rabbitmq-and-path-variable/

Clamav installation steps for linux centos

I have tried to install clamav in linux centos, but not able to succeed, so anybody provide me the procedure to install clamav antivirus and test the same.
Thanks in advance
First thing to do is install the program sudo apt-get install clamav
It´s necessary install the deamon program as well sudo apt-get install clamav-daemon
Once that we have the program properly installed, will be necessary configure to make it works with our app. /etc/clamav/clamd.conf
TCPAddr 127.0.0.1
TCPSocket 3310
To configure by console the antivirus just type sudo dpkg-reconfigure clamav-freshclam
Restart the service sudo /etc/init.d/clamv-* restart
For CentOS 6
Install ClamAV via yum epel repo:
yum install clamd
Edit config file:
vim /etc/clamd.conf
ExtendedDetectionInfo yes
ExcludePath /usr/local/maldetect/
DetectPUA yes
Set to start on boot:
chkconfig clamd on
Update ClamAV prior to a scan:
freshclam
Start ClamAV:
service clamd start
Add the cron for daily automatic scans:
vim /etc/cron.daily/daily-clamscan
#!/bin/bash
SCAN_DIR="/"
LOG_FILE="/var/log/clamav/daily-clamscan.log"
/usr/bin/clamscan -i -r $SCAN_DIR >> $LOG_FILE
Set proper cron permissions:
sudo chmod +x /etc/cron.daily/daily-clamscan
Update the logrotate file to look for all logs via wildcard
vim /etc/logrotate.d/daily-clamscan
/var/log/clamav/daily-clamscan.log {
missingok
notifempty
create 644 clam clam
}
Thats how I installed it on my machine. Here are a few good quick commands or you can use the cron to manually run it. I also installed Linux Malware Detect (LMD) with it so I can do more for my scans.
Full System Scan that only displays infected files and runs in the background with bell
Use jobs command to view status
clamscan -r --bell -i / &

Resources