Date: Fri, 19 May 1995 13:18:10 +0200 (MET DST) From: sven@stack.urc.tue.nl (Sven Berkvens) To: questions@FreeBSD.org Subject: Lots of questions Message-ID: <199505191118.NAA17498@zen.stack.urc.tue.nl>
next in thread | raw e-mail | index | archive | help
Hi everyone! I am one of the system administrators of the university's computer association. We are current running FreeBSD 2.0 RELEASE on three computers. One is acting as an NFS server and contains a lot of harddisks. The other two get most of their stuff from that NFS server. The server contains two WD8003EP ethernet cards. One is for the NFS network (which is local to the three computers) and one is for normal network access. The other two computers have a similar setup, except that they contain two NE2000's. I mention the above because it may have something to do with my qeustion: when I type 'arp -a' to view the ARP cache, all it says (on all three machines) is: ? (0.0.0.0) at (incomplete) ? (0.0.0.0) at (incomplete) ? (0.0.0.0) at (incomplete) ? (0.0.0.0) at (incomplete) permanent ? (0.0.0.0) at (incomplete) ? (0.0.0.0) at (incomplete) One machines has more 0.0.0.0 than another, but all outputs are similar. Does this mean that the machines will try an ARP resolve for every packet they send or is my 'arp' just broken? I don't know exactly how much network load ARP resolves cost, but I can imagine that it is not desirable. Also, I cannot query a host for its ARP address: Turtle: /home/sven> arp zen zen (131.155.140.130) -- no entry Turtle: /home/sven> arp nfszen nfszen (131.155.14.130) -- no entry And that, while it's constantly receiving and sending NFS data to nfszen. Anyone know what's going on here? ------------------------------------------------------------------------------- Now I have a question about the pty/tty's the FreeBSD employs. It seems that when somebody logs in, the pty/tty pair in the /dev directory is chown(2)'ed to that person. That's quite normal :) Now, when he/she logs out, the pty/tty is AUTOMATICALLY chown(2)'ed back to root and given the mode rw-rw-rw-. This is not a real problem, but the problem is this: Say somebody is running ELM. For some reason, he thinks the computer hanging (for example, it takes too long) and he presses ALT-X (using PC NCSA Telnet) which closes the connection. The pty/tty pair gets chowned back to root and they are no longer associated with the ELM process. When ELM does a read(2) to check for terminal input, read(2) returns 0 (I guess as an EOF condition). ELM interprets this wrong (so does TIN for example) and does not see this as an error; even worse, these programs interpret it as a keystroke. Now comes the problem. These program think 'Hey, this is NOT a key I know, lets tell the user and wait for another key'. The write(2)s fail but ELM and TIN don't notice. However, they get stuck in a loop and start eating processor time, because they keep on getting "wrong keys". My questions about this: Is read(2) not supposed to return -1 to indicate an error (like write(2) does)? Why does the tty/pty immediate get chown(2)'ed back to root (and more important: who does this??) instead of leaving it behind as it was and then chown(2)-ing it to another user when necessary (like on SVR4)? ------------------------------------------------------------------------------ Another question: is there a stat-daemon available for FreeBSD? ------------------------------------------------------------------------------ Will the new version of FreeBSD be able to handle bad sectors on disks and harddisks? And what about bad sectors in the swap partition? And why isn't it (yet) possible to swap out of a file? ------------------------------------------------------------------------------ We run XFree86 version 3.1.1 and that works perfectly, except that when you quit the X server, it sometimes nukes the consoles. They either totally disappear (the X server reports VT_ACTIVATE failed), or they just don't display anything (they do work, but you can't see anything except a kind of cursor (ours normally flashes, but this one doesn't) which does not move). Commands that are typed are responded to however. I can't seem to get vidcontrol(1) to do anything about it either. Restarting the X server works (the X screen is displayed properly) but quitting it renders the same result. By the way, this only happens sometimes, not always. In all cases, the getty(1) processes do keep on running. Respawning them manually does not solve the problem. The video card used is an ET 4000 with 1 MB of memory, running in 1024x768x256 and in 1024x768x2 modes. Both modes sometimes render the console useless after quitting the X server, which is done normally by the way: not with CTRL-ALT-BackSpace. Does anybody have the same problem? And does anybody know what I can do to get back my console? ------------------------------------------------------------------------------- Thank you for your time which you took to read this! With kind regards, Sven Berkvens (System Administrator)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505191118.NAA17498>