And how should I restore BAU?
No one was using it since I installed a few days, except for a handful of test calls between my handful of test SIP extensions, half a dozen each, for up to 10 min each. Since then it was idle for a few days. This morning I am alerted to it being non-responsive and see the below.
Your disk drive is at 100% used. You need to free up space on the system.
Sorry, but my only reaction is ‘no $h1t’. I know obvious when I see it, after 30+ years in senior positions in IT.
This is a totally unfamiliar to me, black-box system, and I come here for expert opinions of those, who’ve been dealing with it for years, unlike me. Generic suggestions like ‘fix your system’ only cause raised eyebrows and blank stares from me: this is not MY system. I’ve done very little configuration through the admin UI, and I’ve never seen a Linux system self-destruct so frequently and so quickly. Need specifics.
What writes to / so much and so quickly, in freePBX?
Great, so I’m sure you cleared up the disk space and tested again? Are you still getting errors from Redis or for the database after you clean up the disk space?
Outside of that it looks like you have around 7GB of free space over all so the drive doesn’t appear to be that big. Without see what the log files look like, such as which one has grown the largest, it is hard to say where the issue really is.
However, the system is never truly idle. If you have devices registered to it, that’s going to generate log entries, it’s going to generate traffic on the system. There’s cron jobs running hourly, nightly, weekly. There are other service daemon’s running to support all the features of the PBX.
So you posted help showing REDIS and SQL errors and the fact you have 100% disk space in use. The logical answer to that is clear up the disk space and test again. Do the problems still exist? If they do, then we need to look at what could be causing these issues.
How big is the drive in the system? You really should be using anything less than 25GB and really should probably have 50GB just in case.
In my experience, either logs or recordings. du -sh /var/* | sort -h should shed some light. If not, you can always use a find with a mtime of -1 to see what’s been changing over the last day.
If your system is on the Internet and not firewalled a bit you are probably accumulating a lot of logging from scanner activity. Start in /var/log/asterisk.
/var/log was the 1st thing I checked. Minimal growth, that certainly does not account for gigabytes that were added over a few days. A handful of backups accounted for 100s of MBs. Nothing spectacular. My test users did not record anything other than 1 30s VM.
How big is this driver overall?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.