HDTenEightyP/NetNews huggingface dataset:
From: terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: Multiple processes accessing the same socket/fd
Organization: Novell NPD -- Sandy, UT
Date: Wed, 15 Apr 1992 18:22:23 GMT

In article <12182@ns-mx.uiowa.edu>, dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
|> I've got a situation where I have a single process which connects to a socket
|> in another process, then forks several children, all of which have that same
|> connection.  I want all of these processes to block waiting for a read(2) on
|> that socket, and the first one that is ready (or any of the ready ones if
|> several are ready) to actually do the read and get the data that was sent.

	This is socially acceptable, although getmsg() would be the cannonical
choice, not read().

|> From a viewpoint of the actual inplementation of the read(2) system call, will
|> this work?  Is it possible that certain cases may arise where this will not
|> work as I have outlined?  Or is this purely implementation-specific?

	Yes this will work; however, it may not be the best mechanism.  What will happen
is that all processes sleeping on that socket will wake up, and the ones for which data
isn't available will go to sleep.  The one that gets the actual data will then be
scheduled to run.  This is especially true on SVR4, where the scheduler is distinct from
the kernel sleep().  The act of getting a wakeup() simply means that you are placed
on a read-to-run queue, not that you are actually scheduled.  The scheduler does that.
So you will incurr additional kernel overhead over and above what you expect.

|> I've tried this using accept(2) rather than read, and on the machine I tried
|> it on (an Apollo 425e running Domain/OS 10.4) it resulted in occasional faults
|> due to a reference to illegal address in the accept call.  But doing so with a
|> read has provided consistent results as I have outlined (but I'm still not
|> confident of it for obvious reasons)

	If you are using a TLI-based socket library, the problem is obvious.  A call
was not made to t_sync() to guarantee the data buffers shared in TLI are synced
between the processes.  This should only need to be called once to insure the
location is accessable (and known) to TLI in both cases, say immediately after the
call to fork().

						Terry Lambert
						terry_lambert@gateway.novell.com
						terry@icarus.weber.edu
Newsgroups: comp.unix.internals
From: dps@cbnewsi.cb.att.com (prasad.s.dodrbala)
Subject: Semaphores increase in vmunix
Organization: AT&T
Distribution: usa
Date: Fri, 17 Apr 1992 16:36:58 GMT


Hi I was trying to increase the number of semaphores in my system to have
multiple copies of Informix On-line to work well. This is a sun environment
I don't see any parameter in the configuration file to extend this. But I am
not sure if I can go and change /usr/sys/sys/sem.h file to extend semaphores,
and rebuild vmunix.
If any one had done it before could you please respond to dps@qsun.att.com
If you see /usr/sys/sys/sem.h it has this comments.
/*
 *      Configuration Parameters
 * These parameters are tuned by editing the system configuration file.
 * The following lines establish the default values.
 */
Thanks
Prasad.
From: david@indetech.com
Newsgroups: comp.unix.internals
Subject: Re: swap space
Summary: NFS can be slow
Date: 12 Apr 92 17:21:00 GMT
Article-I.D.: indetech.1992Apr12.172100.10137
Organization: Independence Technologies, Inc. Fremont, CA

In article <140@adagio.UUCP> grog@adagio.UUCP (Greg Lehey) writes:
>As has been said, swapping from the swap space is not faster than
>swapping from the text file.

NFS.  Slow servers => slower clients.  Slow network => slower clients.
Dead servers => dead clients.  All from paging text pages over NFS.
Swapping to the swap disk can be faster.

On my little workstation, swap space comes in at 5.0Mb/sec synchronous
according to the boot message.  The ethernet routinely delivers pages
slower than that.  Our site doesn't have 50 copies of Openwindows out
on individual workstations because it makes things slower.

It would be great if there were an option to mount(8) that said "don't
page text pages from this disk" and the system believed it and paged
them to swap instead.  Then it would be possible to have a workstation
with a disk that booted over the network, but had swap and only swap
(and /tmp if tmpfs isn't workable) on the local disk.  Maintaining
workstations just got a bunch easier since you no longer have to worry
about the disk and the OS and data on it.  OS upgrades are trivial,
just change the bootp database and reboot.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: Accessing the PROCess table (how?)
Date: 16 Apr 92 02:27:42 GMT
Organization: Auspex Systems, Santa Clara

In article <1992Apr14.160552.12365@gateway.novell.com>, terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert) writes:

> 6)	Some information may not be available, since many things in the kernel
> 	can be swapped out, and a reference to /dev/kmem may not be sufficient
> 	to fault them in.  In particular, the user struct may be unavailable
> 	(this is not true of SunOS, which does not swap or relocate it's user
> 	structs).

Wrongo.  At least in 4.1[.x], it *does* page out U areas.

In article <1992Apr15.201258.9108@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:

>Only the currently running process' (ie. your proc table snooper) u-area
>will be mapped by /dev/kmem.

Wrongo.  In SunOS 4.1[.x], U areas aren't handled the "traditional" UNIX
way, in which they're always at a fixed virtual address, which is
remapped on a context switch.  They're all at *different* virtual
addresses in kernel space.

The problem is that with the usual Sun virtual address cache scheme (as
first appeared on the Sun-3/2xx - yes, that's a "3" there), the U area
in the "traditional" scheme has a kernel-only mapping, and cache lines
for which the virtual address is a kernel-only address are *not* tagged
with a context number.  This means that when an MMU context switch is
done, the U area has to be flushed from the cache; this slowed down
context switches.

(This was, I think, responsible for much of the noise about How Bad
SPARC Machines Are At Context Switches in the SunOS 4.0[.x] time frame;
the Sun-4/2xx had the same virtual address cache scheme, and the main
context switch overhead was with flushing the U area - a problem shared
with the Boring Old 68020-based 3/2xx - not with register windows. 
Maybe register windows are the problem in 4.1[.x], and maybe not.)

SunOS 4.1[.x] puts U areas all at *different* virtual addresses, so "u",
rather than being #defined as "(struct u *)MAGIC_ADDRESS" (where
"MAGIC_ADDRESS" was chosen to allow short offsets to be used in 68K
instructions referring to the U area), is #defined as "(*uunix)", where
"uunix" is a global pointer to the current process's U area.

>You will have to use /dev/mem and/or /dev/swap
>(or /dev/drum or whatever it's called to find u-areas).  Reads on /dev/kmem
>will certainly _not_ `fault them in'.

Actually, in SunOS 4.1[.x], touching that region of the kernel's virtual
address space *does* fault them in....

(And in 4.4BSD, the U area is probably going to be *non-existent*.  In
other words, the way you get at the U area - assuming there even *is* a
U area - is dependent on the flavor of UNIX under which you're running. 
Given that the person didn't say what flavor of UNIX he was doing this
on, there are limits to how much information we can give him about
reading the U area, or even about reading the proc table....)
Newsgroups: comp.unix.internals,comp.unix.sysv386
From: ihno@generics.ka.sub.org (Ihno Krumreich)
Subject: Re: swap space
Organization: Generics GmbH
Date: Mon, 13 Apr 1992 19:48:26 GMT

In <nc00.702638653@hawk> nc00@eurotherm.co.uk (Neil Corlett) writes:

>andyb@wndrsvr.la.ca.us (Andy Brager) writes:

>>pavlov@niktow.canisius.edu (Greg Pavlov) writes:


>>Ok, I've heard various claims like this.  I would love to know the
>>reasoning behind it.  No doubt I'll be flamed for not already knowing
>>the answer to my question, but what the hell.  You only burn once :)

>>Why would you need more swap space then memory?   I believe I've
>>been told "so you can do a system dump".  What?  To floppy?  I
>>have 32M of memory.  I'm supposed to dump 96M to floppy?  Someone
>>pass me a clue please?  Thanks!

>At least on Interactive you must have at least as much swap as memory.

Not only for Interactive, but for every SVR4 flavour running on intel.

>The reason is that when the kernel panics and writes memory into
>/dev/swap it assumes there is enough space to do so. If you have less
>swap than memory, the kernel will merrily write into the following
>partition, trashing it.

So the importent thing is, that your first swap partition on the first disk
is big enough.

>The base rule is MORE SWAP THAN MEMORY. Break it at your own peril. Of
>course, some vendors may have more intelligent kernels...

>Finally, you do not have to dump to tape/floppy. When your machine
>first comes up, and before anyone gets to make it swap, run crash on
>/dev/swap. This does not work on SVR4's because they write into
>/dev/swap during boot. It works on Interactive.

Sorry, but it also works on other SVR4's. Before they startup the system,
they ask you, whether you want to save the dump thats in the swap or not.

For SVR4 you need minimum the physical size of the memmory as swap, because
every page in memory needs a physical backup. This was not the same in SRV3.
There it is possible to run a machine with 64M physical memory and 10M of
swap. The only problem comes up, if the kernel panics as described above.

It should be remarked, that extending the swap in SVR4 is now much easier
then in SVR3. Just create a big file somewhere (best place would be a different
disk) and use the swap command to add this file to your virtuel memory.

Ihno
-- 
Ihno Krumreich     | Phone (49) 721 38 70 94
Generics Gmbh      | email: ihno@generics.ka.sub.org
Breite Strasse 24  | FAX   (49) 721 38 56 22
D-W7500 Karlsruhe  |
Newsgroups: comp.unix.internals
From: tom@flood.com (Tom Chatt)
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Organization: The Flood Group, Inc.  Torrance, Ca.
Date: Tue, 14 Apr 92 19:07:57 GMT

gus@progress.COM (Gus Bjorklund) writes:
| Is there a way to find out of a file is on a filesystem that is NFS mounted
| (or some other remote filesystem)? I need to know if my transaction log files
| and/or database files are not on the local filesystem.

Of course, the real answer is to make NFS work right, such that one
wouldn't have to care. That is the theory, isn't it?

What is it about databases that get burned by NFS? Is it the
file locking? Isn't it possible to solve the problems some other
way?

It is very annoying to a consumer of a database product to get
back complaints when not running on the local filesystem. For
most things, NFS works so smoothly that one generally doesn't
know nor care which file systems are where.

(Then again, the products that detect when they are running on
NFS and complain about it are better than those products that
just don't work right for seemingly random reasons, until you
figure out that it's NFS...)

-- 
Tom Chatt                        \   Don't take offense, take action.
Internet: tom@flood.com           \    Speak up. When we remain silent,
UUCP: ...!uunet!flood!tom        / \     we oppress ourselves.
Newsgroups: comp.unix.internals
From: terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: lseek(..., SEEK_END) behaviour
Keywords: lseek holey file
Organization: Novell NPD -- Sandy, UT
Date: Fri, 17 Apr 1992 20:29:58 GMT

In article <1992Apr16.091643.18604@west.nl>, gertjan@west.nl (Gertjan van Oosten) writes:
|> The following behaviour occurs under SunOS (both 4.0 and 4.1):
|> 
|> If I seek beyond EOF [with lseek(..., SEEK_END)], and do it again, the
|> second lseek() does not seek from the last seek position, but from the last
|> written byte [example program below].
|> The manual says:
|> 
|> "                                  ...  If  whence  is  SEEK_END,
|> "    the seek pointer is set to the size of the file plus offset.
|> 
|> [The manual pages in 4BSD, X/Open and SVID make similar statements.  Note
|>  that SunOS, 4BSD and SVID mention holes, X/Open does not.]
|> 
|> What I want to know is:
|>   a. Do you consider this behaviour correct (w.r.t. the man-page)?

	Yes.  Unless you do a write, you do not update the end of the file.  This is
because the "end of file" is determined relative to the information in the locked
vnode rather than from your "struct file" for that particular open instance, as
indexed by the fd off the user struct.  No write means no update to the vnode;
this is definitely correct behaviour, since seek pointers are farcical entities in
the struct file anyway.  Take a look at "lseek()" sources in BSD 4.3 Tahoe.

|>   b. Do you want this behaviour?

	Yes.  It is a definite performance win, especially with "holey" file systems, like
UFS.  Real device access (such as would be required to update the actual inode,
given that you might extend your example to close and reopen after your first lseek)
is the slowest thing you can do on a computer.

					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
From: dan@cs.pitt.edu (Dan Drake)
Newsgroups: comp.unix.internals
Subject: Bsd file system reference
Date: 8 Apr 92 23:41:01 GMT
Organization: Computer Science Dept., University of Pittsburgh

Can someone e-mail me some references on describing the bsd file system?

thanks

dan.

dan@cs.pitt.edu
From: rrybacki@ringer.cs.utsa.edu (Richard M. Rybacki)
Newsgroups: comp.unix.internals
Subject: Re: UDP Broadcast?
Date: 7 Apr 92 20:46:00 GMT
Organization: University of Texas at San Antonio


>      I am confused as to how to get a server to
> broadcast to n clients useing UDP. I would 
> greatly appreciate it if anyone could
> provide me with a code fragment for doing this.
>	 -- Wayne

This was snipped out of a working program Wayne, I hope it helps.

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>

#define PORT_NUMBER			XXXXX

	struct sockaddr_in	in_name;
	struct hostent *hp, *gethostbyname();
	int sockopt = 1;
	int	the_sock;

	.
	.
	.

	/* Create a socket */
	if ((the_sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
	{
		perror("failed to create socket");
		return(0);
	}

	/* Setup the socket to read from anybody */
	in_name.sin_family = AF_INET;
	in_name.sin_addr.s_addr = INADDR_ANY;
	in_name.sin_port = htons(PORT_NUMBER);
	if (bind(the_sock, &in_name, sizeof(in_name))) 
	{
			perror("failed to bind socket");
			return(0);
	}

	/* Setup socket to allow broadcast datagrams */
	if (setsockopt(the_sock, SOL_SOCKET, SO_BROADCAST, &sockopt, 
		sizeof(sockopt)) < 0)
	{
		perror("setsockopt");
		return(0);
	}

	.
	.
	.

	/* Send a broadcast datagram */
	struct sockaddr_in	out_name;

	out_name.sin_family = AF_INET;
	out_name.sin_port = htons(PORT_NUMBER);
	out_name.sin_addr.s_addr = YOUR_NETMASK_HERE;

	if (sendto(the_sock, buffer, size, 0, &out_name, sizeof(out_name)) < 0)
	{
		perror("sendto failed");
		return(-1);
	}
-- 
Richard M. Rybacki                |     Happiness = Reality - Expectations
rrybacki@ringer.cs.utsa.edu       |     -- Click & Clack, The Tappet Brothers
Xref: sparky comp.unix.internals:1127 comp.unix.sysv386:8711
From: nc00@eurotherm.co.uk (Neil Corlett)
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: swap space
Date: 16 Apr 92 10:05:41 GMT
Organization: Eurotherm Limited

ihno@generics.ka.sub.org (Ihno Krumreich) writes:


>Sorry, but it also works on other SVR4's. Before they startup the system,
>they ask you, whether you want to save the dump thats in the swap or not.

Yes, you can save the dump to tape or floppy but you cannot run crash upon
/dev/swap after boot. The reason is that most SVR4s write across the first
block on the tape drive during boot. The /sbin/bcheckrc file is fired up from
inittab, runs /sbin/dumpcheck and then writes a 512 byte block into
/dev/rswap. That is what Dell SVR4 does, anyway. It is to stop you getting
repeated offers to dump after each reboot. Look in /sbin/bcheckrc.

>For SVR4 you need minimum the physical size of the memmory as swap, because
>every page in memory needs a physical backup. This was not the same in SRV3.
>There it is possible to run a machine with 64M physical memory and 10M of
>swap. The only problem comes up, if the kernel panics as described above.

Is anybody _really_ that confident in their OS vendor? I do hope not! :-)

Neil
--
ncorlett@eurotherm.co.uk
Eurotherm Limited on +44 903 268500
Newsgroups: comp.unix.internals
From: terry@ithaca.npd.Novell.COM (Terry Lambert)
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Organization: Novell NPD -- Sandy, UT
Date: Thu, 9 Apr 1992 16:03:57 GMT

In article <1992Apr8.162438.2218@progress.com>, gus@progress.COM (Gus Bjorklund) writes:
|> Is there a way to find out of a file is on a filesystem that is NFS mounted
|> (or some other remote filesystem)? I need to know if my transaction log files
|> and/or database files are not on the local filesystem.
|> 
|> So far the only thing I have come up with is to read /etc/mtab (using
|> getmntent ()) but this is fairly ugly because I have to look for
|> a partial match with the pathname of the file and there may be more than one.
|> This works on Sun but is not very portable.
|> DEC tells us that there is no way on Ultrix.
|> 
|> Digging through the kernel tables is not a viable option because it may break
|> when the os is updated and it isnt likely to port easily anyway.

	Not to mention if the file is o symbolic link on a local partition to a remote
one :-(.

	The easiect way I have found to do this is to go through the /etc/mtab, as you
are doing... but instead of trying path matches, I stat and keep a table of the device
identifier (this varies depending on if you are VFS or not, so I can't give you a real field
name).

	Then I stat (following symlinks) the file I am interested in and check it's device.

	Currently, I don't take multiple symlinks into account, nor do I take non-origin
symlinks (a local symlink to a remote symlink to a local file) or mount point traversal
of a remote fs back to a local fs (ie: / is local, /biff is NFS, /biff/foo is local) into account,
This could be done by iterating and statting the directory components on an individual
basis.

	Hope this helps...

						Terry Lambert
						terry_lambert@gateway.novell.com
						terry@icarus.weber.edu
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Newsgroups: comp.unix.internals
Subject: Multiple processes accessing the same socket/fd
Date: 15 Apr 92 10:48:22 GMT
Organization: ISCA

I've got a situation where I have a single process which connects to a socket
in another process, then forks several children, all of which have that same
connection.  I want all of these processes to block waiting for a read(2) on
that socket, and the first one that is ready (or any of the ready ones if
several are ready) to actually do the read and get the data that was sent.

From a viewpoint of the actual inplementation of the read(2) system call, will
this work?  Is it possible that certain cases may arise where this will not
work as I have outlined?  Or is this purely implementation-specific?

I've tried this using accept(2) rather than read, and on the machine I tried
it on (an Apollo 425e running Domain/OS 10.4) it resulted in occasional faults
due to a reference to illegal address in the accept call.  But doing so with a
read has provided consistent results as I have outlined (but I'm still not
confident of it for obvious reasons)

Any ideas on this?  I'd like to be able to do it, but don't want to if I can't
be reasonably sure the solution is fairly bulletproof and generally portable.
Thanks!

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                | "I don't have to take this abuse from you --  |
|                             |  I've got hundreds of people waiting in line  |
| dsiebert@icaen.uiowa.edu    |  to abuse me."  -  Bill Murray, Ghostbusters  |
\-----------------------------------------------------------------------------/
SIGNATURE VIRUS 3.0b, NEW AND IMPROVED -- NOW EVEN LOUDER AND MORE ANNOYING!!!!
Newsgroups: comp.unix.internals
From: dan@dribble.c-mols.siu.edu (Dan Ellison)
Subject: Re: setuid in daemon spawned from init
Organization: Southern Illinois University - Carbondale, IL (SIU-C)
Distribution: usa
Date: Tue, 7 Apr 1992 19:41:38 GMT

In <bof.702201807@midget.saar.de> bof@midget.saar.de (Patrick Schaaf) writes:

>video@hounix.org (David Schroeder (US Videotel)) writes:
>>This problem involves daemon processes on SCO unix.
>>I have a process spawned from a server, which then gets the username,
>>validates the password and then tries to setuid to the uid of that user.
>>I had trouble with the setuid part of it, getting an error that I am
>>not superuser even though the server process was started from init,
>>[...]
>>Processes spawned from init do not have root privileges?

>Look at the manpage for setluid(S). Before the setuid(), do an
>  setluid(getuid());
>and link your daemon with -lprot.

>Patrick

It could get even worse than that since you're checking passwords....
You'll have to define -DSecureWare and deal with the set_auth_parameters
stuff and play with the coding to get the *REAL* password from the protected
data base as well.  SecureWare is wonderful B^{.

The manual does give *SOME* information on using it but NOT MUCH!
Good luck.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Dan Ellison, Network Admin	  -    	Molecular Science Program SIU-C | 
| Southern Illinois University 	  - 	Carbondale, IL 62901            |   
| FAX:      (618) 453-3459        -   	PHONE:    (618) 453-7310 	|
From: hagiwara@sm.sony.co.jp (Takashi Hagiwara)
Newsgroups: comp.unix.internals
Subject: NEED INFO: DLPI Specifications
Date: 8 Apr 92 02:32:35 GMT
Organization: Supermicro Systems Group, Sony Corporation, Tokyo, Japan

Could anyone tell me how to get "White Paper - Streams Based Data-Link Provider?
Also, any information on DLPI is appreciated.

Thanks in advance.


Takashi Hagiwara
Sony Corporation
From: kevinc@sequent.com
Newsgroups: comp.unix.internals
Subject: Re: Unix kernal diagram
Date: 9 Apr 92 23:56:43 GMT
Article-I.D.: sequent.1992Apr9.235643.10463
Organization: .

In article <1992Apr7.043550.7500@candle.uucp> root@candle.uucp (Bruce Momjian) writes:
>suggestions or corrections, I would be glad to include them.  It is 57
 ^^^^^^^^^^^^^^^^^^^

>                |    |kernal| /             >|___|-- /->|______|
>                |    |______|/               |___|---   |______|    
>                |                            |___|----->|______|  /
>                |                                       |kernal| /

    Spell KERNEL right :-)



________________
Kevin A. Closson,  Technical Support Engineer  voice:    (503)578-3072
Technical Support Database Group,              FAX:      (503)578-5453
Sequent Computer Systems
15450 SW Koll Pkwy (MS WIL1-4M-2)              UUCP:     ..uunet!sequent!kevinc
Beaverton, Oregon 97006-6063               internet:     kevinc@sequent.com
Newsgroups: comp.unix.internals