Newsgroups: comp.unix.aux
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!cmcl2!panix!alexis
From: alexis@panix.uucp (Alexis Rosen)
Subject: A variety of small but annoying bugs in A/UX 2.0.1
Message-ID: <1991Mar28.074451.4116@panix.uucp>
Date: Thu, 28 Mar 91 07:44:51 GMT
References: <1991Mar28.071337.1542@panix.uucp>
Organization: PANIX - Public Access Unix Systems of NY

While I think that these are bugs in A/UX, it's likely that some are due
solely to my ignorance or carelessness. Does anyone know for sure if the
following bugs are really bugs?

1) More
More seems to hate job control. If I ^Z out of more and then fg back to
it, it won't let me use the space bar to see more pages. Some commands,
such as 'f' and ':n', work fine. This problem appeared when I upgraded to
2.0.1.

2) ps
At some times, for no reason that I can see, ps will return the heading line,
but list no processes. There's no underlying problem with the system that
could cause ps to fail, though, because "ps -ef | grep {myusername}" will
show the process list that "ps" should have. This has been a problem since
2.0 at least, maybe 1.1 even.

3) man macros
This one drives me nuts. I've created man pages to various packages like
Cnews, ELM, and rn, and they ALL exhibit the same problems- headers being
wrapped in the middle of the page, characters being repeated, etc. This
doesn't make things unreadable, just very ugly.

4) man
Speaking of man, there has been no fix for the problem of man not waiting
at the end of one man page before showing the next. Also, it still has
minor problems with I/O redirection.  More importantly, the -T flag doesn't
seem to work right- with "-Tdumb", the output is still full of backspaces
and repeated characters. (Is this a bug or a 'feature?')

5) sash (A/UX startup)
Sash has a really nasty problem- as far as I can tell, pname doesn't work in
sash, and there seems to be no way to get to more than one partition per
disk drive from within sash. In other words, if I have a partition at
/dev/dsk/c3d0s3 and another at /dev/dsk/c3d0s4, sash will always see the
first as (3,0,0), and won't find the second, no matter what you call it.

6) inetd
There is something _really_ _wrong_ with this thing. I don't know what, but
I know that if you jam up the mail subsystem, various sendmail processes will
stick around _forever_ (kill -9 won't kill them), untill you kill inetd. Then
they unjam, deliver their mail (which may mean bouncing them- I'm not talking
about the rmail bug directly, here), and terminate normally. In a similar
manner, in.talkd can become unusable. Killing it won't help, until you kill
inetd as well. Then, killing in.talkd will resolve the problem.
	I've read about various problems with SLIP in this group. Could there
possibly be some connection there with the inetd problem?

7) /etc/wtmp, /usr/spool/mqueue/syslog, etc.
These files will grow without bounds until they totally consume your disk.
A/UX ought to come with a cron job pre-installed which trims these files.
There may be others as well (I don't remember offhand).

8) inittab
The sendmail line in the default inittab sets up one sendmail to look for
SMTP mail, and also to run the queue every half hour. If you aren't connected
to a network, you shouldn't do the first of those two things, but you should
still run the queue.

9) Permissions
Various permissions are set up wrong. The most obvious of these is
/usr/spool/uucp, which should be owned by and grouped to uucp, mode 755.
I think /usr/lib/uucp was overly secure in the default setup as well, but
I don't remember... and come to think of it, I believe that PATH and umask
are still set incorrectly vy /etc/cshrc and /etc/profile. The problem is
that umask is too permissive (though this is really a matter of opinion).
More importantly, root always gets a PATH with '.' in it. This is a major
security problem.


There are probably more, but these are the ones that I have to deal with
most.

(The last three items are fixed on this system. While installing 2.0.1, I
think I noted that all of these problems still existed. I won't swear to
it, though. The other six are seen constantly.)

---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
{cmcl2,apple}!panix!alexis