From: Digestifier 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 , wrote: > >In article 93Nov7222819@dynamo.dyndata.com, > dan@dynamo.dyndata.com (Dan Everhart) writes: >> >> What exactly is the difference between /dev/ttyS and /dev/cua? >> 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 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 ===== 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 , Chris O'Regan wrote: >In article 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 |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 \ * | 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 ******************************