How to fix ENOSPC error while running cypress? - terminal

get some error called ESPONC from the terminal on Linux after running cypress by the command "npm run cy:open-mobile"

What version of Cypress are you on? 3.3.2 fixed some problems that could cause ENOSPC: https://docs.cypress.io/guides/references/changelog.html#3-3-2
Users have run in to ENOSPC when their filesystem doesn't support file watching, which Cypress uses to keep track of file changes.
If you're on Linux, you can try increasing the number of file watchers available:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Related

Rundeck debconf-set-selection:

I'm using Rundeck 3.2.6-20200427 and set up a job for installing packages.
Because rundeck runs noninteractive I need to preset some parameters for installing packages (in my case iptables-persistent).
Before installing the package I run that command (for now only this parameter, I will use more parameters if I got that working):
echo iptables-persistent iptables-persistent/autosave_v4 boolean false | sudo debconf-set-selections
Unfortunatelly I got that error if I run rundeck-command
09:09:08 debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
09:09:08 Failed: NonZeroResultCode: Remote command failed with exit status 1
I'm absolute sure that there are no other task or running dpkg related process.
~$ lsof /var/cache/debconf/config.dat
~$
If I try to run that command directly, it works without any error. So I don't understand, why it is not working with rundeck.
I tried that on freshly installed host where I try to install packages (Ubuntu Server 20.04).
Here is my job definition: https://pastebin.com/YSu545tX
I found out that in the node-file, there was a typo so the job was running on wrong host and there were an apt-process, which was stuck.
There I checked with that command:
~$ sudo fuser -v /var/cache/debconf/config.dat
USER PID ACCESS COMMAND
/var/cache/debconf/config.dat:
root 5563 F.... frontend
Then I killed that process and corrected the node-file. Now it works.
I meet the same problem, but both 'fuser' and 'lsof' show nothing. finally finds out is dpkg lock that file, and use
ps aux | grep dpkg
to find that process and kill it.

VirtualBox install failed in a clean OSX 10.13

I did a clean install of High Sierra, Mac OS X 10.13 on my mac.
I've installed a few apps, some browsers, webStorm, vagrant, skype and slack.
When trying to install virtualBox I get an error message saying:
"The installation failed.
The installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance."
When checking the installers log file I get the following error mesage:
Oct 19 16:22:42 newens-mbp installd[519]: PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=112 "An error occurred while running scripts from the package “VirtualBox.pkg”." UserInfo={NSFilePath=./postflight, NSURL=file://localhost/Volumes/VirtualBox/VirtualBox.pkg#VBoxKEXTs.pkg, PKInstallPackageIdentifier=org.virtualbox.pkg.vboxkexts, NSLocalizedDescription=An error occurred while running scripts from the package “VirtualBox.pkg”.} {
NSFilePath = "./postflight";
NSLocalizedDescription = "An error occurred while running scripts from the package \U201cVirtualBox.pkg\U201d.";
NSURL = "file://localhost/Volumes/VirtualBox/VirtualBox.pkg#VBoxKEXTs.pkg";
PKInstallPackageIdentifier = "org.virtualbox.pkg.vboxkexts";
}
I've googled this, and found a few threads here and there that solve different problems. But so far none has worked for me.
Some of the posts I've found:
https://www.virtualbox.org/ticket/15832
Error installing Virtualbox 5.1.10 on macOS Sierra, "The installation failed"
https://apple.stackexchange.com/questions/177868/virtualbox-4-3-26-on-osx-10-10-2-fails-to-install
Can't unload kext while installing VirtualBox 4.3.6
None of these solutions worked for me.
I don't have vmware installed, and have tried searching for the .match_kernel file to delete, but can't find it anywhere. I don't have the option of selecting a partition on disk utilities so can't do a repair disk permissions on it.
I've installed and uninstalled different versions and cold booted in between to try to see if that would help.
Thanks for any help!
after hours of hacking at this issue my coworker and i came to a workable solution. the issue (for me at least) was that when i went to install the package it was getting blocked. you can check to see if this is the case by attempting to install, and when it says 'install failed' go to your security & privacy (in system preferences) and go to the 'general' tab and near the bottom it will say that an oracle application was blocked.
here are the steps we came up with **NOTE: if you tried downloading or installing this a few times like i did you will want to first uninstall virtualbox using the virtualbox uninstall tool which you can find in the downloaded .dmg file. you will also want to eject virtualbox from your devices (in the left panel of finder). after that go ahead and follow these instructions:
Download VirtualBox 5.2 installer
Run the DMG, this creates a device
Attempt to install from .pkg file, it will fail at the validation step
Close installer and run the uninstaller.tool file. DO NOT DELETE THE INSTALLER DEVICE
Go to System Preferences -> Security and Privacy -> General and approve the blocked software from ‘Oracle America’
Run the install from the same .pkg file, it should now complete successfully
I finally managed to solve it with a suggestion from here: https://github.com/caskroom/homebrew-cask/issues/39369#issuecomment-339118861
Run this script:
#!/bin/bash
unload() {
if [ `ps -ef | grep -c VirtualBox$` -ne 0 ]
then
echo "VirtualBox still seems to be running. Please investigate!!"
exit 1;
elif [ `ps -ef | grep -c [V]ir` -gt 0 ]
then
echo "Stopping running processes before unloading Kernel Extensions"
ps -ef | grep [V]ir | awk '{print $2}' | xargs kill
fi
echo "Unloading Kernel Extensions"
kextstat | grep "org.virtualbox.kext.VBoxUSB" > /dev/null 2>&1 && sudo kextunload -b org.virtualbox.kext.VBoxUSB
kextstat | grep "org.virtualbox.kext.VBoxNetFlt" > /dev/null 2>&1 && sudo kextunload -b org.virtualbox.kext.VBoxNetFlt
kextstat | grep "org.virtualbox.kext.VBoxNetAdp" > /dev/null 2>&1 && sudo kextunload -b org.virtualbox.kext.VBoxNetAdp
kextstat | grep "org.virtualbox.kext.VBoxDrv" > /dev/null 2>&1 && sudo kextunload -b org.virtualbox.kext.VBoxDrv
}
load() {
echo "Loading Kernel Extentions"
sudo kextload "/Library/Application Support/VirtualBox/VBoxDrv.kext" -r "/Library/Application Support/VirtualBox/"
sudo kextload "/Library/Application Support/VirtualBox/VBoxNetAdp.kext" -r "/Library/Application Support/VirtualBox/"
sudo kextload "/Library/Application Support/VirtualBox/VBoxNetFlt.kext" -r "/Library/Application Support/VirtualBox/"
sudo kextload "/Library/Application Support/VirtualBox/VBoxUSB.kext" -r "/Library/Application Support/VirtualBox/"
}
case "$1" in
unload|remove)
unload
;;
load)
load
;;
*|reload)
unload
load
;;
esac
Run this script after you attempt to install virtualbox. Keep approving the kexts until the script runs cleanly:
Run brew cask reinstall --force virtualbox
Kudos to Dan Stroot for the solution.
Solution so far:
Ok, this is a bit of a hassle but we did manage to make it kind of work.
The issue is related to the system not deleting all files from the virtual box installation.
Using the terminal to search for files with virtualbox in the name of the file, we found (non vagrant related) files that were still in the system.
Problem is these files cannot be deleted even using sudo. So we had to reboot the system pressing cmd + r so you go into a troubleshooting system and not the normal OS environment. In there, you can open the terminal and run "csrutil disable", then reboot the system.
This turns off System Integrity Protection for your system so it is NOT RECOMMENDED, but we had to do this in order to delete these files that we couldn't delete before.
So after deleting these files, we ran the install again and now it worked! Immediately afterwards I tried running vagrant and now it worked as expected.
My final problem now: after making sure that vagrant is working, I went back to starting the computer again pressing cmd + r, open the terminal and run "csrutil enable" and reboot.
Back in the normal OS X I try to run vagrant and get an error again. So at the moment I had to go back again, to disable the csrutil, which is NOT RECOMMENDED, but it's as of this moment the only thing that works for me.
I have not tried running all these steps again.
The answer from llene works perfect for me. The key is that, when you already tried to install and not succeed, you have to do exactly this steps:
Run VirtualBox installer
Run install from .pkg file, it will fail at the validation step, it's ok
close installer and run it again, but now choose uninstaller.tool file, inside (DO NOT DELETE THE INSTALLER DEVICE yet)
eject virtualbox from your devices (in the left panel of finder)
After, go to System Preferences -> Security and Privacy -> General and approve the blocked software from ‘Oracle America’, that will appear there
6) Run install again from the same .pkg file. Now it should complete successfully
Managed to solve it.
Eject the VirtualBox image from: Finder > Devices
Remove VirtualBox device
Now allow the exception in: System Preferences > Security & Privacy
Then try to install from the .dmg again so that it remounts the device.
Now its working fine for me.
For those using homebrew, run 'brew install caskroom/cask/virtualbox', which will fail the first time. Then go to System Preferences>Security & Privacy>General as described above, where, at the bottom, there should be a message about the software install being blocked. Click the 'Allow' button next to this message, then go back to your terminal. Run the homebrew command again and this time it will work.
So.. after struggling a lot about this, and after spend a lot of time in stack overflow.. I combined some answers and finnaly get to install virtualbox in my 10.13 osx.
So:
As I read, Sierra has a new security feature that blocks some external programs. During virtualbox installations you can check Preferences > Security & Privacy > General. You will see that Oracle (virtualbox) is being blocked.
So, what I did was:
Run this command at terminal to disable that new sierra gatekeeper: sudo spctl --master-disable
Open the virtualbox install program, and click unistall to make sure there is no trace of the previous installation attempts.
In the desktop, or in the finder left sidebar (in devices) if there is any virtualbox image, you have to eject them.
Delete the previous virtualbox program and download a new one.
Now, if these steps work for you as they worked for me, you will be able to install virtualbox.
(After this you can re-enable the gatekeeper feature running sudo spctl --master-enable
When running the excellent Disk Arbitrator app, Deactivate it — when active it blocks all mounts and optionally remounts them read-only
which, e.g., prevents Spotlight from trashing USB drives but (d-uh)
gotta remember to turn it off when appropriate.

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

`dpkg --configure -a` hangs

I'm using Ubuntu 16.04.
When I update, I got the following message
$ sudo apt-get update
....
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
Following the error message, I try
$ sudo dpkg --configure -a
setting up snapd (2.14.2~16.04) ...
then it hangs forever.
Does anybody know how can I fix this problem?
Thanks.
This is a confirmed bug.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
A workaround is listed:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336/comments/4
Adding the workaround from Axel Kämpfe since the links seems to be broken:
Start a rootshell with "sudo -i"
Run echo "bash -c 'service snapd.boot-ok start'" | at now + 4 min
Then run apt install snapd (if it argues about canceled dpkg processes use the dpkg --configure -a. Then wait for at least 4 minutes. The hanging should gone then.
Good luck! :)
/Patrik
I had a similar problem twice and I have noticed that it happens everytime my system wants to upgrade to a new Kernel. The steps below seem to work for me all the time;
Boot into the recovery mode of your newest kernel versions.
Log-in to the system as root from the drop-down menu.
Edit the /etc/resolv.conf file using a text editor, I normally use vi, i.e.
vi /etc/resolv.conf
and put in the contents below and save file;
nameserver 208.67.222.220
nameserver 208.67.222.222
After the above step, Ctrl+D (exit) back into the recovery mode menu and click on networking to enable network/internet connection.
Next, click on the dpkg item to fix broken packages.
That's it, after the reboot your system should have the right kernel install and broken packages fixed/removed.
Identify the application that is causing the dpkg --configure -a hanging error.
Example: snapd
Execute the following command:
sudo apt-get remove snapd
In my case, I entered the following command:
sudo apt-get remove mysql-server-8.0
Re-install the application if necessary.
I hope this helps you too. Health!

Why does npm need sudo for EVERYTHING?

I don't know how I've managed it but npm seems to need sudo for absolutely every command, even npm help does not work without sudo. If I use a command without sudo, I do not see am EACCESS error, but instead my terminal session hangs and then just closes that tab (I use iTerm on Mac).
I have tried changing the ownership of my local .npm folder, outlined here and also done the same on my /usr/local/bin folder where node is installed but none of these allow me to just run npm without sudo, even when installing local packages...! It seems to me that something has screwed along the way, can anyone help?
Many thanks
I encountered the same error after a fresh install of 0.12.4 today; this solved the problem for me:
sudo chown -R $(whoami):admin /usr/local/lib/node_modules
In my particular case, I noticed that this folder was owned by '{some-large-integer-account}:wheel'...YMMV
If that doesn't solve it, take a look at the ownership of the folders that are being blocked as mentioned in the EACCESS error trace. If you're not sure what the ownership should be, you can usually infer it from the sibling dirs' ownership.
I had this as well on my machine. What I did to fix it (there are probably much less extreme ways) was to completely remove npm, and then did a fresh installation node.js (with which npm is included) from http://nodejs.org/ making sure I didn't install as root. That then allowed me to use npm without root (except for global installs).
Take ember project for example, I give all related project directory root:
neil#neil-System-Product-Name:~/Projects/ember-quickstart$ sudo chown -R $(whoami) /home/neil/Projects/ember-quickstart/
neil#neil-System-Product-Name:~/Projects/ember-quickstart$ ember s
Could not start watchman
Visit https://ember-cli.com/user-guide/#watchman for more info.
Livereload server on http://localhost:7020
Build successful (10679ms) – Serving on http://localhost:4200/
Slowest Nodes (totalTime => 5% ) | Total (avg)
----------------------------------------------+---------------------
Babel (18) | 7561ms (420 ms)
Concat (8) | 1872ms (234 ms)
Rollup (1) | 629ms
Use the below option.
Open the terminal and cd to your Home directory and run the below command.
mkdir "${HOME}/.npm-packages"
Then this command after that.
npm config set prefix "${HOME}/.npm-packages"
Next, open your .zshrc file using the open -t .zshrc command and add the following to it.
NPM_PACKAGES="${HOME}/.npm-packages"
export PATH="$PATH:$NPM_PACKAGES/bin"
# Preserve MANPATH if you already defined it somewhere in your config.
# Otherwise, fall back to `manpath` so we can inherit from `/etc/manpath`.
export MANPATH="${MANPATH-$(manpath)}:$NPM_PACKAGES/share/man"

Resources