All, The description of the killprocs script is that it "kills processes so that we can unmount disks cleanly." However, it causes issues like bug #371625, which seems to be exactly the type of issue it is trying to avoid. Also, why do we need this script at all on linux if we do not need it on the bsds (we do not install it there)? Should we consider removing this script given these concerns?
Another concern to add to the llist is that it uses killall5, which is part of sysvinit, so technically openrc requires sysvinit to be present to work correctly.
i dont think removing this is an option for exactly the reasons mentioned. this is also how sysvinit has acted since the beginning. so if we have just one bug for the decade+ of using this logic (while addressing many more), i'd say that's a pretty good track record.
(In reply to comment #2) > i dont think removing this is an option for exactly the reasons mentioned. Please elaborate. How do the reasons that I think removing it might be something we should do back your position for keeping it? It causes bugs with file systems like ntfs3g because it force kills the ntfs3g process before the file system can be unmounted. The bsds do not need it, so why does linux? > this is also how sysvinit has acted since the beginning. I do not understand your statement here. sysvinit and openrc are two separate things. If we do decide to keep killprocs, it should be rewritten so it doesn't use killall5. > so if we have just one bug for the decade+ of using this logic (while > addressing many more), i'd say that's a pretty good track record. Maybe, but also remember that bl1 was o/s specific and openrc is not. So the things that have been done for a decade or more might need to be re-evaluated given openrc's new design.
you already mentioned them. we cant have lazy processes hanging around keeping handles open to mount points (net/local/etc...). my sysvinit commit had nothing to do with killall5. our boot process has always killed things ... iirc, sysvinit itself took care of sending signals, but now openrc does it. i dont know how bsd works. you'd have to find someone on bsd. i dont think "the new design" is relevant to the issue that this is solving. fuse is simply an odd edge case as we never had "filesystems in userspace" to worry about before.
Looking at the man page for shutdown, sysvinit still sends the signals, so I'm wondering why openrc sends them again with the killprocs script in the first place? Since the signals are still sent by shutdown, wouldn't that be another reason to get rid of killprocs?
track back the history in git. it would suggest that no, we should not get rid of this. see bug 168977 and bug 177689 which specifically are fixed by it.
Created attachment 284057 [details] fix-killprocs.patch In that case, I would like to propose this patch for killprocs. If sysvinit is not installed on the system, killall5 will not be present. This patch makes sure that killprocs returns a successful exit code in that case.
we shouldnt be hardcoding paths. and if we're going to require killall5 here, then why not simply force people to remove it from their init.d runlevel ?
Honestly I would prefer to not use killall5 at all, but I'm not sure how to rewrite killprocs to not use it.
This has been fixed since 0.27.0, with the following commit: https://github.com/openrc/openrc/commit/44bac3c3798f7eb9186c3ea8774552aa191bfae7
