In contrary to your belief, it is possible for System V runlevel 1 (a la init 1
) to have some running services, which may hog your /var
directory.
Since you neither elaborate on which kind of system/distribution you are using, nor give ps auxfww
output; I'm going give a generic, sure-fire— but also dirty and dodgy advice...
To boot a GNU/Linux system without any program but your shell, boot your machine with init=/bin/sh
parameter appended to the end of kernel command line.
Without any other program running, this is an ideal environment to commence your /var
relocation operation.
But there are few things you need to take note of...
- Beware that this is a dodgy thing to do, only resort to this if it cannot be done in other ways.
- The shell will be a root shell, and likely to have neither command history nor line editing.
- Only one console will be available; no pressing Ctrl+Alt+F2 if you got stuck.
- Job control will not work; no pressing Ctrl+C to stop runaway program.
$HOME
directory location will be set to /
(rather than the usual /root
); so avoid doing things that write to your home directory.
- Do not
exit
from your main shell. (Doing so will halt your system with kernel panic)
And don't forget these operational safety procedure...
A less-dodgy alternative is booting your system with a GNU/Linux boot disk, and do your moving operations from there of course.
lsof
to see open files, but since/var
is used for lots of state stuff like pidfiles you're going to have to shut down a lot to do all of /var. Consider moving only the big parts of var ( you haven't told us what that is, but say /var/log or docker files) . Easier to stay up that way. Be careful with this, there might be some boot time deps on /var being there/var
and change/etc/fstab
to mount your new partition to/var
. That should do the trick./
and/var
on different filesystems...