why are init's arguments wiped ?

[Laurent Bercot]

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