Re: Fwd: why are init's arguments wiped ?

[Mike Frysinger]

On 02 Feb 2016 08:22, Nicolas CARRIER wrote:
> I used prctl from time to time to change a child's name, but I didn't
> think of using argv directly, to pass more information. In fact I
> discovered it was possible, when I asked this very question.

if you're using python, check out this module:
https://pypi.python.org/pypi/setproctitle

if you're using C, check out the source directly as it's all written
in C anyways and has lots of ports to different OS's.
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: why are init's arguments wiped ?

[Cathey, Jim]

>of course, when you say 1992, that is still "new" compared to
>UNIX systems that existed at the time.

Indeed.  Unix/init had been running for about 20 years by that time.

-mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Mike Frysinger]

On 01 Feb 2016 12:59, Cathey, Jim wrote:
> Some history, as I recall it:
> 
> Unix hard-coded "init" as PID 1, and (I believe) hard-coded the
> initial search path to "/bin" and "/usr/bin".
> 
> Unix didn't pass any command-line arguments _to_ init, because
> there was no environment from which they could come.  Most especially,
> the concept of run-level is an init concept, not a kernel concept, and it
> got it only from the inittab file, and not from the kernel in any way.
> 
> Linux only supports command-line arguments because _uboot_ (et al.) does,
> and between the two of them they conspire to have arguments that are
> meaningful to the kernel.  Which, as part of that, chooses to be able to
> pass some of them off to init.  This is all new behavior, when compared
> to Unix and several of its successors.

to be pedantic, i don't think the interface is that tied to the bootloader.
the linux kernel itself has long supported packing init args & env vars it
sees on its command line.  i see it in Linux-0.98.3 released in Oct 1992,
and at that time u-boot didn't exist :).  the fact that each arch has a way
to pass a command line in at its entry point is immaterial.  the kernel can
still pack its own copy and ignore the bootloader, or default to it if the
bootloader didn't pass anything useful in.

of course, when you say 1992, that is still "new" compared to UNIX systems
that existed at the time.
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Mike Frysinger]

On 01 Feb 2016 22:33, Didier Kryn wrote:
> Le 01/02/2016 18:10, Mike Frysinger a écrit :
> > it makes a lot of sense when you fork children that have specific purposes.
> > rather than just seeing the program's name 4 times, it's more helpful for
> > them to be broken up.
>
>  prctl() can be used for that, with the operation code PR_SET_NAME. 
> It does not change the command line.

right, but that has its own limitations:
- it's new to linux-2.6.9
- can only set the name
- is limited to 16 bytes
- can't change command line args

so we're still stuck with this behavior of modifying the argv mem directly :(
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Didier Kryn]

Le 01/02/2016 23:34, Mike Frysinger a écrit :

On 01 Feb 2016 22:33, Didier Kryn wrote:

Le 01/02/2016 18:10, Mike Frysinger a écrit :

it makes a lot of sense when you fork children that have specific purposes.
rather than just seeing the program's name 4 times, it's more helpful for
them to be broken up.

  prctl() can be used for that, with the operation code PR_SET_NAME.
It does not change the command line.

right, but that has its own limitations:
- it's new to linux-2.6.9
- can only set the name
- is limited to 16 bytes
- can't change command line args

so we're still stuck with this behavior of modifying the argv mem directly :(
-mike
IIUC your argument was there's a need to give sensible names to 
children. prctl() allows this *without* resorting to modifying the 
command line args. I don't find 16 chars (in reality 15) is short for 
the purpose.


Didier

Didier

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Mike Frysinger]

On 02 Feb 2016 00:09, Didier Kryn wrote:
> Le 01/02/2016 23:34, Mike Frysinger a écrit :
> > On 01 Feb 2016 22:33, Didier Kryn wrote:
> >> Le 01/02/2016 18:10, Mike Frysinger a écrit :
> >>> it makes a lot of sense when you fork children that have specific 
> >>> purposes.
> >>> rather than just seeing the program's name 4 times, it's more helpful for
> >>> them to be broken up.
> >>   prctl() can be used for that, with the operation code PR_SET_NAME.
> >> It does not change the command line.
> > right, but that has its own limitations:
> > - it's new to linux-2.6.9
> > - can only set the name
> > - is limited to 16 bytes
> > - can't change command line args
> >
> > so we're still stuck with this behavior of modifying the argv mem directly 
> > :(
>
>  IIUC your argument was there's a need to give sensible names to 
> children. prctl() allows this *without* resorting to modifying the 
> command line args. I don't find 16 chars (in reality 15) is short for 
> the purpose.

if you look at the examples i already posted, 16 is too small for every
one there.  when i've munged the `ps` listing in the past, i've also
easily run past 16 bytes.  your cases might be short, but that doesn't
mean every scenario is that way.
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Mike Frysinger]

On 01 Feb 2016 08:09, Nicolas CARRIER wrote:
> I wrote a little patch which adds the option not to wipe the arguments, but
> the result is a little bit odd, some 0 are inserted between "init" and the
> rest of the arguments. I must be because "/bin/init" is replaced with
> "init".
> So the proper patch should either :
>  * inhibit this argv[0] modification too
>  * perform a memmove to wipe those extra zeros
> 
> Which one do you think is best ?

what do you mean "some 0" ?  can you copy & paste the exact terminal
output you're seeing ?

argv settings has always been ugly in Linux ... the location of argv
is static as is the size.  there's no way to tell the kernel to use
a different location so you're force to screw with the existing mem.

that said, i would just start with the simple answer: don't mess with
anything at all.
-mike

--- a/init/init.c
+++ b/init/init.c
@@ -1139,11 +1139,13 @@ int init_main(int argc UNUSED_PARAM, char **argv)
}
 #endif
 
-   /* Make the command line just say "init"  - thats all, nothing else */
-   strncpy(argv[0], "init", strlen(argv[0]));
-   /* Wipe argv[1]-argv[N] so they don't clutter the ps listing */
-   while (*++argv)
-   nuke_str(*argv);
+   if (FEATURE_INIT_ARGV_REWRITE) {
+   /* Make the command line just say "init"  - thats all, nothing 
else */
+   strncpy(argv[0], "init", strlen(argv[0]));
+   /* Wipe argv[1]-argv[N] so they don't clutter the ps listing */
+   while (*++argv)
+   nuke_str(*argv);
+   }
 
/* Set up signal handlers */
if (!DEBUG_INIT) {


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Nicolas CARRIER]

"init" is 4 chars long, "/bin/init" is 9 chars long, so when I "remove" the
while (*++argv) ... loop, there are 5 extra bytes between "init" and the
content of argv[1].
In ps, the symptom is extra spaces inserted in the output, but the argv[1]+
args are shown "correctly"
In hexdump -C /proc/1/cmdline, 6 zeros instead of 1, are present between
the last char of "init" and the first of argv[1].

I think it's normal since the strncpy line doesn't bother with the rest of
the command-line which was to be wiped, in the end.

So my question was, do I #ifdef the whole cmdline modifications, including
that of argv[0] like you did, or do I let init modify argv[0], in which
case I'll have to memmove the rest of the command-line to get rid of the
unused extra bytes.

Personally, I prefer the first solution. I still don't get the point of
modifying a program's argument, be it init or not...

2016-02-01 9:00 GMT+01:00 Mike Frysinger :

> On 01 Feb 2016 08:09, Nicolas CARRIER wrote:
> > I wrote a little patch which adds the option not to wipe the arguments,
> but
> > the result is a little bit odd, some 0 are inserted between "init" and
> the
> > rest of the arguments. I must be because "/bin/init" is replaced with
> > "init".
> > So the proper patch should either :
> >  * inhibit this argv[0] modification too
> >  * perform a memmove to wipe those extra zeros
> >
> > Which one do you think is best ?
>
> what do you mean "some 0" ?  can you copy & paste the exact terminal
> output you're seeing ?
>
> argv settings has always been ugly in Linux ... the location of argv
> is static as is the size.  there's no way to tell the kernel to use
> a different location so you're force to screw with the existing mem.
>
> that said, i would just start with the simple answer: don't mess with
> anything at all.
> -mike
>
> --- a/init/init.c
> +++ b/init/init.c
> @@ -1139,11 +1139,13 @@ int init_main(int argc UNUSED_PARAM, char **argv)
> }
>  #endif
>
> -   /* Make the command line just say "init"  - thats all, nothing
> else */
> -   strncpy(argv[0], "init", strlen(argv[0]));
> -   /* Wipe argv[1]-argv[N] so they don't clutter the ps listing */
> -   while (*++argv)
> -   nuke_str(*argv);
> +   if (FEATURE_INIT_ARGV_REWRITE) {
> +   /* Make the command line just say "init"  - thats all,
> nothing else */
> +   strncpy(argv[0], "init", strlen(argv[0]));
> +   /* Wipe argv[1]-argv[N] so they don't clutter the ps
> listing */
> +   while (*++argv)
> +   nuke_str(*argv);
> +   }
>
> /* Set up signal handlers */
> if (!DEBUG_INIT) {
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: AW: why are init's arguments wiped ?

[Laurent Bercot]

On 01/02/2016 08:12, dietmar.schind...@manroland-web.com wrote:

Anyone doing engineering work should come up with a better reason
than something like "that's always been done that way".


 Oh, definitely. But I'm not the one engineering something here,
I'm the bad guy saying I don't like the suggested change.

 History and tradition *are* valid objections to change, because breaking
compatibility (if only compatibility of visual output) has a cost.
They're not powerful objections: if a historical design is bad, and
the new design brings obvious benefits, then it's entirely worth deviating
from tradition. But everything else being equal, if the new design isn't
strictly more powerful than the old one, then tradition may be worth
keeping.

 In the present case, the choice is between "wipe init arguments"
(historical) and "allow init to take arguments" (suggested change).
  Advantages of the historical behaviour: clean ps output
  Advantages of the suggested change: passing of information in the
init arguments via /proc/1/cmdline

 Given that /proc/1/cmdline is not a standard Unix way of passing
information, and that the OP's program would thus *only* work with
the new-and-modified busybox init under Linux, making this change
nothing more than a hack;
 Given that Unix already provides plenty of ways to pass information
from a process to its scions, and that the command line is only such
a way for programs specifically designed to perform chain loading,
which init is not;
 Given that I have suggested an *easy*, safe, portable and perfectly
Unix-ish way of accomplishing what the OP wants without having to patch
anything;
 Therefore, in this precise case, I don't think the change is worth it.

 Seriously. Accusing *me* of following historical behaviours for the
sake of it. :D

--
 Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: AW: why are init's arguments wiped ?

[Tito]

On 02/01/2016 01:29 PM, Nicolas CARRIER wrote:

"/proc/1/cmdline is not a standard Unix ..."

I absolutely don't know any other OS, be it Unix or not... But don't
they provide a way to access the command-line used to launch a program ?
In busybox's code at least, I see only one implementation of
read_cmdline, which reads the content of /proc/[PID]/cmdline.
 From that I conclude that only Unices having this file can have a
busybox ps implementation dealing with the command-line.

What's more, I don't think that erasing it's command-line is a "nice"
behavior for a program.
What if I want to debug how init was launched ? The way it behaves now
makes it impossible to know if a runlevel has been passed, how it was
passed, or even if we are launching the right init binary.
On some platforms I work on, there are 2 different init binaries, it
would be nice if performing a simple ps could assure me the right init
binary is used.


Hi,
is renaming them to init1 and init2 an option?

Ciao,
Tito


To conclude, I don't think that "allow[ing] init to take arguments" is
only useful for "passing of information in the init arguments via
/proc/1/cmdline". It is also a way to preserve informations passed by
init's father, whose motivations we can't foresee.

2016-02-01 11:55 GMT+01:00 Laurent Bercot >:

On 01/02/2016 08:12, dietmar.schind...@manroland-web.com
 wrote:

Anyone doing engineering work should come up with a better reason
than something like "that's always been done that way".


  Oh, definitely. But I'm not the one engineering something here,
I'm the bad guy saying I don't like the suggested change.

  History and tradition *are* valid objections to change, because
breaking
compatibility (if only compatibility of visual output) has a cost.
They're not powerful objections: if a historical design is bad, and
the new design brings obvious benefits, then it's entirely worth
deviating
from tradition. But everything else being equal, if the new design isn't
strictly more powerful than the old one, then tradition may be worth
keeping.

  In the present case, the choice is between "wipe init arguments"
(historical) and "allow init to take arguments" (suggested change).
   Advantages of the historical behaviour: clean ps output
   Advantages of the suggested change: passing of information in the
init arguments via /proc/1/cmdline

  Given that /proc/1/cmdline is not a standard Unix way of passing
information, and that the OP's program would thus *only* work with
the new-and-modified busybox init under Linux, making this change
nothing more than a hack;
  Given that Unix already provides plenty of ways to pass information
from a process to its scions, and that the command line is only such
a way for programs specifically designed to perform chain loading,
which init is not;
  Given that I have suggested an *easy*, safe, portable and perfectly
Unix-ish way of accomplishing what the OP wants without having to patch
anything;
  Therefore, in this precise case, I don't think the change is worth it.

  Seriously. Accusing *me* of following historical behaviours for the
sake of it. :D

--
  Laurent

___
busybox mailing list
busybox@busybox.net 
http://lists.busybox.net/mailman/listinfo/busybox




___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: AW: why are init's arguments wiped ?

[Nicolas CARRIER]

I was talking in general, to illustrate the fact that abandoning
information is not a good thing.
In my situation, things will work eventually, because our other init
process doesn't alter it's arguments.

2016-02-01 14:13 GMT+01:00 Tito :

>
>
> On 02/01/2016 01:29 PM, Nicolas CARRIER wrote:
>
>> "/proc/1/cmdline is not a standard Unix ..."
>>
>> I absolutely don't know any other OS, be it Unix or not... But don't
>> they provide a way to access the command-line used to launch a program ?
>> In busybox's code at least, I see only one implementation of
>> read_cmdline, which reads the content of /proc/[PID]/cmdline.
>>  From that I conclude that only Unices having this file can have a
>> busybox ps implementation dealing with the command-line.
>>
>> What's more, I don't think that erasing it's command-line is a "nice"
>> behavior for a program.
>> What if I want to debug how init was launched ? The way it behaves now
>> makes it impossible to know if a runlevel has been passed, how it was
>> passed, or even if we are launching the right init binary.
>> On some platforms I work on, there are 2 different init binaries, it
>> would be nice if performing a simple ps could assure me the right init
>> binary is used.
>>
>
> Hi,
> is renaming them to init1 and init2 an option?
>
> Ciao,
> Tito
>
> To conclude, I don't think that "allow[ing] init to take arguments" is
>> only useful for "passing of information in the init arguments via
>> /proc/1/cmdline". It is also a way to preserve informations passed by
>> init's father, whose motivations we can't foresee.
>>
>> 2016-02-01 11:55 GMT+01:00 Laurent Bercot > >:
>>
>> On 01/02/2016 08:12, dietmar.schind...@manroland-web.com
>>  wrote:
>>
>> Anyone doing engineering work should come up with a better reason
>> than something like "that's always been done that way".
>>
>>
>>   Oh, definitely. But I'm not the one engineering something here,
>> I'm the bad guy saying I don't like the suggested change.
>>
>>   History and tradition *are* valid objections to change, because
>> breaking
>> compatibility (if only compatibility of visual output) has a cost.
>> They're not powerful objections: if a historical design is bad, and
>> the new design brings obvious benefits, then it's entirely worth
>> deviating
>> from tradition. But everything else being equal, if the new design
>> isn't
>> strictly more powerful than the old one, then tradition may be worth
>> keeping.
>>
>>   In the present case, the choice is between "wipe init arguments"
>> (historical) and "allow init to take arguments" (suggested change).
>>Advantages of the historical behaviour: clean ps output
>>Advantages of the suggested change: passing of information in the
>> init arguments via /proc/1/cmdline
>>
>>   Given that /proc/1/cmdline is not a standard Unix way of passing
>> information, and that the OP's program would thus *only* work with
>> the new-and-modified busybox init under Linux, making this change
>> nothing more than a hack;
>>   Given that Unix already provides plenty of ways to pass information
>> from a process to its scions, and that the command line is only such
>> a way for programs specifically designed to perform chain loading,
>> which init is not;
>>   Given that I have suggested an *easy*, safe, portable and perfectly
>> Unix-ish way of accomplishing what the OP wants without having to
>> patch
>> anything;
>>   Therefore, in this precise case, I don't think the change is worth
>> it.
>>
>>   Seriously. Accusing *me* of following historical behaviours for the
>> sake of it. :D
>>
>> --
>>   Laurent
>>
>> ___
>> busybox mailing list
>> busybox@busybox.net 
>> http://lists.busybox.net/mailman/listinfo/busybox
>>
>>
>>
>>
>> ___
>> busybox mailing list
>> busybox@busybox.net
>> http://lists.busybox.net/mailman/listinfo/busybox
>>
>> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Ralf Friedl]

Nicolas CARRIER schrieb:

"/proc/1/cmdline is not a standard Unix ..."

I absolutely don't know any other OS, be it Unix or not... But don't 
they provide a way to access the command-line used to launch a program ?
In busybox's code at least, I see only one implementation of 
read_cmdline, which reads the content of /proc/[PID]/cmdline.
From that I conclude that only Unices having this file can have a 
busybox ps implementation dealing with the command-line.
Busybox is primarily intended for Linux. While some of the applets are 
Posix compliant, others are very Linux specific.


Traditionally, Unix doesn't provide a way to access the comand-line of 
another program. Programs like ps used to do it anyway, but they had to 
be set-uid to root so that they could access the memory of another 
process. The whole /proc filesystem is not part of traditional Unix.


What if I want to debug how init was launched ? The way it behaves now 
makes it impossible to know if a runlevel has been passed, how it was 
passed, or even if we are launching the right init binary.
Assuming you use Linux, which you do, you can use /proc/cmdline to see 
the Kernel command line. From this you can determine which init was use. 
Either it was specified, or the default was used. It also contains the 
runlevel that was passed to init.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Nicolas CARRIER]

We're back to square one since I'm using linux, but it's not the kernel
which launches this pid 1, in a container context.

2016-02-01 14:26 GMT+01:00 Ralf Friedl :

> Nicolas CARRIER schrieb:
>
>> "/proc/1/cmdline is not a standard Unix ..."
>>
>> I absolutely don't know any other OS, be it Unix or not... But don't they
>> provide a way to access the command-line used to launch a program ?
>> In busybox's code at least, I see only one implementation of
>> read_cmdline, which reads the content of /proc/[PID]/cmdline.
>> From that I conclude that only Unices having this file can have a busybox
>> ps implementation dealing with the command-line.
>>
> Busybox is primarily intended for Linux. While some of the applets are
> Posix compliant, others are very Linux specific.
>
> Traditionally, Unix doesn't provide a way to access the comand-line of
> another program. Programs like ps used to do it anyway, but they had to be
> set-uid to root so that they could access the memory of another process.
> The whole /proc filesystem is not part of traditional Unix.
>
> What if I want to debug how init was launched ? The way it behaves now
>> makes it impossible to know if a runlevel has been passed, how it was
>> passed, or even if we are launching the right init binary.
>>
> Assuming you use Linux, which you do, you can use /proc/cmdline to see the
> Kernel command line. From this you can determine which init was use. Either
> it was specified, or the default was used. It also contains the runlevel
> that was passed to init.
>
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Nicolas CARRIER]

Frankly, I find it rather ugly to have to write a shell script, or a C
program and to alter the environment or write files just to circumvent a
dubious and historic "aesthetic" design choice.

Please understand me well, I have a functional (but ugly) solution
implemented for now which could satisfy me. I'm just trying to do my best
to propose a sensible, even if minor enhancement to busybox.

I'm sending my patch in it's current form in another thread. Thank you all
for all your interesting comments.

2016-02-01 15:44 GMT+01:00 Jody Bruchon :

> On February 1, 2016 9:28:58 AM EST, Sean Mathews 
> wrote:
> >Maybe write a simple C init wrapper and have it call the real init
> >process.
>
> Write a shell script that stores its arguments in a particular text file
> i.e.  'echo "$@" > /var/log/init_cmdline'. Have that shell script 'exec
> /sbin/init $@' at the end.
>
> That would preserve the argument list somewhere with no modifications to
> BusyBox and remain otherwise functionally identical. It should also work
> with any init binary you choose.
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Mike Frysinger]

On 01 Feb 2016 09:17, Nicolas CARRIER wrote:
> "init" is 4 chars long, "/bin/init" is 9 chars long, so when I "remove" the
> while (*++argv) ... loop, there are 5 extra bytes between "init" and the
> content of argv[1].
> In ps, the symptom is extra spaces inserted in the output, but the argv[1]+
> args are shown "correctly"
> In hexdump -C /proc/1/cmdline, 6 zeros instead of 1, are present between
> the last char of "init" and the first of argv[1].

OK, so you're talking about embedded NULs.  that's entirely to be expected
and there's not really anything you can do about it unless you repack the
args yourself (as you noticed).

> Personally, I prefer the first solution. I still don't get the point of
> modifying a program's argument, be it init or not...

it makes a lot of sense when you fork children that have specific purposes.
rather than just seeing the program's name 4 times, it's more helpful for
them to be broken up.  for example, postgres does:
805 ? S  0:28 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data
807 ? Ss 2:49 postgres: checkpointer process   
808 ? Ss 1:05 postgres: writer process   
809 ? Ss 0:56 postgres: wal writer process   
810 ? Ss 0:22 postgres: autovacuum launcher process   
811 ? Ss 1:24 postgres: stats collector process   

surely you'd agree this is way better than if you saw:
805 ? S  0:28 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data
807 ? Ss 2:49 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data
808 ? Ss 1:05 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data
809 ? Ss 0:56 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data
810 ? Ss 0:22 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data
811 ? Ss 1:24 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 
--data-directory=/var/lib/postgresql/9.4/data

especially if you're trying to debug why one of those processes is taking
up a ton of CPU or memory.
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: AW: why are init's arguments wiped ?

[Nicolas CARRIER]

"/proc/1/cmdline is not a standard Unix ..."

I absolutely don't know any other OS, be it Unix or not... But don't they
provide a way to access the command-line used to launch a program ?
In busybox's code at least, I see only one implementation of read_cmdline,
which reads the content of /proc/[PID]/cmdline.
>From that I conclude that only Unices having this file can have a busybox
ps implementation dealing with the command-line.

What's more, I don't think that erasing it's command-line is a "nice"
behavior for a program.
What if I want to debug how init was launched ? The way it behaves now
makes it impossible to know if a runlevel has been passed, how it was
passed, or even if we are launching the right init binary.
On some platforms I work on, there are 2 different init binaries, it would
be nice if performing a simple ps could assure me the right init binary is
used.

To conclude, I don't think that "allow[ing] init to take arguments" is only
useful for "passing of information in the init arguments via
/proc/1/cmdline". It is also a way to preserve informations passed by
init's father, whose motivations we can't foresee.

2016-02-01 11:55 GMT+01:00 Laurent Bercot :

> On 01/02/2016 08:12, dietmar.schind...@manroland-web.com wrote:
>
>> Anyone doing engineering work should come up with a better reason
>> than something like "that's always been done that way".
>>
>
>  Oh, definitely. But I'm not the one engineering something here,
> I'm the bad guy saying I don't like the suggested change.
>
>  History and tradition *are* valid objections to change, because breaking
> compatibility (if only compatibility of visual output) has a cost.
> They're not powerful objections: if a historical design is bad, and
> the new design brings obvious benefits, then it's entirely worth deviating
> from tradition. But everything else being equal, if the new design isn't
> strictly more powerful than the old one, then tradition may be worth
> keeping.
>
>  In the present case, the choice is between "wipe init arguments"
> (historical) and "allow init to take arguments" (suggested change).
>   Advantages of the historical behaviour: clean ps output
>   Advantages of the suggested change: passing of information in the
> init arguments via /proc/1/cmdline
>
>  Given that /proc/1/cmdline is not a standard Unix way of passing
> information, and that the OP's program would thus *only* work with
> the new-and-modified busybox init under Linux, making this change
> nothing more than a hack;
>  Given that Unix already provides plenty of ways to pass information
> from a process to its scions, and that the command line is only such
> a way for programs specifically designed to perform chain loading,
> which init is not;
>  Given that I have suggested an *easy*, safe, portable and perfectly
> Unix-ish way of accomplishing what the OP wants without having to patch
> anything;
>  Therefore, in this precise case, I don't think the change is worth it.
>
>  Seriously. Accusing *me* of following historical behaviours for the
> sake of it. :D
>
> --
>  Laurent
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Fwd: why are init's arguments wiped ?

[Nicolas CARRIER]

I used prctl from time to time to change a child's name, but I didn't
think of using argv directly, to pass more information. In fact I
discovered it was possible, when I asked this very question.
Thank you all for all the really interesting information.

2016-02-02 0:14 GMT+01:00 Mike Frysinger :
> On 02 Feb 2016 00:09, Didier Kryn wrote:
>> Le 01/02/2016 23:34, Mike Frysinger a écrit :
>> > On 01 Feb 2016 22:33, Didier Kryn wrote:
>> >> Le 01/02/2016 18:10, Mike Frysinger a écrit :
>> >>> it makes a lot of sense when you fork children that have specific 
>> >>> purposes.
>> >>> rather than just seeing the program's name 4 times, it's more helpful for
>> >>> them to be broken up.
>> >>   prctl() can be used for that, with the operation code PR_SET_NAME.
>> >> It does not change the command line.
>> > right, but that has its own limitations:
>> > - it's new to linux-2.6.9
>> > - can only set the name
>> > - is limited to 16 bytes
>> > - can't change command line args
>> >
>> > so we're still stuck with this behavior of modifying the argv mem directly 
>> > :(
>>
>>  IIUC your argument was there's a need to give sensible names to
>> children. prctl() allows this *without* resorting to modifying the
>> command line args. I don't find 16 chars (in reality 15) is short for
>> the purpose.
>
> if you look at the examples i already posted, 16 is too small for every
> one there.  when i've munged the `ps` listing in the past, i've also
> easily run past 16 bytes.  your cases might be short, but that doesn't
> mean every scenario is that way.
> -mike
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Sean Mathews]

Maybe write a simple C init wrapper and have it call the real init process.
Then you can look at your PID under /proc/xxx/status for the PPid and get
the args from that process.

This would be less work than writing your own init.

If you are not PID 1 you will have to use debug mode for init or it will
fail as it checks that its PID 1. How are you going to handle shutdown and
halt and its kill(-1)?


Re
 Sean

​
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Jody Bruchon]

On February 1, 2016 9:28:58 AM EST, Sean Mathews  wrote:
>Maybe write a simple C init wrapper and have it call the real init
>process.

Write a shell script that stores its arguments in a particular text file i.e.  
'echo "$@" > /var/log/init_cmdline'. Have that shell script 'exec /sbin/init 
$@' at the end.

That would preserve the argument list somewhere with no modifications to 
BusyBox and remain otherwise functionally identical. It should also work with 
any init binary you choose.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

RE: why are init's arguments wiped ?

[Cathey, Jim]

Some history, as I recall it:

Unix hard-coded "init" as PID 1, and (I believe) hard-coded the
initial search path to "/bin" and "/usr/bin".

Unix didn't pass any command-line arguments _to_ init, because
there was no environment from which they could come.  Most especially,
the concept of run-level is an init concept, not a kernel concept, and it
got it only from the inittab file, and not from the kernel in any way.

Linux only supports command-line arguments because _uboot_ (et al.) does,
and between the two of them they conspire to have arguments that are
meaningful to the kernel.  Which, as part of that, chooses to be able to
pass some of them off to init.  This is all new behavior, when compared
to Unix and several of its successors.

So, traditionally there weren't any command-line arguments to init,
and it certainly didn't rely upon them.  I do not know who decided that
(probably for compatibility) this newer system should mimic the
appearance of the older, but there it is nonetheless.

There are numerous reasons for a program to choose to mangle its own
command-line arguments, given that "ps" has always been able to
show them to you.  Some reasons:

1) Fork faces.  Forks without exec would be indistinguishable from each other,
   if not for this.

2) Security.  What if sensitive information had been passed on the command-line?
   Hide it.

3) Advertisement.  Cheesy way to make known things discovered at runtime.

-- Jim

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Mike Frysinger]

On 31 Jan 2016 22:56, Isaac Dunham wrote:
> On Mon, Feb 01, 2016 at 12:21:00AM -0500, Mike Frysinger wrote:
> > On 29 Jan 2016 21:10, Laurent Bercot wrote:
> > > 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 accomplish what
> > > you want with a little workaround.
> > 
> > not really.  his proposal makes busybox smaller.  the only reason given
> > for making busybox larger is "it makes `ps` 'nicer'".  if there's no real
> > technical reason for it and nothing is impacted, then shrinking busybox
> > is a no brainer.  at the very least, it makes sense to make it a config
> > option that defaults to off.
> > 
> > this was first changed here, but not really documented:
> > https://git.busybox.net/busybox/commit/?id=e132f4b09e5c9aedaef97f65279e8702633fd425
> 
> Looking near that commit, I see that it moved the code in question, but
> it seems the origin was instead this commit:
> 
> commit 3163821967821518cfa4c4315f775ec5301bb023
> Author: Erik Andersen 
> Date:   Sat Jan 15 22:28:50 2000 +

i don't think so.  that commit sets argv[0] to "init", but it doesn't
mess with the other argv elements.  the one i pointed out sets argv[1]
to NULL.  there is a later commit which changes it to what we see now:
clearing every valid argv.

not that it matters terribly much as none of the commits provide any
real background beyond the details we have already -- make `ps` nice
and "compatibility" with other inits (not that we know of any real
need for this).
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Isaac Dunham]

On Mon, Feb 01, 2016 at 12:21:00AM -0500, Mike Frysinger wrote:
> On 29 Jan 2016 21:10, Laurent Bercot wrote:
> > 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 accomplish what
> > you want with a little workaround.
> 
> not really.  his proposal makes busybox smaller.  the only reason given
> for making busybox larger is "it makes `ps` 'nicer'".  if there's no real
> technical reason for it and nothing is impacted, then shrinking busybox
> is a no brainer.  at the very least, it makes sense to make it a config
> option that defaults to off.
> 
> this was first changed here, but not really documented:
> https://git.busybox.net/busybox/commit/?id=e132f4b09e5c9aedaef97f65279e8702633fd425

Looking near that commit, I see that it moved the code in question, but
it seems the origin was instead this commit:

commit 3163821967821518cfa4c4315f775ec5301bb023
Author: Erik Andersen 
Date:   Sat Jan 15 22:28:50 2000 +

Sync up busybox with the latest and greatest.  This is not stuff for
the Embedix release.
 -Erik

Nothing indicates what the reason was. Looking at that commit, it seems
that some of it was from Debian-related work, but debian.org has nada.

HTH,
Isaac Dunham

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Fwd: why are init's arguments wiped ?

[Nicolas CARRIER]

I wrote a little patch which adds the option not to wipe the arguments, but
the result is a little bit odd, some 0 are inserted between "init" and the
rest of the arguments. I must be because "/bin/init" is replaced with
"init".
So the proper patch should either :
 * inhibit this argv[0] modification too
 * perform a memmove to wipe those extra zeros

Which one do you think is best ?

@isaac: sorry for the double mail

2016-02-01 7:56 GMT+01:00 Isaac Dunham :

> On Mon, Feb 01, 2016 at 12:21:00AM -0500, Mike Frysinger wrote:
> > On 29 Jan 2016 21:10, Laurent Bercot wrote:
> > > 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 accomplish what
> > > you want with a little workaround.
> >
> > not really.  his proposal makes busybox smaller.  the only reason given
> > for making busybox larger is "it makes `ps` 'nicer'".  if there's no real
> > technical reason for it and nothing is impacted, then shrinking busybox
> > is a no brainer.  at the very least, it makes sense to make it a config
> > option that defaults to off.
> >
> > this was first changed here, but not really documented:
> >
> https://git.busybox.net/busybox/commit/?id=e132f4b09e5c9aedaef97f65279e8702633fd425
>
> Looking near that commit, I see that it moved the code in question, but
> it seems the origin was instead this commit:
>
> commit 3163821967821518cfa4c4315f775ec5301bb023
> Author: Erik Andersen 
> Date:   Sat Jan 15 22:28:50 2000 +
>
> Sync up busybox with the latest and greatest.  This is not stuff for
> the Embedix release.
>  -Erik
>
> Nothing indicates what the reason was. Looking at that commit, it seems
> that some of it was from Debian-related work, but debian.org has nada.
>
> HTH,
> Isaac Dunham
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

AW: why are init's arguments wiped ?

[dietmar.schindler]

> -Ursprüngliche Nachricht-
> Von: Laurent Bercot
> Gesendet: Freitag, 29. Januar 2016 21:10
>
>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 accomplish what
> you want with a little workaround.

Anyone doing engineering work should come up with a better reason than 
something like "that's always been done that way".
--
Regards,
Dietmar

manroland web systems GmbH -- Managing Directors: Joern Gosse, Alexander 
Wassermann
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- 
VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, you are hereby notified that any use or 
dissemination of this communication is strictly prohibited. If you have 
received this eMail in error, then please delete this eMail.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Mike Frysinger]

On 29 Jan 2016 21:10, Laurent Bercot wrote:
> 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 accomplish what
> you want with a little workaround.

not really.  his proposal makes busybox smaller.  the only reason given
for making busybox larger is "it makes `ps` 'nicer'".  if there's no real
technical reason for it and nothing is impacted, then shrinking busybox
is a no brainer.  at the very least, it makes sense to make it a config
option that defaults to off.

this was first changed here, but not really documented:
https://git.busybox.net/busybox/commit/?id=e132f4b09e5c9aedaef97f65279e8702633fd425
-mike


signature.asc
Description: Digital signature
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

AW: why are init's arguments wiped ?

[dietmar.schindler]

> -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 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 ...

Uglyness is a matter of taste. I rather find ugly a program which bastardizes 
its argument list.

--
Dietmar

manroland web systems GmbH -- Managing Directors: Joern Gosse, Alexander 
Wassermann
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- 
VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, you are hereby notified that any use or 
dissemination of this communication is strictly prohibited. If you have 
received this eMail in error, then please delete this eMail.


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: 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
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Isaac Dunham]

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
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Nicolas CARRIER]

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 ?) before
init is launched and the previous questions do apply.

In the meantime, I find it rather strange that busybox wipes it's
arguments, knowing that passing arguments to init is a feature supported,
at least, by linux and that only argv[1] is parsed, so extra arguments
would do no harm. The ps argument is quite strange, why does it matter ?
"Cluttered" command-lines are quite well accepted for other processes, why
would init be any different ?

For now, I will stick with using argv[1] and retrieving it's content with
the RUNLEVEL environment variable, until I'm able to propose a decent
patch, with an option to disable this behavior.

Anyway, thank you for all your answers.

2016-01-29 17:32 GMT+01:00 Isaac Dunham :

> 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
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Didier Kryn]

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 the end. It's now 
useless and init is going to wipe it out anyway. Did I miss something?


Le 29/01/2016 17:50, Nicolas CARRIER a écrit :
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 ?) 
before init is launched and the previous questions do apply.


The first command in your script may be 'busybox mount -t proc proc 
/proc' . I don't think you need /sys and /dev. Mounting /sys is as easy 
as 'busybox mount -t sysfs sys /sys'.


The processes created in the mean time have no consequence: you 
terminate your script with 'exec init'; this does not cause any fork. It 
is the same process which continues with the new init, and still pid1.


Didier

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Isaac Dunham]

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 environment variables that init
> will inherit, but what's the purpose of the $@ at the end. It's now useless
> and init is going to wipe it out anyway. Did I miss something?

That "-s"/"single" or other runlevels (when supported) are specified thus:
init 


> 
> Le 29/01/2016 17:50, Nicolas CARRIER a écrit :
> >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 ?) before

eval is a shell builtin; "export" should function equivalently for this
purpose.

Unless you start this like:
 init.sh single 'foo=`command`'
you aren't going to spawn any processes by using eval.

> >init is launched and the previous questions do apply.
> 
> The first command in your script may be 'busybox mount -t proc proc
> /proc' . I don't think you need /sys and /dev. Mounting /sys is as easy as
> 'busybox mount -t sysfs sys /sys'.

In fact, init does not mount any filesystems itself (it will run swapon if
ram gets too low, but otherwise your rc script handles mount and swapon.)

> The processes created in the mean time have no consequence: you
> terminate your script with 'exec init'; this does not cause any fork. It is
> the same process which continues with the new init, and still pid1.

Correct.

HTH,
Isaac Dunham
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Laurent Bercot]

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 accomplish what
you want with a little workaround.



And concerning the replacement of init with a script, well, hum...
:D Is it even possible ?


 It is very possible, and a lot of init systems do this. If you are
using a distribution that comes with an initramfs, you are using this
feature every time you boot.



Won't it suffer from the lack of proc / sys and dev ? Environment
variables setup by init ?


 This does not matter if all you want is to get command-line arguments
and store them somewhere (in the environment, for instance).



What's more, there is a risk to spawn multiple processes (eval ?)
before init is launched and the previous questions do apply.


 No risk. The only important thing is to make sure your pid 1 does
not die, and eventually execs into init.
 Your zombies will all be reaped when init starts.



In the meantime, I find it rather strange that busybox wipes it's
arguments, knowing that passing arguments to init is a feature
supported, at least, by linux and that only argv[1] is parsed, so
extra arguments would do no harm. The ps argument is quite strange,
why does it matter ? "Cluttered" command-lines are quite well
accepted for other processes, why would init be any different ?


 Because it's a convention that init prints "init" and nothing else
(or sometimes its default runlevel) in the process list.

 Also, the fact that nothing under init actually uses the arguments
to init, so it should not matter at all. Using /proc/1/cmdline to
get those arguments is very ad hoc ; this is not a POSIX way to
transmit information to other programs, and init is free to not
support it.

--
 Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Nicolas CARRIER]

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.

2016-01-28 18:05 GMT+01:00 Jody Bruchon :

> On 2016-01-28 12:02, Nicolas CARRIER wrote:
>
>> Why are init's arguments wipe ?
>> I had the hope to pass init some arguments, then read them by looking
>> into /proc/1/cmdline, but no luck...
>>
>
> I don't know the answer to the question about init's arguments being
> erased, but assuming you're on Linux, you might consider passing the
> arguments to the kernel at boot time and fetch them from /proc/cmdline
> instead. As long as the kernel doesn't recognize them, they'll be silently
> ignored by the kernel.
>
> -Jody
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: why are init's arguments wiped ?

[Jody Bruchon]

On 2016-01-28 12:02, Nicolas CARRIER wrote:

Why are init's arguments wipe ?
I had the hope to pass init some arguments, then read them by looking
into /proc/1/cmdline, but no luck...


I don't know the answer to the question about init's arguments being 
erased, but assuming you're on Linux, you might consider passing the 
arguments to the kernel at boot time and fetch them from /proc/cmdline 
instead. As long as the kernel doesn't recognize them, they'll be 
silently ignored by the kernel.


-Jody
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

why are init's arguments wiped ?

[Nicolas CARRIER]

Hello,
in init/init.c, l. 1144, there is the following code :

/* Wipe argv[1]-argv[N] so they don't clutter the ps listing */
while (*++argv)
 nuke_str(*argv);

Why are init's arguments wipe ?
I had the hope to pass init some arguments, then read them by looking into
/proc/1/cmdline, but no luck...

Do anyone think it could be possible to remove these lines, at least with a
config option ?

Thank you.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox