shutdown busybox and start another PID1 process

[Sam Liddicott]

Don't forgot umount -fl which pretends to unmount now but actually does it
as soon as all files are closed.

Not sure right now if busybox supports it.

Sam
On 10 Aug 2014 22:51, "Laurent Bercot" <ska-dietlibc at skarnet.org> wrote:

> I don't quite understand what you are suggesting.
>>
>
>  Ah, I'm sorry, I hadn't realized you were not the OP, and I have
> replied as if you were trying to bring up a system - but you are
> just trying to shut it down.
>
>  Well a shutdown isn't really something I've mastered. I've always
> considered it was easy: politely ask processes to stop, then ask a
> bit less politely, then nuke everything, then unmount the
> filesystems, done. Nothing fancy here.
>
>  But indeed, FUSE daemons make it a bit trickier - you have to
> shoot stuff in the right order and interleave unmounts with kills.
> I have no expertise to share though - *you* are, probably, the
> local expert. :)
>
>
>  gentle by doing a TERM kill before I pivot_root to let children
>> spawn.  That's an easy modification.
>>
>
>  I don't understand why you would pivot_root to shutdown. Who
> cares what your rootfs is, since the system isn't going to live
> anyway ? I'd even argue that you want to keep your current
> rootfs: it's been proven to work (since the system was live on it),
> it's functional and full of utilities you may need, whereas
> switching to a new rootfs is always error-prone and cumbersome,
> you need a new set of utilities, etc. It feels needlessly complex
> to me not to use the rootfs you have.
>
>
>       pkill [--signal <signal>] -v <regex>
>>
>
>  Be aware that pkill, pgrep et al. all perform a /proc scan, like
> killall5 and similar utilities. They will definitely slow down your
> shutdown process if you use too many of them. I guess there's no
> choice when you have to do complex stuff, but I'd try to reduce
> their use to the strict minimum.
>  My approach would probably be to try something like:
>  - Before killing anything else, do the following atomically:
>    * find processes holding an open file in a FUSE mount, with
> lsof and /proc/$pid/smaps and things like that
>    * kill them
>    * unmount the FUSE filesystems
>  - nuke from orbit, there's nothing left preventing me from doing it
>
>
>  I agree.  ISTM that doing "kill -TERM <pids>" and then waiting
>> a few seconds (if needed) before the pivot_root is a simple
>> and gentle solution.  I'll still follow up with a "kill -TERM"
>> and then "kill -KILL" after the pivot_root.  As you have made
>> me realize, killing after a pivot_root is an effective way
>> of dealing with the child problem.
>>
>
>  Well I still don't understand why you want a pivot_root at the end
> of your system's lifetime. It's like taking a very old and terminally
> ill person to a hospice instead of letting them die at home where
> they have lived all their life. Home is working for them, why change
> what works at this point ?
>
> --
>  Laurent
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140810/79ca292e/attachment-0001.html>