There is not enough space available in tmpfs docker container - unix

I'm running a docker container that seems to have insufficient memory and I'm not sure how to solve this problem.
I'm essentially running a program on this docker container that downloads an image into tmpfs, performs some operations, deletes the the image and returns a result. However, it seems like I'm running into images that are too large to store in my current docker tmpfs. Below is the output of the linux df command while inside the container:
Filesystem Size Used Avail Use% Mounted on
overlay 63G 11G 50G 18% /
tmpfs 64M 0 64M 0% /dev
tmpfs 6.9G 0 6.9G 0% /sys/fs/cgroup
/dev/sda1 63G 11G 50G 18% /etc/hosts
shm 64M 4.0K 64M 1% /dev/shm
tmpfs 6.9G 0 6.9G 0% /sys/firmware
I've tried expanding docker's memory (hence the huge values on two of the tmpfs's) but I'm still running into this problem.
I guess I have a couple of questions:
1) what is the difference between the 3 separate tmpfs filesystems? Why do they exist?
2) Presumably I need to expand the first tmpfs size (the small one) -- how would I go about doing that?
Finally, some relevant system information:
OS -- OSX
Docker version -- Docker version 17.09.0-ce, build afdb6d4
Let me know if there's other stuff you need to know!
Thanks everyone.

Okay, ultimately figured out the answer. My original two questions were kind of off base.
Essentially, my docker instance didn't have enough memory -- the tmpfs files were red herrings. I ended up needing to pass in a --shm-size="4096m" argument to my docker start command (increased memory to 4096 megabytes) in order to allow my function to properly execute. Hope this helps someone down the road!
Also, for google purpose, the exact error I was getting was There is not enough space available on the shmfs/tmpfs file system. relating to Abbyy FineReader

If you are using Kubernetes, then you need sufficient space in /dev/shm.
In my case, there wasnt enough space in /dev/shm hence Abbyy would bail out before extracting Meta-images. After giving /dev/shm a volume mount, it worked fine. Hope this helps!

Related

Google Cloud Shell `No space left on device` even though disk not full?

I am trying to replace my local development machine with Google Cloud Sheel. When running yarn on Cloud Shell, the system says I am out of space. But df tells me there is lots of space remaining (only 68% used on /home)
#cloudshell:~/***$ df
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 62742040 43483680 19241976 70% /
tmpfs 65536 0 65536 0% /dev
tmpfs 8200748 0 8200748 0% /sys/fs/cgroup
/dev/disk/by-id/google-home-part1 5028480 3229288 1520716 68% /home
/dev/sda1 62742040 43483680 19241976 70% /root
/dev/root 2006736 1012260 994476 51% /lib/modules
shm 65536 0 65536 0% /dev/shm
tmpfs 8200748 904 8199844 1% /google/host/var/run
user#cloudshell:~/**$ pwd
/home/user/***
user#cloudshell:~/***$ mkdir test
mkdir: cannot create directory ‘test’: No space left on device
Am I missing something? Why does the system say out of space when there is 32% left?
According to the Cloud Shell documentation:
Cloud Shell provisions 5 GB of free persistent disk storage mounted as
your $HOME directory on the virtual machine instance.
...
If you encounter a no space left on device error, you'll need to remove files from your home directory using the Cloud Shell terminal to free up space.
So it is possible that when it reaches a certain threshold of disk usage that message will pop up.

EC2 with wordpress - everyday running out of space (no space left on device) - can't start apache

I'm having the strangest problem for days now. I took over a WordPress website of a company that was originally developed by another person – the codebase is a mess but I was able to go over it and make sure it at least is working.
The database is huge (70mb) and there is a lot of plugin dependencies on the site.
However the site works generally without issues now and I'm hosting it on an EC2 with a bitnami stack for WordPress.
The weird thing though is that everyday (for instance today morning) I check the site and it's down … 
Service Unavailable The server is temporarily unable to service your
request due to maintenance downtime or capacity problems. Please try
again later.
Additionally, a 503 Service Unavailable error was encountered while
trying to use an ErrorDocument to handle the request.
When logging into the server with ssh and trying to restart apache I get this:
Failed to unmonitor apache: write /var/lib/gonit/state: no space left
on device Syntax OK /opt/bitnami/apache2/scripts/ctl.sh : apache not
running Syntax OK (98)Address already in use: AH00072: make_sock:
could not bind to address [::]:80 (98)Address already in use: AH00072:
make_sock: could not bind to address 0.0.0.0:80 no listening sockets
available, shutting down AH00015: Unable to open logs
/opt/bitnami/apache2/scripts/ctl.sh : httpd could not be started
Failed to monitor apache: write /var/lib/gonit/state: no space left on
device
I had this the 3rd time in 3 days now even though I restored the server from a snapshot with a volume of 200gb (for testing purposes) and all site files including uploads only have 5gb.
The site is running on an EC2 (t2.medium) with 200gb volume now and today morning I can't restart apache. Yesterday evening when restoring from a snapshot the site works well and normal - it's actually even fast.
I don't know where to start investigating here. What could cause the server to run out of disc space in one night?
Thanks,
Matt
Also one of the weirdest things it seems. I reset everything yesterday eventing from an EC2 snapshot to a 200gb volume and attached it to the instance. Everything was working fine. I made some changes on the files, deleted some plugins, updated some settings.
And it seems this is all gone now. And I'm using an elastic IP, so I couldn't connect to a wrong device or something.
Bitnami Engineer here, you will probably need to resize the disk of your instance. But you can investigate those issues later, these commands will show the directories with large number of files
cd /opt/bitnami
sudo find . -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
du -h -d 1
If MySQL is the service that is taking more space, you can try adding this line under the [mysqld] block of the /opt/bitnami/mysql/my.cnf configuration file
expire_logs_days = 7
That will force MySQL to purge the old logs of the server after 7 days. You will need to restart MySQL after that:
sudo /opt/bitnami/ctlscript.sh restart mysql
More information here:
https://community.bitnami.com/t/something-taking-up-space-and-growing/64532/7
What you need to do is increase the size of partition on the disk and the size of file system on that partition. Even you increased the volume size, these figure kept unchanged. Create another from snapshot would not help too.
Check how to do it here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
Your df result shows
Filesystem 1K—blocks Used Available Use% Mounted on
udev 2014560 0 2014560 0% /dev
tmpfs 404496 5872 398624 2% /run
/dev/xvdal 20263528 20119048 128096 100%
tmpfs 2022464 0 2022464 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 2022464 0 2022464 0% /sys/fs/cgroup
/dev/loop0 18432 18432 0 100% /snap/amazon—ssm—agent/1480
/dev/loopl 91264 91264 0 100% /snap/core/7713
/dev/loop2 12928 12928 0 100% /snap/amazon—ssm—agent/295
/dev/loop3 91264 91264 0 100% /snap/core/7917
tmpfs 404496 0 404496 0% /run/user/1000
where the root volume /deb/xvda1 has only 20GB and that is marked as 100% of the volume, not 200GB as you mentioned.
When you increase the volume size during the instance running, it is not automatically applied. In your EC2, you have to apply the change of volume as follows:
sudo resize2fs /dev/xvda1
and check the size of the volume by doing df -h then you will see the size is now 200GB.

Resizing /Dev/SDA1 : Google Cloud

I am a total noob on this one. I have a google cloud SUSE instance which is running a VM image. I am trying to install a package but I think it's running out of space.
What I want to do is to assign some of the 120G space to my /dev/sda1 partition. I have read the google's guide but I am not sure which section should I be following.
>df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 13G 0 13G 0% /dev
tmpfs 13G 0 13G 0% /dev/shm
tmpfs 13G 9.7M 13G 1% /run
tmpfs 13G 0 13G 0% /sys/fs/cgroup
/dev/sda1 36G 34G 0 100% /
tmpfs 2.6G 0 2.6G 0% /run/user/490
tmpfs 2.6G 0 2.6G 0% /run/user/1004
tmpfs 2.6G 0 2.6G 0% /run/user/1006
>sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
└─sda1 8:1 0 36G 0 part /
Without reboot increase boot size in GCP cloud VM
Check first disk usage using df -h if usage of /dev/sda1 more than 80% it's dangerous.
Update disk size on the fly
Increase disk size from console first
SSH inside VM : sudo growpart /dev/sda 1
Resize your file system : sudo resize2fs /dev/sda1
Verify : df -h
Increase the size of existing persistent disk:
Login to Google Cloud Platform
Goto Compute Engine -> Disks
Locate your VM's boot disk(default disk), open it
Click Edit
Enter a new size, please note that you won't be able to decrease this size later.
Reboot your VM, you should be able to see new size of disk.
This is just an addition to Prateeks answer. After changing the size, you need to run (linux only) to reboot:
sudo reboot
Give it some time, close your console if you get no response. Then run df again to see the new size.
Super late to the party but using sudo growpart /dev/sda 1 worked for me

Persistent disk size is not changing - Google Compute Engine

I changed size of my persistent disk from 10GB to 20GB.
Screenshot
Now when I run df command in my server, I can still see only 10GB space.
user#edudrona-prod-vm:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10186040 6755924 2889652 71% /
udev 10240 0 10240 0% /dev
tmpfs 1535964 8528 1527436 1% /run
tmpfs 3839908 0 3839908 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 3839908 0 3839908 0% /sys/fs/cgroup
tmpfs 767984 0 767984 0% /run/user/1003
I am just running simple Wordpress site using Bitnami. Except from changing 10GB to 20GB, I did not make any change to increase disk space. Do I have to play around with settings anywhere else as well?
Update:
I got following output from resize2fs command:
user#edudrona-prod-vm:~$ sudo resize2fs /dev/sda1
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 2620416 (4k) blocks long. Nothing to do!
Take a look at the documentation here.
resize2fs alone is not sufficient because what it does is resizing to fill the extents of the carrier partition, but your /dev/sda1 is still the old size. You need to resize that first. On some operating systems the whole root partition upsizing is done automatically on boot, so try rebooting to see if just that does the trick. Otherwise, you'll need to follow the manual steps. Be careful and make sure to back things up first.

Openstack Instance does not use the entire hard disk

I created new vm instance using "Ubuntu Server 10.04 LTS (Lucid Lynx) - 32 bits" image and m1.small falvour which has 20 GB Disk (OpenStack Icehouse). When i logging to the vm and run df -h , I found that the VM does not use the entire assigned HD. The command results are shown as the following:
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 1.4G 595M 721M 46% /
none 1005M 144K 1005M 1% /dev
none 1007M 0 1007M 0% /dev/shm
none 1007M 36K 1007M 1% /var/run
none 1007M 0 1007M 0% /var/lock
none 1007M 0 1007M 0% /lib/init/rw
The "fdisk -l" shows the DH size is 20 GB:
Disk /dev/vda: 21.5 GB, 21474836480 bytes
4 heads, 32 sectors/track, 327680 cylinders
Units = cylinders of 128 * 512 = 65536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000cb9da
Device Boot Start End Blocks Id System
/dev/vda1 * 17 32768 2096128 83 Linux
I need the vm to take the full space assigned to it. Any idea how could I fix it? I want the solution to be applied on each vm I create, so I do not want to manually update the VM after instantiation. I also must use 10.04 image ( can not upgrdate to 14.04)
The problem here is the image. I grabbed that one and ran it up, it's pretty simple to run a
sudo resize2fs /dev/vda1
which will resize the filesystem to the size of the partition, which seems to be 2GB. Beyond that, you have to increase the partition size. For that I think you're probably best off using virt-resize, there are some good howto's out there e.g. askubuntu, in essence:
SSH into your openstack controller node
source keystonerc_admin (or whatever yours may be called)
nova list --all-tenants | grep <instance_name> or just grab the server guid from horizon
nova show <server_guid> and note which nova host your machine is running on. Also note the instance name (e.g. instance-00000adb)
SSH into that nova node
virsh dumpxml instance-00000adb and look for the image file. On mine, this is /var/lib/nova/instances/<server_guid>/disk but that may not always be the case?
yum install libguestfs-tools
truncate -r /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk.new
truncate -s +2G /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk.new
virt-resize --expand /dev/sda1 /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk /var/lib/nova/instances/d887249a-0d95-473e-b4f2-41f71df4dbb5/disk.new
mv disk disk.old ; mv disk.new disk
NB - mine didn't quite work when I booted that up again, not got time to investigate yet but it can't be far off that, and hopefully this helps.
Once you've managed to boot that up again, then you can shut it down and create a snapshot from horizon. You can then use that snapshot just like any other image, and launch all subsequent VMs directly from there.
HTH.

Resources