var/log filling up super fast

    • var/log filling up super fast

      It all started with me having a problem logging into OMV, i search this forum and found a solution that worked which is to delete all files in /var/log because the drive was full.

      Shell-Script

      1. find /var/log -type f -delete

      This allowed me to login to the control panel, but /var/log will fill up again quickly, often within 12 hours.

      Just this morning when i was trying to log into the control panel. /var/log used 1.2GB of space, and that was not enough for the control panel to allow me to login.

      Shell-Script

      1. du -sh /var/log

      So is there a way to fix this problem?
      I've read that there is something called logrotate, i didn't get how to use it so i have not tried it.
      Thanks.

      Services running:
      - miniDLNA
      - Syncthing
      - SMB/CIFS
      - SSH

      Hardware:
      - Raspberry Pi 3
      - 32GB sd card
      - 1TB usb harddrive

      OMV version 3.0.73 (Erasmus)
    • deleting all logs is not a good idea. You should look at the logs to see if there is something causing the error. Updates (if there are many) can also fill the drive.
      omv 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Are you sure you're using the entire capacity of your 32GB SD card?

      You can use Gparted (a bootable CD version of it) with a standard PC. Before you boot into Gparted, have your SD card plugged in a media slot so it's recognized, then look at the partitions on your SD card.

      I moved from an 8GB SD card to a 16GB for the same reason - I couldn't log into the GUI. But, after writing the 8GB image onto a 16GB card, I had to use G-parted to enlarge the partitions to use the additional space.
      __________________________

      My problem, BTW, appeared to be temp files created by UrBackup in the process of imaging a client. There were numerous failures. After the first success, the temp files purged.

      If there's a similarity here (and this is pure speculation), I'd look at where Syncthing may be writing temp files and / or creating out sized logs that may not be self-purging.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • Enlarging the drive is not a soultion for the problem. the impact just comes later...

      Axaka: Do

      Source Code

      1. ls -lhatrS /var/log


      and find out, whats in den biggest files. Work on the cause.

      Have a look at

      Source Code

      1. /etc/logrotate.conf
      its most self explaining.

      I do not delete actual files in /var/log (see ryecoaaron above), I do something like

      Source Code

      1. cat /dev/null > /var/log/daemon.log
      2. cat /dev/null > /var/log/syslog
      3. cat /dev/null > /var/log/messages
      4. cat /dev/null > /var/log/kern.log
      You can delete *.1 and *.gz

      HTH
      --
      Get a Rose Tattoo...

      HP t5740 with Expansion and USB3, Inateck Case w/ 3TB WD-Green
      OMV 2.2.14 Stone burner i386|3.2.0-4-686-pae
    • Hey, is there a good way to read the logs. Locating the files on SSH and reading them with nano is so tedious.


      [IMG:http://i.imgur.com/YZpyXge.png]
      When i try to unmount /dev/mmcblk0p3 to delete it and expand the filesystem for /var/log.
      But when i try to unmount i get this error:
      Display Spoiler

      Error #0: exception 'OMV\Config\DatabaseException' with message 'The XPath query '//system/fstab/mntent[(((fsname='/dev/mmcblk0p3' or fsname='/dev/disk/by-id/mmc-SD32G_0x0150860f-part3') or fsname='/dev/disk/by-path/platform-3f202000.sdhost-part3') or fsname='/dev/disk/by-uuid/fa36508a-b3c4-4499-b30a-711dd5994225')]' does not return the requested number of 1 object(s).' in /usr/share/php/openmediavault/config/database.inc:172 Stack trace: #0 /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc(926): OMV\Config\Database->getByFilter('conf.system.fil...', Array, 1) #1 [internal function]: OMVRpcServiceFileSystemMgmt->umount(Array, Array) #2 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array) #3 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('umount', Array, Array) #4 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('FileSystemMgmt', 'umount', Array, Array, 1) #5 {main}


      Can i expand the file system /var/log is on in the control panel, or should i use Gparted, or is there a easy way to do it with the terminal?
    • I used a bootable Gparted CD on a standard PC.

      Flash card partitions, partition allocation, etc., works just like it does with spinning hard drives.

      BTW: leave *blk0p1, labeled "boot" alone.

      I had to move one partition, in your case *blk0p3 (to the right and toward the end), then I enlarged both *blk0p3 and *blk0P2. The partition you're particularly interested in *blk0p2 labeled "omv".

      *blk0p3 doesn't need what you have allocated to it. 4GB or maybe 6GB would work fine.

      Enlarge *blk0P2 (labeled ovm) to at least 8GB or more.
      ________________________________________________

      However, Dropkick Murphy is right.

      You may have a problem that needs to be addressed. In my case, the increasing number of temp files ceased to be a problem when the imaging operation was successful, so the problem resolved itself. (At that point, I saw a notable decrease in the size of the omv partition.)

      In your case, something else is going on, but resizing the partition will kick the can down the road, giving you some time to figure it out.

      (*Note, before messing with partitions, you might want to think about cloning your SD card. Resizing was easy, straight forward, and uneventful but anything can happen.)
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • Oh, and you can read many of the system logs in the GUI under DIAGNOSTICS, system logs.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)