Question regarding K22301343, extend /var/ folder after upgrade..
Hi all! We´ve been looking to extend the space of /var/ as it´s causing all types of problems for us when it´s gets full (which happens all the the time). So I´ve been reading and found this article, https://my.f5.com/manage/s/article/K22301343. We´re doing an upgrade at the same this so does anyone know if the /var/ needs to have been extended previously before doing this?? /Kim37Views0likes1Comment/var/ directory running out of space
I'm getting a broadcast message on the bash CLI that warns me about the /var/ directory running out of room. 011d0004:3: Disk partition /var has only 14% free There are four Tomcat files of identical size taking up almost a GB of space, but I don't know what purpose they serve. -rw-r--r--. 1 tomcat tomcat 240192271 2017-11-05 19:51 1509911444508.upload -rw-r--r--. 1 tomcat tomcat 240192271 2017-11-05 10:46 1509878765278.upload -rw-r--r--. 1 tomcat tomcat 240192271 2017-11-05 10:39 1509878372606.upload -rw-r--r--. 1 tomcat tomcat 240192271 2017-11-05 10:38 1509878267154.upload Does anyone know what the purpose of these files are, and whether or not it's safe to remove them?229Views0likes1Commentarg-ex-out using over half of space on partition
Hi, I'm getting the error message, that my F5 has 0% free space - this sucks. I've noticed that this space is used mostly by /var partition: /dev/mapper/vg--db--sda-set.12--hf1._var 3.0G 2.8G 23M 100% /var ` I've found a file named arg_ex_out that uses 1,8G of disk space, and I have no idea what this is. My other F5 (active in HA configuration) has the same file, but "only" around 650M big. The content of the file seems to repeat itself over and over and looks like this: `---- Command Line Args ---- ::ffff: 53 ---- Environment Args ---- ARGS_I= MON_INST_LOG_NAME=/var/log/monitors/SHARED_m_dns-SHARED_2-53.log MON_TMPL_NAME=/SHARED/m_dns NODE_IP=::ffff: NODE_NAME=/SHARED/ NODE_PORT=53 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/contrib/bin:/usr/local/bin:/usr/contrib/sbin:/usr/local/sbin:/usr/libexec RUN_I=/Common/arg_example TMOS_RD=2 = ---- End Args ---- ---- Command Line Args ---- ::ffff: 53 ---- Environment Args ---- ARGS_I= MON_INST_LOG_NAME=/var/log/monitors/SHARED_m_dns-SHARED_-53.log MON_TMPL_NAME=/SHARED/m_dns NODE_IP=::ffff: NODE_NAME=/SHARED/ NODE_PORT=53 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/contrib/bin:/usr/local/bin:/usr/contrib/sbin:/usr/local/sbin:/usr/libexec RUN_I=/Common/arg_example TMOS_RD=2 = ---- End Args ---- This repeats over and over again - judging by the filesize quite a lot. Perhaps it's some sort of external monitor? Any ideas? I'll be needing to upgrade the devices quite soon, I guess I'd need the disk space639Views0likes3CommentsDeleting .pcap files in "/var/tmp/"
Hello everyone! I'm running an HA pair of Big-IP units (BIG-IP 12.1.2 Build 0.0.249 Final) and I need to take packet captures now and then. I'm just wondering if it's safe to delete the capture files once I'm done, like from the CLI? Could I just [cd /var/tmp] and then [rm capturefile.pcap] ? Thanks!Solved1.5KViews0likes2CommentsF5 BIG-IP LTM VE - disk space issue
We do have a cron job running which updates a CRL file on regular basis in order to allow F5 to use up to date CRL file for verification of client certificate during mTLS. What we have noticed is, that the HDD space is constantly being filled up. We did some investigation and we found out, that there are always files being created in the ./config/filestore/.trash_bin_d/ folder Please see below an example ls -lh ./config/filestore/.trash_bin_d/.backup_1597885592_196_d/Common_d/certificate_revocation_list_d/:Common:trust2408-full_88715_317 ls -lh ./config/filestore/.trash_bin_d/.backup_1597885592_196_d/Common_d/certificate_revocation_list_d/:Common:trust2408-prod_79040_294 trust2408-prod / trust2408-full are the certificate revocation lists created by the script. This is causing, that the file system below is full and F5 can no longer operate properly Here is a difference within 24 hours Status from 19/08/2020 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg--db--vda-set.2._config 2.1G 467M 1.5G 24% /config Status from 20/08/2020 Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg--db--vda-set.2._config2.1G805M1.2G41% /config I see that there are 10 files generate in less than 24 hours, each file has 43M. At the end of the day it will eat up all free space and cause F5 to not function properly any longer. I would expect, that these files which are in "./config/filestore/.trash_bin_d/.backup_nnnn " foler are automatically removed by F5 on regular basis. Or am I missing anything here? We do have 4 F5 load balancers which have this script enabled and only 2 of them have this issue. All the setup is the same. Has anyone experienced anything similar? Any advice is highly appreciated.601Views0likes2Comments