Ubuntu - No space left on device Is it a lie or have I run out of inodes
Yesterday one of my development servers decided it was going to do some very strange things.Wordpress and other websites stopped working properly, I got session errors when trying to usePHPMyAdmin, I couldn't upload files through web forms (the server complained there was no temporary directory). So I logged in to try and work out what was going on. The temporary directory was there and had the correct permissions, however if I tried to create a file in it I was told:
$ touch /tmp/testfile
Unable to create file /tmp/testfile: No space left on device
So I must have run out of disk space, which is odd as I had loads last time I checked.
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 15G 8.5G 6.5G 57% /
devtmpfs 299M 112K 299M 1% /dev
none 308M 0 308M 0% /dev/shm
none 308M 64K 308M 1% /var/run
none 308M 0 308M 0% /var/lock
none 308M 0 308M 0% /lib/init/rw
/dev/sdc1 40G 6.4G 32G 17% /home
Oh, I have plenty of disk space! What the hell is going on then? As my server is an Amazon EC2instance my first thoughts were there was a problem with the block storage. So I spent an hour or so trying to find any clues in their forums and got nowhere.
After another few hours of scouring the internet for people having similar problems and finding nothing at all I was about to give up. As a last ditch attempt to find the solution I checked myMunin stats for the server and immediately I noticed that the inode graphs for one of the mounted disks had been rising steadily over the last few weeks and had just reached 100%!!!
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 983040 983040 0 100% /
devtmpfs 76490 1957 74533 3% /dev
none 78747 1 78746 1% /dev/shm
none 78747 34 78713 1% /var/run
none 78747 2 78745 1% /var/lock
none 78747 1 78746 1% /lib/init/rw
/dev/sdc1 2621440 13238 2608202 1% /home
So then, where are all these files? There must be thousands of them to be using up 100% of just under a million.
To count all the files in a directory and all it's subdirectories:
$ for i in /*; do echo $i; find $i | wc -l; done
Then you can narrow down your search by replacing the /* for any directory that has an unusually large number of files in. For me it was /var
$ for i in /var/*; do echo $i; find $i | wc -l; done
Eventually I narrowed it down to the reports being held by the Squid Proxy server report generator sarg so a simple fix was to clear out all the old reports and stop sarg from auto generating reports every day.
$ rm -rf /var/log/sarg/*
And thats it! Server fixed and back up and running without any problems. All I have to do is remember to keep an eye on any autogenerated logs and reports and make sure that old ones are actually being deleted!
【推荐】还在用 ECharts 开发大屏?试试这款永久免费的开源 BI 工具!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 软件产品开发中常见的10个问题及处理方法
· .NET 原生驾驭 AI 新基建实战系列:向量数据库的应用与畅想
· 从问题排查到源码分析:ActiveMQ消费端频繁日志刷屏的秘密
· 一次Java后端服务间歇性响应慢的问题排查记录
· dotnet 源代码生成器分析器入门
· ThreeJs-16智慧城市项目(重磅以及未来发展ai)
· .NET 原生驾驭 AI 新基建实战系列(一):向量数据库的应用与畅想
· Browser-use 详细介绍&使用文档
· 软件产品开发中常见的10个问题及处理方法
· Vite CVE-2025-30208 安全漏洞
2012-05-21 rhel 6使用lxc报错 :no ns_cgroup option specified
2012-05-21 [zz]RHEL 6.2配置本地yum源