jeffp@phred.UUCP (Jeff Parke) (06/27/86)
We recently "upgraded" a vax750 to ULTRIX 1.2. Suddenly the following don't
work anymore:
finger (core dumps occasionally)
sps
top
uw (windows program)
sccs (admin command bombs)
Has anyone else seen this? Has anyone figured out how to fix? Or is there
something wrong with our installation of ULTRIX?
{ seismo!hpscda!hplsla ..OR.. ihnp4!sun!fluke } !tikal!phred!jeffp {Jeff Parke}chuq@sun.uucp (Chuq Von Rospach) (06/30/86)
> We recently "upgraded" a vax750 to ULTRIX 1.2. Suddenly the following don't > work anymore: > > finger (core dumps occasionally) > sps > top > uw (windows program) > sccs (admin command bombs) > > Has anyone else seen this? Has anyone figured out how to fix? Or is there > something wrong with our installation of ULTRIX? Did you recompile the programs? Most or all of those programs use nlist() to snarf into the kernel through /dev/kmem. chances are the internal data structures of the kernel changed and they will start working again when you recompile with the new .h files. Anything that plays with kmem (nasty habit, that....) is susceptible to this. I'd guess you got caught. chuq -- :From the lofty realms of Castle Plaid: Chuq Von Rospach chuq%plaid@sun.COM FidoNet: 125/84 CompuServe: 73317,635 {decwrl,decvax,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!plaid!chuq Dessert is probably the most important stage of the meal, since it will be the last thing your guests remember before they pass out all over the table. -- The Anarchist Cookbook
avolio@decuac.DEC.COM (Frederick M. Avolio) (07/01/86)
In article <455@phred.UUCP>, jeffp@phred.UUCP (Jeff Parke) writes: > We recently "upgraded" ... to ULTRIX 1.2. ... the following don't work ... > finger (core dumps occasionally) Yeah. I don't remember the reason, but I recall occasional core dumps on long lists of names. (It'll come to me in the dead of night probably...) And I can remember making the fix. Just don't remember what... In any event, I can send you a uuencoded version of one that doesn't dump core. (Unless you ordered the one that dumped core :-).) Let me know. (By the way, this code is changed in an attempt -- successful, I think, to un-UCB it. I mean, I odn't work in Evans *or* Cory Halls! :-)) > sps > top > uw (windows program) Structures in the kernel have changed (you would find the same "problems" upgrading to 4.3BSD, I suspect). Recompile. > sccs (admin command bombs) If by bomb you mean it cannot create an initial SCCS file, yes I have seen it ("cannot create lockfile" or some such error). I believe sccs is trying to be smart and secure about how it creates things. It runs as user 'sccs.' Change the mode on /usr/ucb/sccs to 755 and it should work. -- Fred @ DEC Ultrix Applications Center INET: avolio@decuac.DEC.COM * Fight the Fight * UUCP: {decvax,seismo,cbosgd}!decuac!avolio * Rescue the Unborn *
maxson@cfa.UUCP (Charles Maxson) (07/03/86)
> Xref: talcott net.sources.d:297 net.unix:5769 net.unix-wizards:8556 > >> We recently "upgraded" a vax750 to ULTRIX 1.2. Suddenly the following don't >> work anymore: >> >> finger (core dumps occasionally) >> sps >> top >> uw (windows program) >> sccs (admin command bombs) >> >> Has anyone else seen this? Has anyone figured out how to fix? Or is there >> something wrong with our installation of ULTRIX? Some of the include file declarations have been altered (presumably to be in accord with 4.3 BSD features). In particular, tty.h now references the winsize structure, which is declared in ioctl.h. Thus, where you have included tty.h, you should also insert the line: # include <h/ioctl.h> prior to the tty.h line. Recompiling the programs should then work. For sps, findtty.c, inittty.c, flagsetup.c, ttystatus.c, and waitingfor.c must be changed. Grep the source files for tty.h to see which need to be changed. -- -- Charles W. Maxson (617)495-7178 -- Harvard-Smithsonian Center for Astrophysics, 60 Garden St., Cambridge, MA 02138 -- UUCP: {seismo,ihnp4,cmcl2}!harvard!talcott!cfa!maxson wjh12!cfa!maxson -- ARPA: maxson%cfa.UUCP@harvard.HARVARD.EDU
pdg@ihdev.UUCP (P. D. Guthrie) (07/07/86)
In article <975@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: >In article <455@phred.UUCP>, jeffp@phred.UUCP (Jeff Parke) writes: >> We recently "upgraded" ... to ULTRIX 1.2. ... the following don't work ... >> uw (windows program) > >Structures in the kernel have changed (you would find the same >"problems" upgrading to 4.3BSD, I suspect). Recompile. > This may not work either. I put a windows system onto Ultrix 1.2 last week and recompiled (no problems), but the sucker still won't work. I didn't have time to track down the problem in full, but the first time you open a pty, the open works, but when you open it again (to get a different file descriptor), it fails. I kludged around this with a dup, but then started getting io errors from the pty driver on writes. The problem may be easy to fix (and if anyone else knows what is going on I would be interested in hearing from you) but I really haven't had the time to look at it in detail. The thing that gets me here (although I could be jumping to conclusions) is that there are *undocumented* incompatabilities. We'll just have to chalk Ultrix up as Just Another Different Unix. I must admit, though, that a large proportion of software did work right off. -- Paul Guthrie `See the happy moron, he doesn't give a damn. ihnp4!ihdev!pdg I wish I were a moron. My God! Perhaps I am.'
jdb@mordor.ARPA (John Bruner) (07/11/86)
>>> We recently "upgraded" ... to ULTRIX 1.2. ... the following don't work ... >>> uw (windows program) >> >>Structures in the kernel have changed (you would find the same >>"problems" upgrading to 4.3BSD, I suspect). Recompile. > >This may not work either..... I can't speak for other window programs, but as the author of UW perhaps I can shed a little light on its problems. When I distributed UW v2.10 in November, my VAX was running 4.3BSD. I recoded the server to use the data types and macros defined in 4.3BSD's <sys/types.h>. Since the FD_SET, FD_ISSET, etc. macros were not defined in 4.2BSD, I added some conditional code to define them. In so doing, I made a stupid incorrect assumption. Since VAX 4.2BSD was limited to 30 file descriptors (because of the layout of bits in page table words), I assumed that no 4.2BSD or 4.2BSD-derived implementation supported more than 30 file descriptors. This is wrong. I tried out the UW server on the only machines available to me (4.2 and 4.3 VAX, Sun, Integrated Solutions) and it worked. I do not know how many file descriptors ULTRIX 1.2 allows, but this is a possible source of problems. One cheap-hack workaround is to replace the call to "getdtablesize()" with the constant 30. A better fix is to recode the definitions of FD_SET, etc. I know that some implementations of 4.2BSD have had trouble with UW's UNIX-domain datagrams (used to pass file descriptors from one process to another). If UNIX-domain sockets aren't implemented (or are buggy), then "uwtool" won't work, but the UW server is still useable. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb
pdg@LaBrea.UUCP (07/16/86)
In article <975@decuac.DEC.COM> avolio@decuac.DEC.COM (Frederick M. Avolio) writes: >In article <455@phred.UUCP>, jeffp@phred.UUCP (Jeff Parke) writes: >> We recently "upgraded" ... to ULTRIX 1.2. ... the following don't work ... >> uw (windows program) > >Structures in the kernel have changed (you would find the same >"problems" upgrading to 4.3BSD, I suspect). Recompile. > This may not work either. I put a windows system onto Ultrix 1.2 last week and recompiled (no problems), but the sucker still won't work. I didn't have time to track down the problem in full, but the first time you open a pty, the open works, but when you open it again (to get a different file descriptor), it fails. I kludged around this with a dup, but then started getting io errors from the pty driver on writes. The problem may be easy to fix (and if anyone else knows what is going on I would be interested in hearing from you) but I really haven't had the time to look at it in detail. The thing that gets me here (although I could be jumping to conclusions) is that there are *undocumented* incompatabilities. We'll just have to chalk Ultrix up as Just Another Different Unix. I must admit, though, that a large proportion of software did work right off. -- Paul Guthrie `See the happy moron, he doesn't give a damn. ihnp4!ihdev!pdg I wish I were a moron. My God! Perhaps I am.'