0

I've got /var mounted as a separate partition and although it's 2Gb it keeps filling up quite often. Using something like apt clean only frees 100m at best. So I would like to move it to the root partition. I wonder what is the easiest method to do it? I know that I can boot from a USB and do it (although not sure how) but I wonder if it is possible to avoid it and do it just from the current installation?

3

You should be able to move the contents from the /var partition to the / position on the fly. There is no special lock on it.

sudo cp -pr /var /var2
sudo umount /var
sudo rm -R /var
sudo mv /var2 /var

Then remove the line that mounts /var from /etc/fstab.

sudo nano /etc/fstab

If you receive an error /var: target is busy, you need to find out which processes are preventing unmounting of the device and stop them.

Disclaimer: I would still recommend doing this on a live system or from grub rescue. It should be safer.

  • Hi, thanks a lot, but I've got umount: /var: target is busy, when I try to umount var. – foxy123 May 7 '18 at 14:45
  • use a live sesson to do that or do it from grub rescue, not on a live system. Or make sure you are not currently in /var if you do, and have all services stopped that could use /var (apache, mysql, logging etc). – Rinzwind May 7 '18 at 14:47
  • But yes, of course it's safer to do it from a live system. OP just asked for a way how to do it from the current session. – pLumo May 7 '18 at 14:54
  • @xiota note that your edit actually now creates a /var/var2 directory. – muru May 7 '18 at 14:56
1

I don't think moving var will help you with your problem in the long run, in your particular case you might need to look at logrotate and the like, filling up your rootfs is a much bigger problem than filling up /var. I think that is a reason some people have a separate partition. Since the one tool, you'd think could handle that, quotas, is user / filesystem specific, and doesn't allow for the specification of a particular directory.

In my case, it just is perturbing to see error messages from the systemd during the shutdown because it can't unmount /var because it is in use by itself / the system log. Way more valid imo.

In general, it is insane to move an fs that is actively in use, making a copy while files are being written is bound to not work. And while Linux will let you delete files that are open, so-called "anonymous files"... see https://stackoverflow.com/questions/4171713/relinking-an-anonymous-unlinked-but-open-file for more on that... you won't be getting those writes. So be sure to check lsof and ensure as much as you care about is not writing to the fs. Some default users that come to mind, databases (MySQL, Mongo, Postgres, probably others), /var/log by like everything, /var/run especially on systemd systems. There is probably lots of important sh!t in /var. So be careful. DO NOT follow the other answers suggest to immediately rm -rf /var it and assume all is good. You can simply comment out the /var entry in fstab, so that it no longer mounts and add one that binds /newvar to /var. When you reboot and verify everything is still working, then you might consider deleting it, but really, check that stuff work. If you don't desperately need the disk space, leave it around for awhile, what is the harm? Make a backup? Whatever you do, don't immediately delete it unless you're a masochist, then I guess you would want to.

That being said, I empathize... I know it is crazy, but I rather google for ways to do it and wind up here telling you what I'm about to do instead of just rebooting hitting f12 and starting up a live cd, or just dropping to the rescue shell by appending rescue to my kernel command lines... probably because I am not using a bootloader, but still... efi shell is a thing, so lets just admit it is laziness, we both would rather spend 16 hours fixing the system we broke than do that.

    # Probably completely pointless
    sync
    # Make a copy, but realize it is as of right now and thing are still being written, record the errors, so you have a better idea of what will be broken.
    cp -avPR /var /varnew 2>varnew.errs
    mount -o bind /varnew /var 

/etc/fstab

    #/dev/mapper/vgX-oldvar /var ext4 defaults 0 0
    /newvar /var none bind

May the flying spaghetti monster have mercy on your soul

    reboot
    # Check stuff and if you must format/lvremove whatever your old var
  • Incidentally, does anyone know why the heck mv doesn't have an option to merge with existing, or any sort of useful functionality? – Justin Mar 4 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.