why are init's arguments wiped ?

Isaac Dunham ibid.ag at gmail.com
Fri Jan 29 16:32:43 UTC 2016


On Fri, Jan 29, 2016 at 08:27:19AM +0100, Nicolas CARRIER wrote:
> Thank you for your answer.
> 
> Even if I'm using linux, I want the solution to work in the context of init
> being launched as a pid 1 of a pid namespace, which is my main use case.
> In this situation, the kernel's command line can't be changed as it's the
> one of the host PC.
> 
> Luckily enough, I have several ways to achieve what I want, but in my
> opinion, using init's arguments would have been the most elegant option.
> 
> I'm really interested in knowing which is the real reason behind this
> feature and if there is any chance that a patch would be accepted, to
> either remove, or allow to disable this part of the code.

A patch to optionally disable a feature is usually acceptable, it seems.
I can't speak for the maintainer, though.

However, I seem to recall that commonly, options like 'foo=bar' get into
the environment.
This would be doable by means of a script that execs busybox init,
something like this (untested, doesn't handle -...):

for opt in $#; do
    case "$opt" in
	(*=*) eval "$opt"
	;;
    esac
done

exec busybox init $@


HTH,
Isaac Dunham


More information about the busybox mailing list