On 29/01/2016 08:27, Nicolas CARRIER wrote:
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.
But then the solution is easy: start your pid 1 as a script that takes arguments, does what you want with them, then executes into init. The "init" program is nothing magical. It's one of a thousand alternatives that are suitable for the traditional "duties of init" (does not die, subreaper, supervises at least one other process). And as long as your pid 1 executes into something that fulfills these duties, your system will work.
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.
"init" was not made to take or use any arguments, and that dates back to decades ago. It's just the way it was designed. But nothing prevents you from writing a trivial shell wrapper that does take arguments and runs as your starter init. And that is, IMO, the most elegant solution (because it's the simplest).
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.
The real reason is the one you read in the comment: any arguments would show up in the "ps" output after the "init" name, and that would be ugly and inconsistent with the behaviour of other "init" implementations. Since init is not supposed to take any arguments, this normally doesn't matter. If taking arguments matters for your use case, then "init" is not the program you want to run as your pid 1 - not in the first place anyway. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
