/var/log is a directory, not a file. It contains log files from a number of different things, many of them relating to the OS, rather than FreePBX.
Typically you run logrotate, from a cron script, but the details depend on the specific log file.
How much log file you keep is a policy decision depending on how far you need to go back in time to analyze a problem, and, again will depend on the particular log file.
You look in the directory and find which files are getting large, do a search to find out how important they are to you. If they are FreePBX related, come back here. If they are OS related, consult information on the OS.
If the OP is confusing directories and files, I think they will have even more trouble with sub-directories. Only the files take up significant space, and the files in /var/log/asterisk will be included in
My real points were that the space is in the files, there is more than one file, not all of those files are the responsibility of FreePBX.
The offending file /dev/mapper/pbxvg0-lvvarlog is tripping email alerts. I understand that there is a way to configure the size of the file and how far back it will save the old log files (rotation). Is there a good reference to guide me through this, or can I ask what the line-by-line commands are so I can fix this?
There’s already a log rotation file if you did an official install of FreePBX v17. Are you saying a single file is getting too big? Because the directory space filling up just isn’t from the active log files there are the rotated log files as well. Outside of saying “My disk is getting full” you haven’t really shown/explained what is taking up the space or if there are rotated files.
This isn’t a normal file either. It represents a disk partition, and is almost certainly of fixed size.
Basically the questions you are asking suggest you have no understanding of logging and filesystem structures, on Linux, and probably not, to the necessary detail, on Windows either. I think you need to hire someone with the appropriate knowledge (or present a case here as to why someone should do the work pro bono). Generally people providing free support are only interested in things that the requestor might reasonably have not known about, not in dealing with the basic debugging steps that anyone analyzing a problem needs to know.
Basically logs provide information that can help a manager to understand the way the system is operating (and may also capture information used for billing). Your statistics are only telling you that the total of all your log files is reaching the limit Either something has gone wrong with the measures used to remove old entries, or some events are occurring that are creating a lot of loggable events. In the latter case, you need to find the specific file that has become excessively large, not just the filesystem (which basically only tells you that you are dealing with a large log file) and look inside it. It will contain messages about those events. Most of the files will be plain text, or simply compressed plain text files, although newer Linux systems also have files that require a special tool (journalctl) to format them.
In terms of a purely symptomatic approach, any normal file subordinate to /var/tmp which ends in .1, or .z, can be removed with no more risk than that you might destroy evidence of the root cause. Other normal files subordinate to it an be removed, but the removal might not be complete until the system is rebooted, and there is a risk that they will get recreated with the wrong ownership, or the recreation will fail.
Removing sub-directories may break logging until they are manually recreated, although some may get recreated if found to be missing.
I found on our installation a number of logfiles in /var/log/asterisk/ that were not in /etc/logrotate.d/asterisk to be rotated.
I would recommend you read up or ask someone to help that knows linux fairly well to set them up for how you want to retain those logfiles. I tweaked our config file to include those files that were not being rotated and it cleaned itself up overnight like it should.
Here is what I ended up with on our installation so far:
That work would make for some nice first issue diffs in our GitHub repos… modules have hooks for logrotate actions, primarily to add configuration files in to the /etc/logrotate.d/ directory, e.g.
May or may not be related, but in general you should go into the log settings on FreePBX and disable debug and verbose. For some reason that is still the default on a new install. It should not be imo.
Debug should normally be off, as most system managers won’t be able to use it effectively, but verbose comes in multiple levels, and I’d certainly want it partially enabled.