> -Ursprüngliche Nachricht-
> Von: Laurent Bercot
> Gesendet: Freitag, 29. Januar 2016 10:13
>
> On 29/01/2016 08:27, Nicolas CARRIER wrote:
> > ...
> > 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
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
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
I quite agree with dietmar, concerning uglyness...
And concerning the replacement of init with a script, well, hum... :D
Is it even possible ? Won't it suffer from the lack of proc / sys and dev ?
Environment variables setup by init ?
What's more, there is a risk to spawn multiple processes (eval
Le 29/01/2016 17:32, Isaac Dunham a écrit :
for opt in $#; do
case "$opt" in
(*=*) eval "$opt"
;;
esac
done
exec busybox init $@
Isaac,
I understand what that the loop sets environment variables that
init will inherit, but what's the purpose of the $@ at
On Fri, Jan 29, 2016 at 06:10:10PM +0100, Didier Kryn wrote:
> Le 29/01/2016 17:32, Isaac Dunham a écrit :
> >for opt in $#; do
> > case "$opt" in
> > (*=*) eval "$opt"
> > ;;
> > esac
> >done
> >
> >exec busybox init $@
>
> Isaac,
>
> I understand what that the loop sets
On 29/01/2016 17:50, Nicolas CARRIER wrote:
I quite agree with dietmar, concerning uglyness...
That doesn't change the fact that it's the behaviour of every
init binary since 1970 and that you should come with a better reason if
you want to change it, especially since it's so easy to
