Re: why are init's arguments wiped ?
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
Re: why are init's arguments wiped ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
Re: why are init's arguments wiped ?
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
Re: why are init's arguments wiped ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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: why are init's arguments wiped ?
>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
