Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1993-12-07/mail-archive/linux-admin/Volume1/digest189
2024-02-19 00:24:15 -05:00

599 lines
21 KiB
Plaintext

From: Digestifier <Linux-Admin-Request@senator-bedfellow.mit.edu>
To: Linux-Admin@senator-bedfellow.mit.edu
Reply-To: Linux-Admin@senator-bedfellow.mit.edu
Date: Sat, 27 Nov 93 08:13:14 EST
Subject: Linux-Admin Digest #189
Linux-Admin Digest #189, Volume #1 Sat, 27 Nov 93 08:13:14 EST
Contents:
Re: Process table filling (Joerg Lenneis)
Re: Difference between cua and ttyS (Ed Casas)
Taylor UUCP 1.04 fails EAGAIN on 0.99.12 (Intellection)
Re: Can't run VI (Chris O'Regan)
Re: Once again, using tape drives under Linux (Jim Kunzman)
Re: How to send commands to /dev/modem or /dev/cua1 ? (Laszlo Herczeg)
Re: [Q] How to make a socket? (Laszlo Herczeg)
[Q] LILO doesn't work from my IDE MBR (Norman Ramsey)
[Q] help wanted with "/dev/cua1: Device or resource busy" (Norman Ramsey)
Re: Can't run VI (Drew Eckhardt)
sz problems (Paul McIntire)
Re: [Q] How to make a socket? (Daniel Garcia)
Re: SLIP FAQ (Terry Dawson)
Re: NFS proplems (Remco Treffkorn)
Re: Shadow passwords? (H.J. Lu)
Re: Taylor UUCP 1.04 fails EAGAIN on 0.99.12 (Dr Eberhard W Lisse)
----------------------------------------------------------------------------
From: lenneis@wu-wien.ac.at (Joerg Lenneis)
Subject: Re: Process table filling
Date: 26 Nov 1993 17:52:08 GMT
John Will (john.will@satalink.com) wrote:
: ER>: I'm having some difficulties with process tables filling up. If my box sits
: ER>: idle for more than about 2 hours, I find that the process table gets filled
: ER>: with zombies spawned by rpc.portmap. I can get rid of the zombies by
: ER>: killing rpc.portmap, but I'd like to know if there is a solution...
: ER>...
: ER>: For details, I'm running pl13r, 16 megs RAM, NET-2-debugged. Please email
: ER>: me with any leads.
: ER>
: ER>I don't know about you, but I had to go back down to 0.99.13p to get rid of
: ER>these. :( Same problem here...
: I'm running 99pl13r on a local Ethernet network here, and it's been up
: for days, no zombies from anyone. There must be something that causes
: them other than the version of the kernel...
There definitely must be. We are on quite a busy network and have experienced
three different problems that must be caused by something "coming from outside":
- Heaps of portmappers get started for no apparent reason.
- Heaps of popd processes. I think this is caused by Macintoshes running the
Eudora POPmail client, since I traced the machines trying to connect and they were
without exeption MACs.
- From time to time there are tons of the following message:
ARP: ARPing my own IP address 127.0.0.1 !
This means that either something is really sending out ARPs for 127.0.0.1 or the
kernel is tricked into thinking so. This always occurs in bursts, so I think that
some machines on the net in a particular configuration are started up and cause
this.
I have upgraded to 99pl13s as of yesterday, but we have had this problems for
all of Patchlevel 13, including 99pl13s.
--
Joerg Lenneis
University of Economics and Business Adminstration
Department for Applied Statistics and Data Processing
Augasse 2-6, 1090 Vienna, Austria
Tel. *43/222/31336 4758
email: lenneis@wu-wien.ac.at
------------------------------
From: edc@fs0.ee.ubc.ca (Ed Casas)
Subject: Re: Difference between cua and ttyS
Date: 26 Nov 1993 18:31:40 GMT
In article <CGuECC.6y7@hphbbs.e.open.de>, <hph@hphbbs.E.open.DE> wrote:
>
>In article 93Nov7222819@dynamo.dyndata.com,
> dan@dynamo.dyndata.com (Dan Everhart) writes:
>>
>> What exactly is the difference between /dev/ttyS<n> and /dev/cua<n>?
>> I.e. device majors 4 and 5.
>>
> I just want underpin this request. I asked the very question
> a couple of times but no one could give a resonable answer
> about this topic. Instead I recently got a
> getty-implementation in my hands, where was said:
>
> "... on LINUX use the ttyS-devices not the cua-devices. No, I'm not
> willing to disuss this here ..."
> ...
>
> "Undocumented software is shitware!"
I agree. Source code is not enough. I believe people who
release material for public consumption have a responsibilty to
document their work.
The only thing I can suggest is that you keep clear of
undocumented sofware. Lack of documentation is often an
indication of poorly conceived and executed work.
The problem with lack of documentation for Linux in general (and
the serial driver in particular) is that the code is based on
documentation for BSD-ish systems (SunOS, SysVR4) or Posix. This
documentation is readily available to the developers but can't be
released with the code since it is not in the public domain(?).
In any case... the following explanation is taken from the
README.linux file from mgetty_ps. It should give you an idea of
how it's meant to work. Also, if you have access to, for
example, SunOS documentation (man 4 zs) you'll find that other
cua devices work in a similar way.
========================================================================
1. NEW SERIAL DRIVERS
To many people's surprise (and a few people's disgust), the serial
drivers have been upgraded. The basic idea behind the new drivers
is that callin and callout devices should not try to use the same
line at the same time. In the past, this was accomplished by jug-
gling lockfiles. The new scheme takes care of the problem in the
kernel. Instead of one modem device, there are now two: a callin
device, named /dev/ttyS# (where # is the port number), and a call-
out device, named /dev/cua# (again, # = port number). The callin
devices are used by programs like getty; the callout devices are
used by programs like Seyon and Kermit. If you don't have the
callout devices in /dev, you create them with the mknod command.
They are character devices, major number 5, minor number same as
the corresponding callin device.
So how does it work? Simple...
Suppose that kermit wants to open /dev/cua1 for a callout session.
The kernel allows the line to be open if and only if no other
program currently has the corresponding /dev/ttyS1 line open; if
it does, the error EBUSY is returned in errno.
The /dev/ttyS1 line is a bit more complicated. By default, the device
'blocks' on open. This means that the program will be stopped until
the device is clear to open. For the device to be clear, two things
must be true: no process can be using the corresponding /dev/cua1
line, and the carrier detect line of the serial port must be high.
While the device is blocking, it is not busy, so callout devices can
use the line. In other words, if getty is running on /dev/ttyS1, as
long as no incoming calls open the line (causing the carrier to go
high), other programs are free to use the line. Blocking can be dis-
abled by setting the O_NDELAY flag to the open system call. In this
case, carrier detect is not needed to open the line; however, if
/dev/ttyS1 is busy, EBUSY is still returned in errno and the open fails.
So... why didn't getty_ps work with this? Getty_ps opened the line with
the O_NDELAY flag set to do modem initialization and wait for RING to
come over the line. By doing this, the device is always busy, and any
other program trying to use the line is not allowed. This behaviour
is the major change in the getty_ps package.
--
Ed Casas (edc@ee.ubc.ca)
------------------------------
From: intell@metronet.com (Intellection)
Subject: Taylor UUCP 1.04 fails EAGAIN on 0.99.12
Date: Fri, 26 Nov 1993 21:24:24 GMT
I can't establish an outdial connection to any of my Dialers with
either cu or uucico. For example, cu SYSTEM will print the
"Connected" message, then the first 10 or so characters of the remote
login prompt. (I assume that those characters are printed by the
flush code before the child process gets control.) The child process
does its read() from the modem and returns -1 with errno=EAGAIN, and
at the same time, DTR drops.
The symptoms are the same no matter what system I dial. But if I
bypass the chat script with cu -l /dev/cua1 and dial manually instead,
there's no problem. I get the entire login prompt, and log in without
losing DTR. Of course that's no use, since I'm really trying to get
uucico working, not interactive logins.
The difficulty with uucico is similar. The Dialers chat script work
fine, but the Systems chat script dies right off with EAGAIN.
Any insight would be appreciated, because I've been deep into the UUCP
code and the terminal driver without any results.
Regards, Ed
------------------------------
From: ct_orega@ECE.Concordia.CA (Chris O'Regan)
Subject: Re: Can't run VI
Date: Fri, 26 Nov 1993 23:06:32 GMT
In article <CGMFI0.F8K@ucdavis.edu> ez025807@othello.ucdavis.edu ( ) writes:
> Trouble writing to tmp file
Under root, change the protection of /tmp to 777.
This happened to me as well, for some odd reason. I can't tell
you why. Maybe an intermittant bug which enjoys playing with the
protections on /tmp? :-)
Chris
------------------------------
From: jdk001u@paradyne.com (Jim Kunzman)
Crossposted-To: comp.os.linux.help
Subject: Re: Once again, using tape drives under Linux
Date: 26 Nov 1993 16:58:35 GMT
According to awk@char.vnet.net (Alexander Kourakos):
> My initial posting about tape drives received a few meager scraps
>of replies.
> I'm going to have to buy SOMETHING by the end of this week.
>
> Has anyone here actually saved data to a tape and restored it? What
>brand? What drivers?
>
> PLEASE let me know so I don't make a $200 (or more) mistake.
>
>awk
>awk@vt.edu
Most any SCSI drive will work with LINUX distributions. I have an
Archive 4mm DAT, but any of the 6150 drives also work well. I'm not
fond of the DC2000 series tapes because of the DMA problems with the
floppy drive controller, Nevertheless many LINUXers use them anyway
with moderate success (Anyone want to buy a Mountain Mach II
controller and streamer?).
But hey, as cheap as large SCSI drives are getting, you could almost buy
a spare external SCSI drive and just mount it periodically when you need
to backup. ;-) Of course this wouldn't apply if you were doing serious
LINUX development work or needed to archive mounds of data.
Good luck with your decision.
--
Jim Kunzman at AT&T Paradyne <jdk001u@paradyne.com>
=====
Ich bin ein LINUXer.
------------------------------
From: las@whome.uucp (Laszlo Herczeg)
Subject: Re: How to send commands to /dev/modem or /dev/cua1 ?
Date: Sat, 27 Nov 1993 01:00:31 GMT
dschleef@bohr.physics.purdue.edu (David A. Schleef) wrote:
>
> sleep 1; echo '+++\c' > /dev/modem; sleep 1; echo ATH0 > /dev/modem
>
>
>
> dave...
Actually:
echo 'atdt 9999999\r' >/dev/modem
^^
because the Hayes modem responds to ^M as the command
separator
Laszlo
*This works using ksh 's built-in echo command; I don't know about
other shells.
------------------------------
Crossposted-To: comp.os.linux.help
From: las@whome.uucp (Laszlo Herczeg)
Subject: Re: [Q] How to make a socket?
Date: Sat, 27 Nov 1993 01:00:34 GMT
dan@oea.hobby.nl wrote:
> dan@oea.hobby.nl wrote:
>
> : I accidentally erased /tmp/.X11-unix/X0 and I'm having trouble
> : recreating it. How do I go about making this socket? I'll most
> : likely reinstall XFree to get the socket back, but I'm curious!
>
> Thanks to all who sent me email. The unanimous answer was that there
> is no need to recreate the socket as the X server will automagically
> do that.
>
> Cheers,
>
> --
> |< Dan Naas dan@oea.hobby.nl >|
> +---------------------------------+
Still, does anyone know how to create a Unix domain socket like
the screen program does?
------------------------------
From: norman@flaubert.bellcore.com (Norman Ramsey)
Subject: [Q] LILO doesn't work from my IDE MBR
Date: Sat, 27 Nov 1993 01:47:07 GMT
I have one DOS partition on my IDE hard drive (/dev/hda1), and I have
a SCSI drive with several partitions, Linux root on /dev/sda1. From
reading the LILO docs it seemed my only chance was to put lilo in the
MBR of the IDE drive. Unfortunately, lilo only gets to the `L' stage
and then the machine hangs. I'm running the Yggdrasil LGX F93, but I
have also tried the lilo on the TransAmeritech CD. No luck with
either. I restored the original MBR with dd, but I'm left booting
linux from floppy (ugh). Does anybody have any suggestions about how
to proceed?
Norman Ramsey
--
Norman Ramsey
norman@bellcore.com
------------------------------
From: norman@flaubert.bellcore.com (Norman Ramsey)
Subject: [Q] help wanted with "/dev/cua1: Device or resource busy"
Date: Sat, 27 Nov 1993 02:07:03 GMT
I'm running the Yggdrasil LGX F93 kernel, and any attempt to use
/dev/cua1 (including to run setserial) results in "Device or resource
busy". (Ditto /dev/ttyS1, unsurprisingly.) I have a mouse on com1
(/dev/cua0), and I can use kermit to connect to the mouse and see
gibberish at 1200baud when I move it. I have an external modem on
com2.
I checked the serial-FAQ, but didn't get far:
-- there are no getty processes on the serial line, just on tty[1-4]
(my four virtual consoles). I checked both inittab and `ps aux`
-- the FAQ suggests remaking the kernel, but I tried that and the
kernel sources as distributed won't build.
I have an SMC Ethernet card plugged into the system that I have never
used. Could it be causing the problem? If so, is there a cure other
than ripping it out?
Can anyone suggest any other cures? My linux box is pretty useless if
I can't talk to the world...
Norman Ramsey
--
Norman Ramsey
norman@bellcore.com
------------------------------
From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Can't run VI
Date: Sat, 27 Nov 1993 03:18:55 GMT
In article <CH4G6x.B70@newsflash.concordia.ca>,
Chris O'Regan <ct_orega@ECE.Concordia.CA> wrote:
>In article <CGMFI0.F8K@ucdavis.edu> ez025807@othello.ucdavis.edu ( ) writes:
>> Trouble writing to tmp file
>
> Under root, change the protection of /tmp to 777.
No. While this lets users create files in /tmp as required, it also
allows users to delete eachother's files. Instead, /tmp should have the
sticky bit set so that users can't delete files they don't own unless they
own the directory (which they don't).
Change the protection of /tmp to 1777.
------------------------------
From: pmcintir@etsun.tech.iupui.edu (Paul McIntire)
Subject: sz problems
Date: Sat, 27 Nov 1993 03:10:36 GMT
Greetings:
I'm trying to get sz to work with my Slackware release, but
everytime I try to send to my home pc, zmodem fires up, then
automatically aborts. Is this a linux problem? Or an sz problem?
Thanks.
--
************************************************************************
* Paul T. McIntire *
* Indiana University Purdue University at Indianapolis *
* Office of Integrated Technologies *
------------------------------
From: kender@esu.edu (Daniel Garcia)
Crossposted-To: comp.os.linux.help
Subject: Re: [Q] How to make a socket?
Date: 26 Nov 1993 22:55:27 -0500
Reply-To: kender@esu.edu
Slaving away in a dark room, las@whome.uucp (Laszlo Herczeg) produced:
>
>Still, does anyone know how to create a Unix domain socket like
>the screen program does?
This is more a general unix programming question, and as such, has been
redirected into comp.unix.programmer. If you want to look into
socket program, I would suggest the book Unix Network Programming,
by W. Richard Stevens, it's an excellent book, and while I was familiar
with network programming before I got it, I've found it to be an
invaluable reference tool.
D
--
|Dan Garcia,Kender@esu.edu|Don't tear away from me, I need you to hold on to, |
|#include <stdisclaimer.h>|Don't tear away from me, I need someone to hold on |
|Coram Deo|Death to Barney|to - 'Terrible Lie' - NIN |
| GCS/MU d--() -p+ c++(c+) l++ u+ e+(*) m++(*) s !n h f+ !g w+ t++(--) r+ !y |
------------------------------
From: terryd@extro.ucc.su.OZ.AU (Terry Dawson)
Subject: Re: SLIP FAQ
Date: Sat, 27 Nov 1993 04:01:12 GMT
iiitac@swan.pyr (Alan Cox) writes:
>And if you see the NET-2-HOWTO don't believe it: Its obsolete and wrong.
>A couple of things it tells you to do will break an SLS system (not a bad
>thing in itself 8-))
Version 1.8 of he NET-2-HOWTO, which hopefully has been posted already,
contains the updates that Alan sent. You obviously didn't receive my
mail explainging this Alan ?
Terry
--
--- Terry Dawson, terryd@extro.ucc.su.oz.au
------------------------------
From: root@hip-hop.sbay.org (Remco Treffkorn)
Subject: Re: NFS proplems
Date: Thu, 25 Nov 1993 20:18:58 GMT
Reply-To: remco@hip-hop.sbay.org
alex@psyalex.psy.gu.se wrote:
: Hi !
...
: I'm currently running 0.99pl13r and the problem occurs
: when I try to NFS mount a disk from our HP-server.
: The message I get is :
: mount clntudp_create: RPC: Program not registered
: mount clntudp_create: RPC: Program not registered
: mount clntudp_create: RPC: Program not registered
...
: So should I blame Linux or HP ? Of course I suspect HP ;-)
: Please answer somebody.
: --
Well, I think you have only yourself to blame. The same happens to me
when trying to mount my SUN from linux. I am sure that it is a config
issue with the SUN. (SUNOS 5.2)
I have virtually no printed doc for the SUN but megabytes on disk. I am
sure the answer is there somewhere but I could not find it.
Happy Thanksgiving...
Remco
--
Remco Treffkorn, DC2XT
remco@hip-hop.sbay.org <<-- REAL reply address !!
(408) 685-1201
------------------------------
Crossposted-To: comp.os.linux.help
From: hjl@nynexst.com (H.J. Lu)
Subject: Re: Shadow passwords?
Date: Sat, 27 Nov 93 04:35:27 GMT
rob@pe1chl.ampr.org (Rob Janssen) writes:
: In <2cue0n$eu2@organpipe.uug.arizona.edu> ron@argus.lpl.Arizona.EDU (Ron Watkins) writes:
:
: >What are shadow passwords. I haven't run across them before. How do I know
: >what in my Linux distribution is using them? Is it possible to avoid using
: >them? I would rather have an old-fashon UNIX setup, small and simple. I
: >don't want excess stuff in my directories. Please mail any info to
: >ron@argus.lpl.arizona.edu.
:
: Shadow passwords move the password information from the publicly readable
: /etc/passwd to a more restricted /etc/shadow file. This file also has
: some extra fields to carry info like password expiration date.
:
: It is possible to disable it by recompiling some programs with different
: options, but you will certainly have more trouble with that (and the effects
: on future installation of upgrades, networking etc) than you now save by
: keeping things like you are accustomed to!
:
All the baniries linked with the shared library may automatically
have the support for the shadow password when libc 4.5.x is released
to public. I don't use the shadow password myself. libc 4.5.3 works
fine with me. I don't know about how it works with the shadow
password. I am still waiting for reports from the libc testers.
H.J.
------------------------------
From: el@lisse.NA (Dr Eberhard W Lisse)
Subject: Re: Taylor UUCP 1.04 fails EAGAIN on 0.99.12
Date: Sat, 27 Nov 1993 09:25:53 GMT
intell@metronet.com (Intellection) writes:
>I can't establish an outdial connection to any of my Dialers with
>either cu or uucico. For example, cu SYSTEM will print the
>"Connected" message, then the first 10 or so characters of the remote
>login prompt. (I assume that those characters are printed by the
>flush code before the child process gets control.) The child process
>does its read() from the modem and returns -1 with errno=EAGAIN, and
>at the same time, DTR drops.
>The symptoms are the same no matter what system I dial. But if I
>bypass the chat script with cu -l /dev/cua1 and dial manually instead,
>there's no problem. I get the entire login prompt, and log in without
>losing DTR. Of course that's no use, since I'm really trying to get
>uucico working, not interactive logins.
>The difficulty with uucico is similar. The Dialers chat script work
>fine, but the Systems chat script dies right off with EAGAIN.
>Any insight would be appreciated, because I've been deep into the UUCP
>code and the terminal driver without any results.
Well, I think read the FAQ! There is a litle patch that Ian Taylor
sent to me which fixed that problem.
I'll mail it to you seperately.
el
--
Dr. Eberhard W. Lisse \ / Windhoek Central Hospital
<el@lisse.NA> \ * | Department of Obstetrics and Gynaecology
Private Bag 13215 \ / 61 203 2106/7 (Bleeper) 61 224014 (home)
Windhoek, Namibia ;____/
------------------------------
** 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: Linux-Admin-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.admin) via:
Internet: Linux-Admin@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Admin Digest
******************************