Mailing List Archive: argv[0] inconsistencies?

argv[0] inconsistencies?

Jun 22, 1995, 9:52 AM

Post #1 of 8 (929 views)

This is what I get out of 'ps ax' on a FreeBSD 2.0.5 system right
after starting up a 20-child server:

961 ?? Is 0:00.07 apache-parent (apache-0.7.3g)
962 ?? I 0:00.01 apache-1- (apache-0.7.3g)
963 ?? I 0:00.01 apache-2- (apache-0.7.3g)
964 ?? I 0:00.01 apache-3- (apache-0.7.3g)
965 ?? I 0:00.01 apache-4- (apache-0.7.3g)
966 ?? I 0:00.01 apache-5- (apache-0.7.3g)
967 ?? I 0:00.01 apache-6- (apache-0.7.3g)
968 ?? I 0:00.01 apache-7- (apache-0.7.3g)
969 ?? I 0:00.01 apache-8- (apache-0.7.3g)
970 ?? I 0:00.01 apache-9- (apache-0.7.3g)
971 ?? I 0:00.01 apache-10 (apache-0.7.3g)
972 ?? I 0:00.01 apache-11-0 (apache-0.7.3g)
973 ?? I 0:00.01 apache-12-0 (apache-0.7.3g)
974 ?? I 0:00.01 apache-13-0 (apache-0.7.3g)
975 ?? I 0:00.01 apache-14-0 (apache-0.7.3g)
976 ?? I 0:00.01 apache-15-0 (apache-0.7.3g)
977 ?? I 0:00.01 apache-16-0 (apache-0.7.3g)
978 ?? I 0:00.01 apache-17-0 (apache-0.7.3g)
979 ?? I 0:00.01 apache-18-0 (apache-0.7.3g)
980 ?? I 0:00.01 apache-19-0 (apache-0.7.3g)
981 ?? I 0:00.01 apache-20-0 (apache-0.7.3g)

Why do children 1 to 9 lack the request number, and number 10
lacks both the hyphen and the request number?
--
Brian ("Though this be madness, yet there is method in't") Tao
taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org

Re: argv[0] inconsistencies? [ In reply to ]

Jun 22, 1995, 11:29 AM

Post #2 of 8 (927 views)

> This is what I get out of 'ps ax' on a FreeBSD 2.0.5 system right
> after starting up a 20-child server:

is the code for inststr() in utils.c correct ?

Seems to me that if the string being overwritten is shorter than
the new string, then all the arguments and environment variables
get overwritten by '\0'

As the number of requests processed increases to double figures,
this is guaranteed to happen. It doesn't look like the algorithm
takes into account what happens when there's no args, no environment
variables or if the routine is called multiple times. All of these
things are happening I bet.

1st call to inststr changes the name to "apache-parent"
(shrinks if argv[0] has full path ?)
all the children inherit this, hmm, maybe not a good idea.

2nd call to inststr changes children to "apache-n" (shrinks)

3rd call to inststr changes children to "apache-n-0" (grows)

13th call to inststr changes children to "apache-n-10" (grows)

Perhaps if the name changes where forced to a fixed size, then the
problem would go away.

... for once it looks like HP do it right :-)

rob.

Re: argv[0] inconsistencies? [ In reply to ]

brian at organic

Jun 22, 1995, 11:39 AM

Post #3 of 8 (926 views)

On Fri, 23 Jun 1995, Brian Tao wrote:
> This is what I get out of 'ps ax' on a FreeBSD 2.0.5 system right
> after starting up a 20-child server:

Looks even weirder on BSDI:

root 25578 0.0 1.4 1304 636 ?? Ss 4:10PM 0:11.44 (httpd)
nobody 17578 0.0 1.0 1328 468 ?? S 11:34AM 0:00.31 apache-1-20 -20 "" (httpd)
nobody 17701 0.0 0.8 1324 352 ?? S 11:36AM 0:00.09 apache-2-3 -3 "" (httpd)
nobody 17702 0.0 0.8 1324 388 ?? S 11:36AM 0:00.07 apache-3-4 -4 "" (httpd)
nobody 17670 0.0 0.8 1320 376 ?? S 11:35AM 0:00.08 apache-4-7 -7 "" (httpd)
nobody 17700 0.0 0.8 1324 392 ?? S 11:36AM 0:00.06 apache-5-3 -3 "" (httpd)
nobody 17227 0.0 1.0 1328 456 ?? I 11:28AM 0:00.47 apache-6-27 -27 "" (httpd)
nobody 17669 0.0 1.0 1328 464 ?? S 11:35AM 0:00.13 apache-7-7 -7 "" (httpd)
nobody 17708 0.0 0.8 1320 348 ?? S 11:36AM 0:00.05 apache-8-4 -4 "" (httpd)
nobody 17720 0.0 0.8 1324 384 ?? S 11:36AM 0:00.06 apache-9-2 -2 "" (httpd)
nobody 17623 0.0 0.9 1336 416 ?? S 11:35AM 0:00.11 apache-10-8 0-8 "" (httpd)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: argv[0] inconsistencies? [ In reply to ]

Jun 22, 1995, 11:52 AM

Post #4 of 8 (927 views)

maybe this'd be better...

inststr (utils.c)

char *ptr, len_dest, len_src;

ptr = dst[0]; /* ptr to string to overwrite */
len_dest = strlen(ptr);
len_src = strlen(src);
strncpy(ptr, src, len_dest); /* overwrite the string */

ptr += len_src; /* find end of new string */
while (len_src++ < len_dest) *ptr = ' '; /* if it's shorter, add spaces */

/* string was terminated by a '\0', and we haven't trashed it */
return;

Re: argv[0] inconsistencies? [ In reply to ]

Jun 22, 1995, 1:52 PM

Post #5 of 8 (927 views)

> maybe this'd be better...
>
>
> inststr (utils.c)
>
>
> char *ptr, len_dest, len_src;
>
> ptr = dst[0]; /* ptr to string to overwrite */
> len_dest = strlen(ptr);
> len_src = strlen(src);
> strncpy(ptr, src, len_dest); /* overwrite the string */
>
> ptr += len_src; /* find end of new string */
> while (len_src++ < len_dest) *ptr = ' '; /* if it's shorter, add spaces */

*ptr++

of course.

>
> /* string was terminated by a '\0', and we haven't trashed it */
> return;

This works under SunOs - the old version didn't.

--
http://nqcd.lanl.gov/~hartill/

Re: argv[0] inconsistencies? [ In reply to ]

Jun 22, 1995, 11:51 PM

Post #6 of 8 (926 views)

On Thu, 22 Jun 1995, Rob Hartill wrote:
>
> Seems to me that if the string being overwritten is shorter than
> the new string, then all the arguments and environment variables
> get overwritten by '\0'

What if the new string is longer? Don't you risk overwriting
whatever happens to follow argv[0]? I remember reading somewhere
(perhaps in the NCSA httpd 1.4 docs) that they recommend specifying
the complete pathname of the server when starting it so that you get
lots of room to play with when fiddling with process names and the
like.
--
Brian ("Though this be madness, yet there is method in't") Tao
taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org

Re: argv[0] inconsistencies? [ In reply to ]

Jun 23, 1995, 10:37 AM

Post #7 of 8 (925 views)

>
> On Thu, 22 Jun 1995, Rob Hartill wrote:
> >
> > Seems to me that if the string being overwritten is shorter than
> > the new string, then all the arguments and environment variables
> > get overwritten by '\0'
>
> What if the new string is longer? Don't you risk overwriting
> whatever happens to follow argv[0]? I remember reading somewhere
> (perhaps in the NCSA httpd 1.4 docs) that they recommend specifying
> the complete pathname of the server when starting it so that you get
> lots of room to play with when fiddling with process names and the
> like.

The replacement inststr routine I mailed to the list yesterday fixes
the problem, it won't overwrite anything other than the filename, and
it pads things out with spaces if there's room to spare. The size of
the filename / process name will stay at a constant length.

As NCSA say, for best results, use the full pathname.

does this 'fix' repair any Solaris/Linux problems that were seen ?

rob
--
http://nqcd.lanl.gov/~hartill/

Re: argv[0] inconsistencies? [ In reply to ]

Jun 23, 1995, 11:13 PM

Post #8 of 8 (928 views)

On Fri, 23 Jun 1995, Rob Hartill wrote:
>
> The replacement inststr routine I mailed to the list yesterday fixes
> the problem, it won't overwrite anything other than the filename, and
> it pads things out with spaces if there's room to spare. The size of
> the filename / process name will stay at a constant length.

At first I thought I applied the inststr patch incorrectly, but I
still get this problem with 0.73h: the process name includes trailing
arguments, making for rather wide ps listings:

25950 ?? IWs 0:00.07 apache-parent -f /usr/loc ... (apache-0.7.3h)
25951 ?? IW 0:00.01 apache-1-0 -f /usr/loc ... (apache-0.7.3h)
25952 ?? IW 0:00.01 apache-2-0 -f /usr/loc ... (apache-0.7.3h)
[...]

The argv[0] portion comes up correctly now, but if I invoke
Apache with additional command-line arguments (in this case, to read
an alternate httpd.conf), the whole thing shows up in a ps. This is
on a FreeBSD 2.0.5 machine. I tried it on an IRIX 6.01 machine and
there didn't seem to be any argv[0] manipulation at all.

Anyhow, I need to go catch my flight to Toronto now... talk to you
guys next week. :)
--
Brian ("Though this be madness, yet there is method in't") Tao
taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org