Linux-Development-Sys Digest #984, Volume #6 Thu, 22 Jul 99 20:14:06 EDT
Contents:
Linux Training ("JamesH")
status code in drivers/net (Yung-Hsiang Lu)
Re: File size restriction on Linux : (Mark Hahn)
Re: when will Linux support > 2GB file size??? (bill davidsen)
Re: when will Linux support > 2GB file size???
Re: Bug of GCC ([EMAIL PROTECTED])
Re: NCR 53C710 Fast SCSI-2 Controller ("Robert M. Stockmann")
Re: lib probs with cc and gcc 2.7.2.3 (Matt)
Re: building JWS1.1.3 Major Problems. (Matt)
Re: Server linux config (bill davidsen)
----------------------------------------------------------------------------
From: "JamesH" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.hardware,comp.os.linux.development.apps
Subject: Linux Training
Date: Thu, 22 Jul 1999 12:10:39 -0700
Hello,
Can anyone recommend a good Linux Training Organization?
Has anyone used or heard anything about Linuxcare or Redhat training?
Jim Holloway
GTS, Inc.
800 888-9874 ext. 203
------------------------------
From: [EMAIL PROTECTED] (Yung-Hsiang Lu)
Subject: status code in drivers/net
Date: 22 Jul 1999 21:13:43 GMT
Hi,
Does anybody know where I can find a table that shows the meaning of
the status code used in drivers/net/? What does 383c or 2000 mean?
Thank you very much.
--
Sincerely,
Yung-Hsiang Lu
[EMAIL PROTECTED]
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Subject: Re: File size restriction on Linux :
Date: 22 Jul 1999 21:40:18 GMT
>> > The process stops after creating the file of size 2147482648 which is
>> > nothing but 2 Gbytes.
as expected/specified/documented on 32b CPUs.
> It is the 32-bit kernel, not ext2. Without hacks, that's the file size
> limit for standard IA-32 architecture.
actually, there's an experimental patch that permits large files
on 32b CPUs.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 22 Jul 1999 21:34:16 GMT
In article <[EMAIL PROTECTED]>,
Christopher B. Browne <[EMAIL PROTECTED]> wrote:
| I suggest that this is a *common* issue that hits:
|
| a) Memory mapping,
| b) File mapping, and
| c) Date mapping.
|
| All three have roughly the same sorts of limitations that result from
| 32 bit values, and you hit all three in the FILE * structure.
|
| There are effectively three choices:
| a) Leave it alone, letting 32 bit systems have 32 bit limitations, and
| 64 bit systems have 64 bit limits, which is the situation we have at
| present,
|
| b) Move to 64 bit representations on all platforms, which results in a
| performance "hit" for 32 bit systems, but which has the positive effect
| that it is a "linear" change, or
|
| c) Segment things, having the *option* of using a 64 bit API when
| desired, and a 32/64 bit API (platform-dependent) when you "don't care."
|
| My suspicion is that the best way to handle this is to go with option a)
| for the time being, and then move to b) in about five years when 64 bit
| processors become dominant in the marketplace.
I think that a solution which causes programs needing 64 bits to be
compiled in some special way is the right one, for any value of "special
way" you name.
I think your assumption about 64 bits is wistful thinking. The typical
users, home or business, has no need for 64 bits. 16 was a problem, but
32 fits a lot of real world problems well. People just don't have huge
databases on their system in any significant numbers, they connect to
servers for big stuff, because to support a really large data set, you
need not only addressing space but backup, high bandwidth to storage,
etc. In most cases it makes sense to have that on a server and access
from a low cost system for the user.
While I never doubted that 16 bit systems would vanish because they are
too small, I don't have that feeling about 32 bits. The applications
which need 64 bits are mostly business applications, where a server is
likely to be cost effective.
I don't doubt that there will be a market for 64 bit personal systems,
but I think there will continue to be a large market for 32 bit machines
because they will be the most cost effective solution. The solution to
64 bit data isn't going to wait a decade or more for 64 bit systems on
every desk, so I think there better be a practical solution using 32
bits, and sooner rather than later.
The change most likely to work without breaking programs is to extend
the sizeof int to 64 bits (and long and offset_t). That is not going to
avoid breaking code which is really badly written, but it avoids
breaking some moderately good code. I think almost all of my code uses
offset_t for file operations, but subscripts are int, and that's where
the change is needed if the code is to remain portable.
That's my view.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Thu, 22 Jul 1999 15:13:52 -0700
On 22 Jul 1999 16:53:05 -0400, Robert Krawitz <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] () writes:
>
>> On 22 Jul 1999 08:14:42 -0400, Robert Krawitz <[EMAIL PROTECTED]> wrote:
>> >[EMAIL PROTECTED] (Christopher B. Browne) writes:
[deletia]
>> Except, moving to another Unix variant is hardly
>> a revolutionary change. Moving just to another
>> binary platform is even less so.
>
>32-bit to 64-bit shouldn't be too hard for well written code, but how
>much badly written code is there that assumes pointers fit in ints,
>ints == longs, and so forth? How much of that is in commercial
That's taken care of by your first such platform. There
are 64 bit unixen in production already. As long as you're
already building on one of those, bitness shouldn't be an
issue.
>products? I would venture to say quite a lot.
>
>> In the scheme of things, considering what else other Unix
>> vendors support, another binary platform is not so significant.
>> Someone in Oracle tech support could be running 8i on Linux/
>> Alpha at this very moment for all we know.
>
>Do you really think that moving from a 32-bit platform to a 64-bit
>platform is easy for typical code out there? Do you really believe
That falsely presumes that it hasn't already been done
for some other more relevant Unix already.
[deletia]
--
It helps the car, in terms of end user complexity and engineering,
that a car is not expected to suddenly become wood chipper at some |||
arbitrary point as it's rolling down the road. / | \
Seeking sane PPP Docs? Try http://penguin.lvcm.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Bug of GCC
Date: Thu, 22 Jul 1999 16:52:03 -0600
"David T. Blake" wrote:
>
> Villy Kruse <[EMAIL PROTECTED]> wrote:
> >How about:
> >
> >
> >#if 0
> > char abc[] = "this is a test
> >#endif
> > char abc[] = "this is another test"
>
[snip]
> DEC OSF cc runs the program without error.
> OSF gcc barfs at unterminated string.
> egcs on linux barfs similarly.
> cc on the SGI compiles and runs it without error.
> gcc on linux barfs on unterminated string constant.
>
> Looks like they divide - free vs proprietary compilers.
>
$ uname -vrs
HP-UX B.10.20 A
$ which gcc
/tools/HP9000/bin/gcc
$ gcc -v
Reading specs from
/tools/HP9000/lib/gcc-lib/hppa1.1-hp-hpux10.10/2.7.2.1/specs
gcc version 2.7.2.1
$ cat test.c
#include <stdio.h>
#if 0
char abc[] = "this is a test
#endif
char abc[] = "this is another test"
main(){
printf("%s\n",abc);
}
$ gcc test.c
test.c:9: unterminated string or character constant
test.c:4: possible real start of unterminated constant
test.c:3: unterminated `#if' conditional
$
------------------------------
From: "Robert M. Stockmann" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: NCR 53C710 Fast SCSI-2 Controller
Date: Fri, 23 Jul 1999 00:51:49 +0200
Mike Coakley wrote:
>
> I am having trouble installing a RedHat 6.0 installation onto a Compaq
> Proliant 4000 with the NCR53C710 controller. The installation simply cannot
> find the controller and cannot continue without it. (I know I shouldn't be
> saying this...) I can install MS WinNT without any problems and the
> controller is recognized and the system boots off of this controller/HD.
> Does anyone out there have any ideas?
>
Have a look here :
http://www.sleepie.demon.co.uk/ncr53c710/index.html
This is an experimental driver, but works OK on my EISA ncr710.
The machine is a Compaq Prosignia (old EISA iron ;)
Ask the maintainer for some redhat 6 bootfloppies :)
I can make them too if you want, but will need to install redhat 6
first.
redhat 5.2 is still my favorite. (on the other hand i have a spare
partition available)
Regards
Robert
--
++---------------------++---------------------------------++
|| R.M. Stockmann || InfoMagic Nederland VOF ||
|| [EMAIL PROTECTED] || Unix administration & support ||
++---------------------++---------------------------------++
Linux: A copylefted Unix-like operating system for several platforms :
http://www.ctv.es/USERS/xose/linux/linux_ports.html
------------------------------
From: Matt <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.lang.c
Subject: Re: lib probs with cc and gcc 2.7.2.3
Date: Fri, 23 Jul 1999 00:05:46 +0100
Fixed the fault
The major problem was UNIXUserEnumeration.c and
UNIXUser.c were identical in the genunix/unknown dir
to the ones in the ../native dir.
Also as Greg pointed out..
#ifdef
#else
#endif
Was a primary cause. But I re-applied the fixes on the
patch and re-checked...
All works now.
Many thanks
Matt
Matt wrote:
>
> Hi,
>
> I am having some major problems compiling and lniking the
> javawebserver 1.1.3 in linux SuSE6.1 (glib2.0.7)
>
> All seems to be going well however when the libserver.so
> file is being created the 'make' fails.
>
> Does anyone know why and how I can correct it please ?
>
> Many thanks
>
> Matt
>
> bash-2.02# cc -v
> Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
> gcc version 2.7.2.3
>
> make -fd jws_inst.mk install
>
> [snip]....
>
> Finished dependencies of target file
> `genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
> Dependency
> `genunix/com_sun_server_realm_unix_UNIXUserEnumeration.c' is older than
> dependent
> `genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
> No need to remake target
> `genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
> Finished dependencies of target file `genunix/unknown/libserver.so'.
> Must remake target `genunix/unknown/libserver.so'.
> cc -shared -fPIC -Igenunix -I/usr/lib/jdk1.1.7/include
> -I/usr/lib/jdk1.1.7/include/genunix -o genunix/unknown/libserver.so
> genunix/unknown/server.o genunix/unknown/UNIXUser.o
> genunix/unknown/UNIXUserEnumeration.o
> genunix/unknown/com_sun_server_ServerProcess.o
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o
> Putting child 0x0806f210 PID 00857 on the chain.
> Live child 0x0806f210 PID 857
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o: In function
> `com_sun_server_realm_unix_UNIXUser_loadFromPasswd':
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o(.text+0x0):
> multiple definition of
> `com_sun_server_realm_unix_UNIXUser_loadFromPasswd'
> genunix/unknown/UNIXUser.o(.text+0x0): first defined here
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o: In function
> `com_sun_server_realm_unix_UNIXUser_checkCrypt':
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o(.text+0xd0):
> multiple definition of `com_sun_server_realm_unix_UNIXUser_checkCrypt'
> genunix/unknown/UNIXUser.o(.text+0xd0): first defined here
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o: In
> function `com_sun_server_realm_unix_UNIXUserEnumeration_setpwent':
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o(.text+0x0):
> multiple definition of
> `com_sun_server_realm_unix_UNIXUserEnumeration_setpwent'
> genunix/unknown/UNIXUserEnumeration.o(.text+0x0): first defined here
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o: In
> function
> `com_sun_server_realm_unix_UNIXUserEnumeration_getNextUserName':
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o(.text+0x20):
> multiple definition of
> `com_sun_server_realm_unix_UNIXUserEnumeration_getNextUserName'
> genunix/unknown/UNIXUserEnumeration.o(.text+0x20): first defined here
> Got a SIGCHLD; 1 unreaped children.
> Reaping losing child 0x0806f210 PID 857
> make: *** [genunix/unknown/libserver.so] Error 1
> Removing child 0x0806f210 PID 857 from chain.
>
> My make file..
>
> ###################################################
> # @(#)Makefile.sol 1.11 97/11/06
> #
> # Solaris-specific makefile for building optional native library
> support.
> # Use this as a starting point for porting to other UNIX platforms.
> #
> # Path to top of Java Web Server distribution tree
> TOP = ..
>
> # Name of the library we're making (given to System.loadLibrary)
> LIBNAME = server
>
> # Location of Java Developer's Kit (and runtime)
> JAVA_HOME=/usr/lib/jdk1.1.7
>
> # Java runtime flags
> JAVAH=$(JAVA_HOME)/bin/javah
>
>CLASSPATH=$(TOP)/classes:$(TOP)/lib/classes.zip:$(JAVA_HOME)/classes:$(JAVA_HOME)/lib/classes.zip
>
> # OS and machine type
> OS = genunix
> ARCH = unknown
> OBJ = $(OS)/$(ARCH)
>
> # Preprocessor, compiler, linker, and related flags
> CC = cc
> CFLAGS = -shared -fPIC
> CPPFLAGS = -I$(OS) -I$(JAVA_HOME)/include
> -I$(JAVA_HOME)/include/$(OS)
> LDFLAGS = #-G -h $(LIBNAME)
> INSTALL = /usr/bin/install
>
> LIBDIR = $(TOP)/lib/$(OBJ)
>
> LIBRARY = $(OBJ)/lib$(LIBNAME).so
> OBJS = $(OBJ)/server.o \
> $(OBJ)/UNIXUser.o \
> $(OBJ)/UNIXUserEnumeration.o \
> $(OBJ)/com_sun_server_ServerProcess.o \
> $(OBJ)/com_sun_server_realm_unix_UNIXUser.o \
> $(OBJ)/com_sun_server_realm_unix_UNIXUserEnumeration.o
>
> default all: $(LIBRARY)
>
> $(LIBRARY): $(OBJS)
> $(LINK.c) -o $@ $(OBJS)
>
> $(OBJ)/server.o: server.c $(OS)/com_sun_server_ServerProcess.h
> $(COMPILE.c) -o $@ server.c
>
> $(OBJ)/UNIXUser.o: UNIXUser.c $(OS)/com_sun_server_realm_unix_UNIXUser.h
> $(COMPILE.c) -o $@ UNIXUser.c
>
> $(OBJ)/UNIXUserEnumeration.o: UNIXUserEnumeration.c \
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.h
> $(COMPILE.c) -o $@ UNIXUserEnumeration.c
>
> $(OBJ)/com_sun_server_ServerProcess.o:
> $(OS)/com_sun_server_ServerProcess.c
> $(COMPILE.c) -o $@ $(OS)/com_sun_server_ServerProcess.c
>
> $(OS)/com_sun_server_ServerProcess.c:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) -stubs
> com.sun.server.ServerProcess
>
> $(OS)/com_sun_server_ServerProcess.h:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH)
> com.sun.server.ServerProcess
>
> $(OBJ)/com_sun_server_realm_unix_UNIXUser.o:
> $(OS)/com_sun_server_realm_unix_UNIXUser.c
> $(COMPILE.c) -o $@ $(OS)/com_sun_server_realm_unix_UNIXUser.c
> $(OS)/com_sun_server_realm_unix_UNIXUser.c:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
> -stubs com.sun.server.realm.unix.UNIXUser
> $(OS)/com_sun_server_realm_unix_UNIXUser.h:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH)
> com.sun.server.realm.unix.UNIXUser
>
> $(OBJ)/com_sun_server_realm_unix_UNIXUserEnumeration.o: \
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c
> $(COMPILE.c) -o $@
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
> -stubs com.sun.server.realm.unix.UNIXUserEnumeration
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.h:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
> com.sun.server.realm.unix.UNIXUserEnumeration
>
> install: $(LIBRARY)
> $(INSTALL) -d $(LIBDIR)
> $(INSTALL) -c $(LIBRARY) $(LIBDIR)
>
> clean:
> rm -rf $(OS)
>
> .INIT:
> -@mkdir -p $(OBJ)
>
> .KEEP_STATE:
------------------------------
From: Matt <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.programmer,comp.lang.java.machine,comp.os.linux.development.apps,comp.lang.c
Subject: Re: building JWS1.1.3 Major Problems.
Date: Fri, 23 Jul 1999 00:08:57 +0100
Fixed the fault
The major problem was UNIXUserEnumeration.c and
UNIXUser.c were identical in the genunix/unknown dir
to the ones in the ../native dir.
Also as Greg pointed out..
#ifdef
#else
#endif
Was a primary cause. But I re-applied the fixes on the
patch and re-checked...
All works now.
Many thanks
Matt
Matt wrote:
>
> Hi,
>
> I am having some major problems compiling and lniking the
> javawebserver 1.1.3 in linux SuSE6.1 (glib2.0.7)
>
> All seems to be going well however when the libserver.so
> file is being created the 'make' fails.
>
> Does anyone know why and how I can correct it please ?
>
> Many thanks
>
> Matt
>
> bash-2.02# cc -v
> Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
> gcc version 2.7.2.3
>
> make -fd jws_inst.mk install
>
> [snip]....
>
> Finished dependencies of target file
> `genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
> Dependency
> `genunix/com_sun_server_realm_unix_UNIXUserEnumeration.c' is older than
> dependent
> `genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
> No need to remake target
> `genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o'.
> Finished dependencies of target file `genunix/unknown/libserver.so'.
> Must remake target `genunix/unknown/libserver.so'.
> cc -shared -fPIC -Igenunix -I/usr/lib/jdk1.1.7/include
> -I/usr/lib/jdk1.1.7/include/genunix -o genunix/unknown/libserver.so
> genunix/unknown/server.o genunix/unknown/UNIXUser.o
> genunix/unknown/UNIXUserEnumeration.o
> genunix/unknown/com_sun_server_ServerProcess.o
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o
> Putting child 0x0806f210 PID 00857 on the chain.
> Live child 0x0806f210 PID 857
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o: In function
> `com_sun_server_realm_unix_UNIXUser_loadFromPasswd':
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o(.text+0x0):
> multiple definition of
> `com_sun_server_realm_unix_UNIXUser_loadFromPasswd'
> genunix/unknown/UNIXUser.o(.text+0x0): first defined here
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o: In function
> `com_sun_server_realm_unix_UNIXUser_checkCrypt':
> genunix/unknown/com_sun_server_realm_unix_UNIXUser.o(.text+0xd0):
> multiple definition of `com_sun_server_realm_unix_UNIXUser_checkCrypt'
> genunix/unknown/UNIXUser.o(.text+0xd0): first defined here
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o: In
> function `com_sun_server_realm_unix_UNIXUserEnumeration_setpwent':
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o(.text+0x0):
> multiple definition of
> `com_sun_server_realm_unix_UNIXUserEnumeration_setpwent'
> genunix/unknown/UNIXUserEnumeration.o(.text+0x0): first defined here
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o: In
> function
> `com_sun_server_realm_unix_UNIXUserEnumeration_getNextUserName':
> genunix/unknown/com_sun_server_realm_unix_UNIXUserEnumeration.o(.text+0x20):
> multiple definition of
> `com_sun_server_realm_unix_UNIXUserEnumeration_getNextUserName'
> genunix/unknown/UNIXUserEnumeration.o(.text+0x20): first defined here
> Got a SIGCHLD; 1 unreaped children.
> Reaping losing child 0x0806f210 PID 857
> make: *** [genunix/unknown/libserver.so] Error 1
> Removing child 0x0806f210 PID 857 from chain.
>
> My make file..
>
> ###################################################
> # @(#)Makefile.sol 1.11 97/11/06
> #
> # Solaris-specific makefile for building optional native library
> support.
> # Use this as a starting point for porting to other UNIX platforms.
> #
> # Path to top of Java Web Server distribution tree
> TOP = ..
>
> # Name of the library we're making (given to System.loadLibrary)
> LIBNAME = server
>
> # Location of Java Developer's Kit (and runtime)
> JAVA_HOME=/usr/lib/jdk1.1.7
>
> # Java runtime flags
> JAVAH=$(JAVA_HOME)/bin/javah
>
>CLASSPATH=$(TOP)/classes:$(TOP)/lib/classes.zip:$(JAVA_HOME)/classes:$(JAVA_HOME)/lib/classes.zip
>
> # OS and machine type
> OS = genunix
> ARCH = unknown
> OBJ = $(OS)/$(ARCH)
>
> # Preprocessor, compiler, linker, and related flags
> CC = cc
> CFLAGS = -shared -fPIC
> CPPFLAGS = -I$(OS) -I$(JAVA_HOME)/include
> -I$(JAVA_HOME)/include/$(OS)
> LDFLAGS = #-G -h $(LIBNAME)
> INSTALL = /usr/bin/install
>
> LIBDIR = $(TOP)/lib/$(OBJ)
>
> LIBRARY = $(OBJ)/lib$(LIBNAME).so
> OBJS = $(OBJ)/server.o \
> $(OBJ)/UNIXUser.o \
> $(OBJ)/UNIXUserEnumeration.o \
> $(OBJ)/com_sun_server_ServerProcess.o \
> $(OBJ)/com_sun_server_realm_unix_UNIXUser.o \
> $(OBJ)/com_sun_server_realm_unix_UNIXUserEnumeration.o
>
> default all: $(LIBRARY)
>
> $(LIBRARY): $(OBJS)
> $(LINK.c) -o $@ $(OBJS)
>
> $(OBJ)/server.o: server.c $(OS)/com_sun_server_ServerProcess.h
> $(COMPILE.c) -o $@ server.c
>
> $(OBJ)/UNIXUser.o: UNIXUser.c $(OS)/com_sun_server_realm_unix_UNIXUser.h
> $(COMPILE.c) -o $@ UNIXUser.c
>
> $(OBJ)/UNIXUserEnumeration.o: UNIXUserEnumeration.c \
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.h
> $(COMPILE.c) -o $@ UNIXUserEnumeration.c
>
> $(OBJ)/com_sun_server_ServerProcess.o:
> $(OS)/com_sun_server_ServerProcess.c
> $(COMPILE.c) -o $@ $(OS)/com_sun_server_ServerProcess.c
>
> $(OS)/com_sun_server_ServerProcess.c:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) -stubs
> com.sun.server.ServerProcess
>
> $(OS)/com_sun_server_ServerProcess.h:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH)
> com.sun.server.ServerProcess
>
> $(OBJ)/com_sun_server_realm_unix_UNIXUser.o:
> $(OS)/com_sun_server_realm_unix_UNIXUser.c
> $(COMPILE.c) -o $@ $(OS)/com_sun_server_realm_unix_UNIXUser.c
> $(OS)/com_sun_server_realm_unix_UNIXUser.c:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
> -stubs com.sun.server.realm.unix.UNIXUser
> $(OS)/com_sun_server_realm_unix_UNIXUser.h:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH)
> com.sun.server.realm.unix.UNIXUser
>
> $(OBJ)/com_sun_server_realm_unix_UNIXUserEnumeration.o: \
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c
> $(COMPILE.c) -o $@
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.c:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
> -stubs com.sun.server.realm.unix.UNIXUserEnumeration
> $(OS)/com_sun_server_realm_unix_UNIXUserEnumeration.h:
> $(JAVAH) -d $(OS) -classpath $(CLASSPATH) \
> com.sun.server.realm.unix.UNIXUserEnumeration
>
> install: $(LIBRARY)
> $(INSTALL) -d $(LIBDIR)
> $(INSTALL) -c $(LIBRARY) $(LIBDIR)
>
> clean:
> rm -rf $(OS)
>
> .INIT:
> -@mkdir -p $(OBJ)
>
> .KEEP_STATE:
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Server linux config
Date: 22 Jul 1999 22:01:00 GMT
In article <[EMAIL PROTECTED]>,
Warren Young <[EMAIL PROTECTED]> wrote:
| Have you changed the ulimits for the user that owns the server
| processes? By default, no user can create as many processes as the
| system can support. Ditto for file handles. It's to guard against
| denial-of-service attacks.
The individual process have only about ten files open, including stdin
and friends and counting mmaped files as open for the sake of argument.
And when the systems gets into this problem the whole system sees it,
including stuff running as root.
It would appear that the kernel is out of fd's, and there must be some
additional place the limit is set. I was hoping that someone knew where
the system fd limit was set, as there are many folks who spend more time
in the kernel code than I do (or ever will unless I hit the lottery).
Thanks for the ulimit suggestions, but that doesn't seem to be the
catch. I'm willing to revisit this if I'm missing something.
I do notice an FD_SETSIZE in posixtypes.h, but that appears to be the
limit of the fd's available to any single process, rather than the
system.
Any more ideas gratefully taken, I hate to think that I have to go to
some other o/s just because of this. The notes and patches I found all
seem to be on 2.0 kernels and haven't shed light on the 2.2 problem. Are
all the web servers running hacked 2.0 kernels?
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
