Bizarre Solaris problem

Bizarre Solaris problem

[Anthony Heading]

This has me perplexed. I have a small program, attached below, which
does little more than a gethostbyname() call.

I compile it *statically* under SunOS 4.1.3, using either acc or gcc,
and attempt to run it under Solaris 2.5.1.

It works OK for any standard /bin/sh or /bin/csh login.  If however I
use an account with /usr/local/bin/zsh (3.0.5) as the login (/etc/passwd)
shell, it hangs in the gethostbyname() call.

Further investigation using subshells from a /bin/csh login reveals:

su <zsh> : OK
zsh -l : OK
su - <zsh> : hangs

Having got into a "hang" configuration, su - <csh> *doesn't* reverse
back into a working state.

Those four pieces of evidence seem to rule out the problem as being in
the environment or the zlogin file?

Other info:  I'm unaware of anything needed to "authorize" zsh (a la
e.g. /etc/shells under some BSD-like environments).  Vanilla 3.0.5
compilation (except for my vared patch sent to the list a week or
two ago).  Nothing in zlogin except for an stty config line.

Where does one start looking here?  

Anthony
---------

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int main(int argc, char *argv[])
{
  struct hostent *m;
  unsigned char *a;

  if (argc < 2) {
    fprintf(stderr, "usage: %s <hostname>\n", argv[0]); 
    exit(1);
  }
  m=gethostbyname(argv[1]);
  if (!m || !m->h_addr_list || !m->h_addr_list[0]) {
    fprintf(stderr, "No such host %s\n", argv[1]);
    exit(1);
  }
  a = (unsigned char *)m->h_addr_list[0];
  fprintf(stderr, "%d.%d.%d.%d\n", a[0], a[1], a[2], a[3]);
  return 0;
}

Re: Bizarre Solaris problem

[Bart Schaefer]

On Nov 12,  1:22pm, Anthony Heading wrote:
} Subject: Bizarre Solaris problem
}
} I compile it *statically* under SunOS 4.1.3, using either acc or gcc,
} and attempt to run it under Solaris 2.5.1.

I think you're going to have to be more specific about "attempt to run
it."  Since it's doing something with argv[1], the arguments that you're
passing are pretty important.

Where are you executing this?  From .zshrc or .cshrc or .profile or ?

} su <zsh> : OK
} zsh -l : OK
} su - <zsh> : hangs
} 
} Having got into a "hang" configuration, su - <csh> *doesn't* reverse
} back into a working state.
} 
} Those four pieces of evidence seem to rule out the problem as being in
} the environment or the zlogin file?

They probably rule out /etc/zlogin or ~/.zlogin, but not the environment.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Bizarre Solaris problem

[Anthony Heading]

Haha!  A quick update in case anyone is thinking about this.

The problem I've just tracked down to process limits.  csh is
initialising with the maxmimum number of file descriptors set to 64
(indeed the value of OPEN_MAX and supposedly the maximum limit
therefore for RLIMIT_NOFILE).

getrlimit(), however,  believes that the maximum number of file
descriptors is 1024, and zsh is bumping the limit up to that value.
This appears to confuse the 4.1.3 gethostbyname().

Time to complain to Sun, I think.

Regards

A

PS.  Apologies to Bart for sending a reply only to him. Didn't replies
use to go to the list rather than just the originator?

Re: Bizarre Solaris problem

[Richard Coleman]

> PS.  Apologies to Bart for sending a reply only to him. Didn't replies
> use to go to the list rather than just the originator?

Not for several years (since I took over the zsh lists).  That
makes it too easy for a misconfigured autoresponder or vacation
program to flood our mail server.

--
Richard Coleman
coleman@math.gatech.edu

Re: Bizarre Solaris problem

[Peter Stephenson]

Anthony Heading wrote:
> Haha!  A quick update in case anyone is thinking about this.
> 
> The problem I've just tracked down to process limits.  csh is
> initialising with the maxmimum number of file descriptors set to 64
> (indeed the value of OPEN_MAX and supposedly the maximum limit
> therefore for RLIMIT_NOFILE).
> 
> getrlimit(), however,  believes that the maximum number of file
> descriptors is 1024, and zsh is bumping the limit up to that value.
> This appears to confuse the 4.1.3 gethostbyname().

We saw this business apropos of something else a while ago.  OPEN_MAX
is actually not the maximum limit, since it's run-time configurable
under Solaris 2.  So presumably the difference that's causing the OS bug
to show up is because csh is too old-fashioned to care.  Unless there's
some reason for not following getrlimit() if all those descriptors aren't
needed.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, Platanenallee 6, 15738 Zeuthen, Germany.

Re: Bizarre Solaris problem

[Anthony Heading]

Peter wrote:
> Anthony Heading wrote:
> > Haha!  A quick update in case anyone is thinking about this.
> > 
> > The problem I've just tracked down to process limits.  csh is
> > initialising with the maxmimum number of file descriptors set to 64
> > (indeed the value of OPEN_MAX and supposedly the maximum limit
> > therefore for RLIMIT_NOFILE).
> > 
> > getrlimit(), however,  believes that the maximum number of file
> > descriptors is 1024, and zsh is bumping the limit up to that value.
> > This appears to confuse the 4.1.3 gethostbyname().
> 
> We saw this business apropos of something else a while ago.  OPEN_MAX
> is actually not the maximum limit, since it's run-time configurable
> under Solaris 2.  So presumably the difference that's causing the OS bug
> to show up is because csh is too old-fashioned to care.  Unless there's
> some reason for not following getrlimit() if all those descriptors aren't
> needed.

Not sure.

For my particular problem, Sun have been good enough to acknowledge this
as a bug in 2.5.1, and tell me it's fixed in the 2.6 Sun4 libraries.
(Exactly why one fixes the libraries, rather than have the kernel cap
the process limits to SunOS4 maxima when executing those binaries I
don't quite understand, but nevermind...)

Unless I've got this wrong (and I've got a cold at the moment so the
powers of analysis are somewhat below peak), zsh is displaying a
certain amount of youthful exuberance in widening the process limits
out to their hard stops.  No other shells appear to do this, instead
happily inheriting and reflecting the soft limits from their parents.

Now this is a matter of little practical import, mostly because few
people ever worry about these limits, and an extra line or lack of
it in .zshenv is not a big deal.  But after some thought, the
semantics seem undesirable:

 - it destroys information for little gain;
 - it's different from everyone else;
 - it potentially prevents implementation optimizations.

I know very little about POSIX and Unix standards and stuff, but if the
concept of hard and soft process limits are defined there, I'd doubt
that a shell is mandated to throw away the soft ones.

A