Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (04/09/85)
Unix Technical Digest Tue, 9 Apr 85 Volume 1 : Issue 41
Today's Topics:
Administrivia
Bug in csh? (exec v. job control) (2 msgs)
Daylight Saving time (2 msgs)
File system limit in 4.2 BSD (2 msgs)
HELP - Background jobs in csh (2 msgs)
----------------------------------------------------------------------
Date: Tue, 9 Apr 85 16:56:31 GMT
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Subject: Administrivia
Just a couple of notes. First, I still plan to stop reading the net.unix
and net.unix-wizards groups at the end of April, so submissions should start
getting sent to me instead of being submitted to them. Second, I have
received several pieces of mail addressed to netnews@wnuxb.UUCP and
heiby@wnuxa.UUCP. While these do in fact reach me (today), they are
not guaranteed to do so in the future. Also, anything that is sent to
"heiby" is assumed to be personal and anything sent to "netnews" is assumed
to be related to news administration. If you want to talk with me about
mod.unix, please send your (at least initial) message to unix-request
on cbosgd. Submissions for posting must be sent to unix@cbosgd.UUCP.
Thanks. Ron.
------------------------------
Date: 3 Apr 85 22:19:31 GMT
From: greg@ncr-tp.UUCP (Greg Noel)
Subject: Bug in csh? (exec v. job control)
There seems to be a bug in the way the C shell's exec function interacts
with job control. The quickest way to show it:
- Run the C shell and make sure that the SHELL environment variable
is set to /bin/csh.
- type "vi garbage-file" to get a program that will create a shell.
- type ":sh" to get a shell. The C shell should prompt you.
- type "exec echo foo" -- actually, exec any program. In theory,
this should run the specified program and then return to the editor.
Now tell me, why was the editor stopped with a "tty output"?
--
-- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA
------------------------------
Date: 12 Apr 85 05:49:31 GMT
From: anton@ucbvax.ARPA (Jeff Anton)
Subject: Bug in csh? (exec v. job control)
For those few who understand how the "process group" has been abused
in the name of job control this should be understud.
The new csh changed the process group of the terminal then the
csh execs foobar and the process dies. The vi wakesup from the
forked process dying and tries to print something. The vi's process
group now does not match the terminals so the system sends the process
group a SIGTOUT stopping is. The csh that forked vi finds that
the vi has stoped and then gives you control to fg it.
The whole process group, job control stuff is very messy.
If you had a /bin/sh, ran vi, changed vi to call a csh, did the
shell escape and exec command your terminal would be hung since
vi's process group would include your /bin/sh. Very nasty.
Ever wonder why 'suspend' on a login shell prints:
Can't suspend a login shell. (yet)
--
C knows no bounds.
Jeff Anton
U.C.Berkeley
ucbvax!anton
anton@berkeley.ARPA
------------------------------
Date: 28 Mar 85 16:56:48 GMT
From: leif@erisun.UUCP (Leif Samuelsson)
Subject: Daylight Saving Time
In article <471@grendel.UUCP> avolio@grendel.UUCP (Frederick M. Avolio) writes:
>>
>> Well, it seems that all 4.2BSD machines in Europe went on
>> DST a week too early this year...
>
> One other solution --- I believe this is good for any 4.2bsd
>based U*ix. When you configure the system specify dst followed by a
>number. 1 = usa, 2=australia, 3=w. europe, 4=central europe, and 5= e.
>europe.
This isn't the problem. The code is *wrong* for group 3 and 4 of
the above. If we hadn't specified a "4" for our machine, we would
have had to wait another *month* for DST to happen. (It's this
sunday, folks!)
It's hard work to correct the code in ctime.c for a system
administrator, even with the sources, because it does not reside in
the kernel. It is linked in with every routine that deals with
time, like "date".
I think a solution would be to handle the timezone and dst
business with the "date" command and have the algorithms in the
kernel instead. That way you could specify the timezone and dst
in your /etc/rc like this:
date -tMET -d4
Leif Samuelsson
Ericsson Information Systems AB ..mcvax!enea!erix!erisun!leif
Advanced Workstations Division
S-172 93 SUNDBYBERG 59 19 N / 17 57 E
SWEDEN
------------------------------
Date: 3 Apr 85 06:52:17 GMT
From: njh@root44.UUCP (Nigel Horne)
Subject: Daylight Saving time
Not only 4.2BSD, but also System V. Ho hum, still the week soon went by.
--
Nigel Horne <njh@root44.UUCP>
Root Computers Ltd.
{deccra,edai,glasgow,hirst1,ist,kcl-cs,qmc-cs,rlvd,pmllab,stc-a,ubu,
ukc,unisoft}!root44!rootcl!njh
------------------------------
Date: 31 Mar 85 19:14:08 GMT
From: mojo@sun.uucp (Joseph Moran)
Subject: File system limit in 4.2 BSD
In article <681@rayssd.UUCP> dhb@rayssd.UUCP writes:
>Has anyone ever successfully gotten more than 15 file systems on a 4.2 BSD
>system?
>We have been trying to track what we thought
>was a weird swapping error for three months (tues and wed eve.) and have
>now been running smoothly WITHOUT the coremap changes for over two weeks.
Your problem is the "Fastreclaim" code in vax/locore.s. This code is
an optimization put into 4.2. This code knows about the cmap
structure. If you change anything in the cmap structure w/o rewritting
this code, you are bound to get bad paging problems. As it turns out,
you can take out the call to Fastreclaim as it is simply an
optimization, in the long run you'll want to rewrite the code for your
new cmap structure. It turns out that this code also knows a few other
magic numbers also, w/o using the right symbols to reference them (like
UPAGES). The second problem can be avoided by figuring out some of the
magic numbers in the code and putting in an expression using the right
symbols.
It turns out that we were bit by this same problem here at Sun twice.
We changed the cmap structure for use with the nfs (network file
system). We had a hard time figuring out why random pages got paged in
incorrectly and processes were dying when we were running the nfs
kernel until it was tracked down to Fastreclaim. Later we were playing
with changing UPAGES and got bit by Fastreclaim again. Sometimes
changing .h files doesn't do everything it really needs to. Hats off
to Bill Shannon for finding both of these.
Joe Moran
sun!mojo
------------------------------
Date: 3 Apr 85 23:05:11 GMT
From: chris@umcp-cs.UUCP (Chris Torek)
Subject: File system limit in 4.2 BSD
I strongly urge all 4.2 VARs to do something about this. BRL (and UCB
and others) have modified h/cmap.h to contain #defines for use by
locore.s. This at least centralizes the information. (By the way, I
have a sneaking suspicion that Fastreclaim was done as a quick hack by
the Franz group. Anyone "in the know" care to comment?)
[Excerpts from the BRL version of h/cmap.h:]
/*
* core map entry
*
* Limits imposed by this structure:
*
* limit cur. size fields
* Physical memory+ 64 Mb c_next, c_prev, c_hlink
* Mounted filesystems 255 c_mdev
* size of a process segment 1 Gb c_page
* filesystem size 2 Gb c_blkno
* proc, text table size 1024 c_ndx
*
* + memory can be expanded by converting first three entries
* to bit fields, shrinking c_unused, and increasing MAXMEM below.
*/
#ifndef LOCORE
struct cmap
{
[...]
};
#else LOCORE
/*
* bit offsets of elements in cmap
*/
#define C_INTRANS 66
#define C_FREE 67
#define SZ_CMAP 16 /* sizeof(struct cmap) */
#define MAXMEM 64*1024 /* maximum memory, in Kbytes */
#endif LOCORE
[...]
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland
------------------------------
Date: 5 Apr 85 13:47:24 GMT
From: gda@creare.uucp (gda)
Subject: HELP - Background jobs in csh
Can anyone suggest a way for a program to know if it's running
in background ? We have a program that is partly interactive,
but when run in background we want it to skip the interactive
part. We tried checking if STDIN was a tty, but that didn't help.
We think it could call up "ps" and look for itself, but there must
be an easier way...
Thanks for your help (in advance).
Gray Abbott
Creare Inc.
{...dartvax!creare!gda}
------------------------------
Date: 8 Apr 85 20:34:04 GMT
From: anton@ucbvax.ARPA (Jeff Anton)
Subject: HELP - Background jobs in csh
Background and foreground jobs are determined by process group.
A background process (job) will have a different process group
than the terminal. You get the terminal process group with TIOCGPGRP
as described in tty(4). Compare this with getpgrp(2).
--
C knows no bounds.
Jeff Anton
U.C.Berkeley
ucbvax!anton
anton@berkeley.ARPA
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)