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.

    Bash
    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.


    Bash
    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)

    • Offizieller Beitrag

    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 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    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.

  • Enlarging the drive is not a soultion for the problem. the impact just comes later...


    Axaka: Do


    Code
    ls -lhatrS /var/log


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


    Have a look at

    Code
    /etc/logrotate.conf

    its most self explaining.


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


    Code
    cat /dev/null > /var/log/daemon.log
    cat /dev/null > /var/log/syslog
    cat /dev/null > /var/log/messages
    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 5.5.23-1 Usul i386|4.19.0-9-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.




    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:


    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?

    • Offizieller Beitrag

    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.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!