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: 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 ?

[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 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 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. Option -c in top, and I think also 
in ps, displays command name instead of command line.


I also find that wiping ones own command arguments is impolite, but 
relying on them is obviously non-portable.


My 2 cents.

Didier

___
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: [PATCH] init: allow to preserve init's command-line

[Mike Frysinger]

i'll let this sit for a bit to see if anyone else (like Denys) has any
feedback.  otherwise i'm fine with 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 ?

[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: [PATCH] init: allow to preserve init's command-line

[Nicolas CARRIER]

Thank you for all your comments.
Please find a new version attached.

2016-02-01 18:15 GMT+01:00 Mike Frysinger :
> On 01 Feb 2016 18:00, Nicolas CARRIER wrote:
>> When launched as PID 1 and after parsing it's arguments, init wipes all
>
> you'll want to run s/it's/its/ on the commit message and docs you added
> to the help string.  "it's" is short for "it is" while "its" is what you
> want here -- the possessive form.  because english!
>
>> +//config:  retrieved in /proc/1/cmdline on Linux, for example.
>> +
>>
>
> these's no need to add this extra blank line
>
>> +#if !ENABLE_FEATURE_PRESERVE_CMDLINE
>>   /* 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);
>> +#endif
>
> we strongly prefer to *not* use CPP when we can do it in C.
> write the code like i posted in the patch to you earlier.
> if (!ENABLE_FEATURE_PRESERVE_CMDLINE) {
> ...
> }
>
> the compiler will optimize it the same way.
> -mike
From 96a7dee821ee6ca3c0ef02dcbfedf3a068144030 Mon Sep 17 00:00:00 2001
From: Nicolas Carrier 
Date: Mon, 1 Feb 2016 18:28:37 +0100
Subject: init: allow to preserve init's command-line

When launched as PID 1 and after parsing its arguments, init wipes all
all of them except argv[0] and rewrites argv[0] to contain only "init",
so that its command-line appears solely as "init" in tools such as ps.

This patch adds the FEATURE_PRESERVE_CMDLINE which, if set to Y, will make
init preserve all its arguments including argv[0], be they parsed or
ignored.
The original command-line used to launch init can then be retrieved in
/proc/1/cmdline on Linux, for example.
---
 init/init.c | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/init/init.c b/init/init.c
index 2040a59..2424dd7 100644
--- a/init/init.c
+++ b/init/init.c
@@ -102,6 +102,21 @@
 //config:
 //config:	  Note that on Linux, init attempts to detect serial terminal and
 //config:	  sets TERM to "vt102" if one is found.
+//config:
+//config:config FEATURE_PRESERVE_CMDLINE
+//config:	bool "Prevent init from altering its command-line after parsing"
+//config:	default n
+//config:	depends on INIT
+//config:	help
+//config:	  When launched as PID 1 and after parsing its arguments, init
+//config:	  wipes all the arguments but argv[0] and rewrites argv[0] to
+//config:	  contain only "init", so that its command-line appears solely as
+//config:	  "init" in tools such as ps.
+//config:	  If you set this option to Y, all the arguments including argv[0]
+//config:	  will be preserved, be they parsed or ignored by init.
+//config:	  The original command-line used to launch init can then be
+//config:	  retrieved in /proc/1/cmdline on Linux, for example.
+
 
 //applet:IF_INIT(APPLET(init, BB_DIR_SBIN, BB_SUID_DROP))
 //applet:IF_FEATURE_INITRD(APPLET_ODDNAME(linuxrc, init, BB_DIR_ROOT, BB_SUID_DROP, linuxrc))
@@ -1138,11 +1153,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 (!ENABLE_FEATURE_PRESERVE_CMDLINE) {
+		/* Make the command line just say "init"  - that's 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) {
-- 
2.7.0

___
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: Implement "dG" in vi

[Cathey, Jim]

So what's wrong with:

.,$d

-- Jim

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

Re: [PATCH] init: allow to preserve init's command-line

[Mike Frysinger]

On 01 Feb 2016 18:00, Nicolas CARRIER wrote:
> When launched as PID 1 and after parsing it's arguments, init wipes all

you'll want to run s/it's/its/ on the commit message and docs you added
to the help string.  "it's" is short for "it is" while "its" is what you
want here -- the possessive form.  because english!

> +//config:  retrieved in /proc/1/cmdline on Linux, for example.
> +
>  

these's no need to add this extra blank line

> +#if !ENABLE_FEATURE_PRESERVE_CMDLINE
>   /* 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);
> +#endif

we strongly prefer to *not* use CPP when we can do it in C.
write the code like i posted in the patch to you earlier.
if (!ENABLE_FEATURE_PRESERVE_CMDLINE) {
...
}

the compiler will optimize it the same 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 ?

[Nicolas CARRIER]

Your example is interesting.
Postgres preserves it's arguments (chosen by it's father), it only tunes
the command-line of it's sons.

There is no loss of information in the process, on the contrary.

2016-02-01 18:10 GMT+01:00 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
>
___
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

[PATCH] init: allow to preserve init's command-line

[Nicolas CARRIER]

When launched as PID 1 and after parsing it's arguments, init wipes all
all of them except argv[0] and rewrites argv[0] to contain only "init",
so that it's command-line appears solely as "init" in tools such as ps.

This patch adds the FEATURE_PRESERVE_CMDLINE which, if set to Y, will make
init preserve all it's arguments including argv[0], be they parsed or
ignored.
The original command-line used to launch init can then be retrieved in
/proc/1/cmdline on Linux, for example.
From 4a798bf8e080d88a17a35feaf83f2c76151a9fae Mon Sep 17 00:00:00 2001
From: Nicolas Carrier 
Date: Mon, 1 Feb 2016 17:59:56 +0100
Subject: init: allow to preserve init's command-line

When launched as PID 1 and after parsing it's arguments, init wipes all
all of them except argv[0] and rewrites argv[0] to contain only "init",
so that it's command-line appears solely as "init" in tools such as ps.

This patch adds the FEATURE_PRESERVE_CMDLINE which, if set to Y, will make
init preserve all it's arguments including argv[0], be they parsed or
ignored.
The original command-line used to launch init can then be retrieved in
/proc/1/cmdline on Linux, for example.
---
 init/init.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/init/init.c b/init/init.c
index 2040a59..74c9486 100644
--- a/init/init.c
+++ b/init/init.c
@@ -102,6 +102,22 @@
 //config:
 //config:	  Note that on Linux, init attempts to detect serial terminal and
 //config:	  sets TERM to "vt102" if one is found.
+//config:
+//config:config FEATURE_PRESERVE_CMDLINE
+//config:	bool "Prevent init from altering it's command-line after parsing"
+//config:	default n
+//config:	depends on INIT
+//config:	help
+//config:	  When launched as PID 1 and after parsing it's arguments, init
+//config:	  wipes all the arguments but argv[0] and rewrites argv[0] to
+//config:	  contain only "init", so that it's command-line appears solely as
+//config:	  "init" in tools such as ps.
+//config:
+//config:	  If you set this option to Y, all the arguments including argv[0]
+//config:	  will be preserved, be they parsed or ignored by init.
+//config:	  The original command-line used to launch init can then be
+//config:	  retrieved in /proc/1/cmdline on Linux, for example.
+
 
 //applet:IF_INIT(APPLET(init, BB_DIR_SBIN, BB_SUID_DROP))
 //applet:IF_FEATURE_INITRD(APPLET_ODDNAME(linuxrc, init, BB_DIR_ROOT, BB_SUID_DROP, linuxrc))
@@ -1138,11 +1154,13 @@ int init_main(int argc UNUSED_PARAM, char **argv)
 	}
 #endif
 
+#if !ENABLE_FEATURE_PRESERVE_CMDLINE
 	/* 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);
+#endif
 
 	/* Set up signal handlers */
 	if (!DEBUG_INIT) {
-- 
2.7.0

___
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: 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 ?

[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 ?

[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 ?

[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: 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: 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 mailto:ska-dietl...@skarnet.org>>:

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]

"/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: 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: 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: 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