React Native Error: ENOSPC: System limit for number of file watchers reached - react-native

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

Related

WSL2 Clock is out of sync with Windows

WSL2 clock goes out of sync after resuming from sleep/hibernate.
A workaround was shared on GitHub sudo hwclock -s to resync clock in WSL, but you have to do this every time you resume from sleep/hibernate.
UPDATE: THIS BUG IS FIXED, just check for updates! See the Clock Sync fix
In case anyone finds this via search and doesn't notice that there is actually a solution listed in the question, you can fix WSL clock drift via.
sudo hwclock -s
If you just need to do it occasionally, this is a fine solution. If you need to do it more frequently, consider #piouson's solution
Update
The fix is now in WSL2 Linux kernel 5.10.16.3 and newer! Note you may need to install WSL2 from the Windows Store to get the latest kernel version per this thread with Craig from Microsoft.
Older Answer
sudo hwclock -s gets you kind of there, but for some reason doesn't get the exact time - I often find it's a minute or so in the future!
sudo ntpdate pool.ntp.org should get you the correct time.
But this is all because of a bug in the Linux kernel which should be included in a Windows update at some point...
There are a number of hacks referenced in the the GitHub issue which can work around this, mostly, but not always, in my experience...
just restart wsl, it works fine for me
wsl --shutdown
then
wsl
in PowerShell
UPDATE: as mentioned by drkvogel, the Clock Sync fix was released in WSL2 kernel version 5.10.16.3
OBSOLETE
At time of writing, this GitHub Issue was open for the bug.
The workaround I chose for my situation (single distro in WSL2) is to use Windows Task Scheduler to run hwclock in WSL whenever Windows resyncs hardware clock.
Windows: Open PowerShell as Administrator
schtasks /create /tn WSLClockSync /tr "wsl.exe sudo hwclock -s" /sc onevent /ec system /mo "*[System[Provider[#Name='Microsoft-Windows-Kernel-General'] and (EventID=1)]]"
Set-ScheduledTask WSLClockSync -Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries)
WSL2: Run sudo visudo and add hwclock to sudoers to skip password prompt
# bottom of my file looks like this
...
...
#includedir /etc/sudoers.d
<username> ALL=(ALL) NOPASSWD:/usr/sbin/hwclock, /usr/bin/apt update, /usr/bin/apt upgrade
Results
See image for how to get Event XPath from Windows Event filtering. Use as provided to let task scheduler auto-display scheduled triggers.
Use cron to schedule sudo hwclock -s
As others said before sudo hwclock -s syncs the clock,
but you will need to do this after every sleep/hibernate.
Solution is to add an hourly cron task to sync the clock.
Open crontab with sudo (must open with sudo since the command uses sudo):
sudo crontab -e
and add this code with a new line after the task (it's a cron requirement):
PATH=/sbin:/bin:/usr/bin
#hourly hwclock -s
You must either set PATH since root-cron do not has it or use absolute paths e.g. /usr/sbin/hwclock.
cron troubleshooting:
To verify cron is working you may add a dummy task (don't forget to add a new line):
* * * * * date > /tmp/log.txt
If no file is created, verify cron is working: pgrep cron.
If no PID shows, start cron with: sudo service cron start.
To learn cron timing method: cron timing generator
Necro'ing this: As of May 2022, this issue persists to a degree.
There are two components.
First, Windows time sync needs to be decent to start with. It's not, out of the box, on machines that aren't domain-joined.
Change w32time to start automatically. In Administrator cmd, but not PowerShell, sc triggerinfo w32time start/networkon stop/networkoff. Verify with sc qtriggerinfo w32time. To get into cmd that way, you can start Admin PowerShell and then just type cmd.
Make a few changes in regedit.
In Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config, set MaxPollInterval to hex c, decimal 12.
Check Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Parameters\NtpServer. If it ends in 0x9 you are done. If it ends in 0x1 you need to adjust SpecialPollInterval in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient to read 3600
Reboot, then from Powershell run w32tm /query /status /verbose to verify that w32time service did start. If it didn't, check triggers again. If all else fails, set it to Automatic Delayed startup
Second, WSL2 needs to actually stay in sync. MS will likely release another kernel fix. In the meantime a scheduled task can bring it back into sync periodically:
schtasks /Create /TN WSL2TimeSync /TR "wsl -u root hwclock -s" /SC ONEVENT /EC System /MO "*[System[Provider[#Name='Microsoft-Windows-Kernel-Power'] and (EventID=107 or EventID=507) or Provider[#Name='Microsoft-Windows-Kernel-General'] and (EventID=1)]]" /F
This GitHub Issue was closed
You can also run the below command in Powershell Terminal so sync it.
wsl.exe sudo hwclock -s
You can manually update the WSL2 kernel to 5.10.16 by following the method in this comment: #5650 (comment). I have fixed the issue by this method.
I've added this to Windows Task Scheduler, set to run every 12 hours:
wsl.exe -d ubuntu -u root -- ntpdate time.windows.com
To install ntpdate:
sudo apt install ntpdate
For me this issue seems to be happening when the system goes to sleep. So I have registered a bash command to call whenever, it goes out of sync. I did it by adding a function.sh file and sourced it in ~/.bashrc.
function.sh:
YELLOW='\033[0;33m'
NC='\033[0m'
TIME_SERVER=ntp.ubuntu.com
# Sync wsl time
sync_date () {
echo -e "${RED}sudo ntpdate $TIME_SERVER ${NC}"
echo
sudo ntpdate $TIME_SERVER
}
~/.bashrc:
source ~/Linux/funtions.sh
Note that I have added a bit of color and some customizations (TIME_SERVER: [windows time server is other option]).
You can sync the time using sync_date command in cli.

How can I raise the limit for open files in Ubuntu 20.04 on WSL2?

My setup looks as follows: Windows 10, Release 1909 (Build 18363.1082), using WSL2 with an Ubuntu 20.04 environment. Everything works nicely most of the time, but there are some issues I cannot manage to solve.
During development using parcel (React bundler), I run into the problem that the bundler apparently opens lots of files at the same time, and at a certain point, I run into the following problem:
EMFILE: too many open files, open '/home/myusername/Projects/some-project-path/node_modules/#material-ui/icons/esm/RoundedCornerRounded.js'
As parcel seemingly does not easily support using something like graceful-fs, I have tried to increase the limit for open files inside the Ubuntu environment. What I have tried so far:
A simple ulimit -n 4096 (which is the highest possible by default), but it's apparently (by far?) not enough
I tried increasing fs.files-max to something really high in /etc/sysctl.conf, but it doesn't seem to have an effect (neither after sysctl -p nor after a restart of wsl)
I also tried increasing fs.inotify.max_user_watches, but that did not seem to have an effect either
Also setting soft and hard limits in /etc/security/limits.conf did not seem to have an effect
I also found information that changing DefaultLimitNOFILE in /etc/systemd/system.conf can have an effect (so I did that as well)
Has anybody manage to solve a similar system on Ubuntu 20.04 on WSL2? This left me pretty stumped, and it prevents me from using parcel inside this environment. That's a real pity, as really everything else is working really fine.
UPDATE
So I have found out that my changes in various places (probably the one in /etc/security/limits.conf) has had some kind of effect. Just not when logging in directly. This illustrates this:
donmartin#SOMEMACHINE:~$ ulimit -Hn
4096
donmartin#SOMEMACHINE:~$ su donmartin
Password:
donmartin#SOMEMACHINE:~$ ulimit -Hn
65536
donmartin#SOMEMACHINE:~$
Which means: If I su to my own user, the ulimit has indeed been raised. But if I log in just as normal using Windows Terminal, this limit is not in effect. Even more puzzled now - BUT - I have a workaround for my problem. Having set my values to 65536, the parcel build now works, running as my own user. Go figure! I still don't quite know which setting was changing the behaviour now - perhaps somebody has more thorough information on how this works and/or how I can make this also the default without having to do a su to get the updated limits.
I had to add the following line to /etc/systemd/user.conf:
DefaultLimitNOFILE=65535
As written in the answer here:
https://superuser.com/questions/1200539/cannot-increase-open-file-limit-past-4096-ubuntu/1200818#1200818?s=1b927bb17396480da98a94cbacf8da62
Also you may need to run this (if working with applications that monitors changes in many files/folders):
sudo sh -c 'sysctl fs.inotify.max_user_watches=524288 && sysctl -p'
Try this:
$ visudo
ADD: user ALL=(ALL) NOPASSWD:ALL
$ vi ~/.profile
ADD: user ALL=(ALL) NOPASSWD:ALL
$ vi /etc/security/limits.conf
ADD: user soft nproc 10000
user hard nproc 10000
user soft nofile 10000
user hard nofile 10000
Temporarily increase the open files hard limit for the session
Run this 3 commands (the first one is optinal), to check current open files limit, switch to admin user, and increase the value.
$ ulimit -n
1024
$ su <user name>
<Enter password>
$ ulimit -n 65535
Check the new limit:
$ ulimit -n
65535
To check all values, run this:
$ ulimit -a

Stuck when installing phpmyadmin

I was installing phpmyadmin following this tutorial.
I missed the warning in step 1 and I did not select Apache2. I exited the command line and when I try to start from the beginning I get this error:
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
I've been searching for answers, but couldn't find one that helps.
What should I do here?
Thanks
Some of the running processes is still using the apt package manager. You can find the apt process using the following command:
ps aux | grep apt
and kill it:
sudo kill -9 PID
Don't forget to replace PID with the actual process ID.
Probably a background process is using/locked on the administrator directory. You could
ps
or
ps | e
to view the running processes and stop/kill the one using the dpkg.
I ran into this error once after updating my Linux Mint Tara, and couldn't use dpkg. I had to restart the whole system which worked fine.
You could try it too, restarting.
It mean something(Process) else is installing or removing software and has locked the apt database while it performs the action.(Probably The Software Center or The update Manager). The safest way is(without crashing your system) Reboot Ubuntu the Try to install phpmyadmin again.
Killing the process might not work always, because there could be no process involved at all!
So, the best solution would be:
sudo rm /var/lib/apt/lists/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock*
I had your same error messages [both of them] and I solved the issue running:
sudo rm /var/lib/apt/lists/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock
as said in this post which explains that "the root cause is the lock file. Lock files are used to prevent two or more processes from using the same data. When apt or apt-commands are run, it creates lock files in a few places. When the previous apt command was not terminated properly, the lock files were not deleted and hence they prevent any new instances of apt/apt-get commands"

Running "screen" without additional permissions on WSL

I'm trying to run the "screen" utility on Windows Subsystem for Linux on Windows 10 (Version 1703, OS Build 15063.483).
It seems that I need additional permissions to run it (it works if I "sudo" it), but I don't understand why that is necessary.
What is the recommended way to set this up?
Is there some reason why this isn't the default set up?
$ screen
Cannot make directory '/var/run/screen': Permission denied
From an answer on SuperUser I discovered that you have to run
sudo /etc/init.d/screen-cleanup start
Then screen works fine for me.
EDIT: after installing Ubuntu 20.04 the problem went away (*).
As Krease pointed out, the best solution is the one described in this SuperUser post.
Add the following to your .bashrc:
export SCREENDIR=$HOME/.screen
[ -d $SCREENDIR ] || mkdir -p -m 700 $SCREENDIR
See also issue 1245 on github.
--
(*) now this warning comes up, but seems harmless:
sleep: cannot read realtime clock: Invalid argument
sudo screen # which creates dir /var/run/screen
chmod 777 /var/screen # so that non-root users can create their own screen dir in this dir.

How to add EnvironmentFile directive to systemctl using Docker with centos7/httpd base image

I am not sure if this is possible without creating my own base image, but I use environment variables in /etc/environment on our servers and typically make them accessible to apache by doing the following:
$ printf "HTTP_VAR1=var1-value\n\
HTTP_VAR2=var2-value"\
>> /etc/environment
$ mkdir /usr/lib/systemd/system/httpd.service.d
$ printf "[Service]\n\
EnvironmentFile=/etc/environment"\
> /usr/lib/systemd/system/httpd.service.d/environment.conf
$ systemctl daemon-reload
$ systemctl restart httpd
$ reboot
The variables are then available in any PHP calls to getenv('HTTP_VAR1'); and etc. However, in running this from a docker file I get dbus errors on the systemctl commands. Without the systemctl commands it seems the variables are not available to apache as it seems the new EnvironmentFile directive doesn't take effect. My docker file snippet:
FROM centos/httpd:latest
RUN printf "HTTP_VAR1=var1-value\n\
HTTP_VAR2=var2-value"\
>> /etc/environment
RUN mkdir /usr/lib/systemd/system/httpd.service.d &&\
printf "[Service]\n\
EnvironmentFile=/etc/environment"\
> /usr/lib/systemd/system/httpd.service.d/environment.conf
RUN systemctl daemon-reload &&\
systemctl restart httpd
COPY entrypoint.sh /entrypoint.sh
So I happened upon the answer to the issue today. It seems that systemd drops backslashes inside single quotes, but it may effect double-quotes too from what I saw in testing. I found the systemd development mailing list thread from April 2014 where patching the issue was being discussed. It seems as though the fix never made it in. So we have to work around it.
In attempting to work around it I noticed some issues with actually reading the variables at all. It seemed as though either Apache or php-cli would get the correct variables, and sometimes not at all, it took a bit of sleuthing to figure out what was going on. Then I started reading into the systemd's EnvironmentFile directive to see if there was more to gain from the docs. It turns out it does not evaluate bash so export won't work. It expects a text file with variable assignments and herein lies one of the main issues that might keep this from being resolved.
I then devised a workable solution. Utilizing systemd's ExecStartPre directive I am able to run a script on startup of the httpd service. I then read in the environment file and write a new plain text one that will then be used by httpd's systemd unit. Here is the code:
Firstly, I moved my variables to /etc/profile.d/ directory rather than /etc/environment file.
file: /etc/profile.d/environment.sh
This is where we store all our environment variables, this gets easily sourced on all interactive shell logins. In the rarer cases where we need to have these variables available non-interactively we can either provide --login flag to /bin/bash or source it manually.
export HTTP_VAR1=var1-value-with-a-back\slash
export HTTP_VAR2=var2-value
file: /usr/lib/systemd/system/httpd.service.d/environment.conf
Our drop-in unit file to extend how the httpd service works. I add in a script that runs before httpd starts up. This gets ran on all httpd restarts and starts. The script that runs generates a plain text file at /etc/profile.d/environment.env which we subsequently tell systemd to load as an EnvironmentFile.
[Service]
ExecStartPre=/usr/bin/bash -c "/usr/local/bin/generate-plain-environment-file"
EnvironmentFile=/etc/profile.d/environment.env
file: /usr/local/bin/generate-plain-environment-file
Here is the script I am using, I whipped this together really fast, I really don't think it is that robust and it could be better. It just removes the export from the beginning of the lines and then escapes any backslashes since systemd drops single backslashes. A more proper solution might be to use bash to evaluate each line and obtain the variable value in case of usage of variables or other bash in the actual bash variables, then output them as plain text name=value assignments, however this is not part of my use-case so I didn't bother.
#!/bin/bash
cd /etc/profile.d/
rm -rf "./environment.env"
while IFS='' read -r line || [[ -n "$line" ]]; do
echo $(echo "${line}" | sed 's/^export //' | sed 's/\\/\\\\/g') >> "./environment.env";
done < "./environment.sh"
file: /etc/profile.d/environment.env
This is the resulting file generated by the described script.
HTTP_VAR1=var1-value-with-a-back\\slash
HTTP_VAR2=var2-value
Conclusion is that the I now have two files with the same thing in them but I only need to maintain the one, the other is generated each time we restart httpd. Also, we fix the backslash issue in the process. Hurray!