<div dir="ltr"><div><div>Your example is interesting.<br></div>Postgres preserves it's arguments (chosen by it's father), it only tunes the command-line of it's sons.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There is no loss of information in the process, on the contrary.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-01 18:10 GMT+01:00 Mike Frysinger <span dir="ltr"><<a href="mailto:vapier@gentoo.org" target="_blank">vapier@gentoo.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01 Feb 2016 09:17, Nicolas CARRIER wrote:<br>
> "init" is 4 chars long, "/bin/init" is 9 chars long, so when I "remove" the<br>
> while (*++argv) ... loop, there are 5 extra bytes between "init" and the<br>
> content of argv[1].<br>
> In ps, the symptom is extra spaces inserted in the output, but the argv[1]+<br>
> args are shown "correctly"<br>
> In hexdump -C /proc/1/cmdline, 6 zeros instead of 1, are present between<br>
> the last char of "init" and the first of argv[1].<br>
<br>
</span>OK, so you're talking about embedded NULs.  that's entirely to be expected<br>
and there's not really anything you can do about it unless you repack the<br>
args yourself (as you noticed).<br>
<span class=""><br>
> Personally, I prefer the first solution. I still don't get the point of<br>
> modifying a program's argument, be it init or not...<br>
<br>
</span>it makes a lot of sense when you fork children that have specific purposes.<br>
rather than just seeing the program's name 4 times, it's more helpful for<br>
them to be broken up.  for example, postgres does:<br>
805 ? S  0:28 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
807 ? Ss 2:49 postgres: checkpointer process<br>
808 ? Ss 1:05 postgres: writer process<br>
809 ? Ss 0:56 postgres: wal writer process<br>
810 ? Ss 0:22 postgres: autovacuum launcher process<br>
811 ? Ss 1:24 postgres: stats collector process<br>
<br>
surely you'd agree this is way better than if you saw:<br>
805 ? S  0:28 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
807 ? Ss 2:49 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
808 ? Ss 1:05 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
809 ? Ss 0:56 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
810 ? Ss 0:22 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
811 ? Ss 1:24 /usr/lib/postgresql-9.4/bin/postgres -D /etc/postgresql-9.4 --data-directory=/var/lib/postgresql/9.4/data<br>
<br>
especially if you're trying to debug why one of those processes is taking<br>
up a ton of CPU or memory.<br>
<span class="HOEnZb"><font color="#888888">-mike<br>
</font></span></blockquote></div><br></div></div>