Regarding parallel rc, there's also https://reviews.freebsd.org/D3715. Last time I've tried it worked just fine, apart from script output messages being all messed up due to parallel execution.

So, what's the status on this?

If your init is broken, your theoretical wrapper would probably be broken in the exact same way. It's just another moving part that can cause problems. Moving it into the kernel, on the other hand, is intuitive to the user.

I agree that a separate application would be more elegant. However, it would make it more complicated from the user point of view - the approach I took doesn't require the user to learn anything new; the init_path option existed since forever, and there are no special userspace tools to remember about. Also, we kind of already have that: it should be possible to get init(8) to do exactly that, although I don't exactly know how.

Add O_NONBLOCK and do some cleanups.

Handle both "ufs" and "ffs" names.

The special case of checking the filesystem is added to reduce the other special case - the one for / - so it doesn't apply if the filesystem doesn't match. I kind of agree that "mount -u /" shouldn't be special, but as I've said - there might be something out there that will get broken by removing it. So instead I'm trying to just fix the case that's clearly broken (it results in mount(8) executing something like "mount_nfs -o remount,rw /dev/ada0 /") and not touching others.

Looks good. You might ask for testing in the freebsd-stable@ thread, "vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)".

I don't have a slightest idea why the special case is required. But it might be, and removing it altogether might break somebody's system. Adding additional condition is much less intrusive, and thus safer.

Okay; Alex explained to me what it actually does. Geez, make(1) is hard...

Okay. But then what exactly is the purpose of the change, compared to eg just adding "-v" to the code currently in the tree?

I (believe I) understand the problem. I'm not sure what the patch does, though. Where's the "-v" there?

So, while the problem pointed by Rod is real, I don't really see no easy way to fix it. Meanwhile, this patch improves stuff a lot for the common case and shouldn't make matters any worse in the other case. So, I think I'll just commit it, noting the potential problem with resizing after logging in.

Bryan, does this look ok to you? Thanks!