Everytime antiX shuts down, it does a bunch of things and when completed, it unmount root and turn off. Why that can happen? Why 'mount' is always killed last? Can I make 'mount' to be killed first rather than last, which will cause error? Or can I make another program to be killed last before the computer turned off?

if a live image is loaded entirely into ram, the distro can unmount the drives first-- or at least after syncing (which umount will do, but either way) and when its done with any programs or drivers that were loaded from the drives to be unmounted.

however / is / whether its a mountpoint for an image loaded first in ram or first on the drive. its where various things are mounted to, including /sys and /dev and /proc and /tmp ...it cant umount / until its done doing everything else.

if youre running in ram and can make certain that all persistent partitions/volumes/block devices are unmounted, you can call poweroff -f ...a good question would be"what happens if i keep calling poweroff -f without unmounting all physical devices first?" i wouldnt-- but at least sync first! IF YOU DAMAGE something this way, you will know why not to.

figosdev wrote:if a live image is loaded entirely into ram, the distro can unmount the drives first-- or at least after syncing (which umount will do, but either way) and when its done with any programs or drivers that were loaded from the drives to be unmounted.

however / is / whether its a mountpoint for an image loaded first in ram or first on the drive. its where various things are mounted to, including /sys and /dev and /proc and /tmp ...it cant umount / until its done doing everything else.

if youre running in ram and can make certain that all persistent partitions/volumes/block devices are unmounted, you can call poweroff -f ...a good question would be"what happens if i keep calling poweroff -f without unmounting all physical devices first?" i wouldnt-- but at least sync first! IF YOU DAMAGE something this way, you will know why not to.

How about normal installation? If 'mount' is killed first during shutdown, then the filesystem isn't unmounted cleanly, right? Can I somehow, add a program and set it to be killed last?

mount is not a process, its a utility that interacts with the kernel. the part of"mount" that is like a process is the kernel. but really, the kernel isnt a process either.

admitttedly while mount is running, its a process. but after you run it, it exits moments later. you cant kill it, because it isnt running. its like ls or find-- you can kill them while theyre running, but they do one thing and then exit anyway.

i think what you want is to learn about the rc.d scripts and shutdown handling. though until i understand why youre focused on"mount" its difficult to say. are you trying to optimise the shutdown process? whats the actual goal, rather than the step (kill mount) youre trying to achieve?

figosdev wrote:mount is not a process, its a utility that interacts with the kernel. the part of"mount" that is like a process is the kernel. but really, the kernel isnt a process either.

admitttedly while mount is running, its a process. but after you run it, it exits moments later. you cant kill it, because it isnt running. its like ls or find-- you can kill them while theyre running, but they do one thing and then exit anyway.

i think what you want is to learn about the rc.d scripts and shutdown handling. though until i understand why youre focused on"mount" its difficult to say. are you trying to optimise the shutdown process? whats the actual goal, rather than the step (kill mount) youre trying to achieve?

my root installation is handled by qemu-nbd and it's frustrating that qemu-nbd is the process that get killed first on shutdown, resulting unsafe shutdown. How can I somehow, let the qemu-nbd to be killed last so my system can shutdown safely?

ok, that brings me back to"i think what you want is to learn about the rc.d scripts and shutdown handling" though here is a thought:

if you have enough ram to load antix into ram, then you can unmount everything BEFORE you shutdown, and then youre probably fine. im not familiar with qemu-nbd (i have it installed, ive never heard of the nbd protocol) but this is one way to possibly fix your problem (just a guess) plus you might want to ask wherever they support qemu, what they recommend.