stew@hanauma.UUCP (03/14/87)
---- OS: Sun 4.2 Unix Release 3.2 We've tried recently to bring up our imagen spooling software on our new Sun workstations. Our problem is that the line printer demon /etc/lpd gets fired up, chews up a lot of CPU, and never successfully execs any of the imagen filters. When compiled without the initial sequence that divorces itself from the invoking user and /dev/tty (i.e. compiled with -DDEBUG) and run manually, everything works fine. I've done a gcore of the lpd demon when it gets stuck and find that it is somewhere inside the print() subroutine apparently in an infinite loop within close(). Any ideas? Also, while I'm at it, does anyone know why telnet from 4.2BSD on a Vax to the Sun misbehaves? I find I have to always type ^J rather than a return to terminate a line. I've played with setting and unsetting CRMOD without success. Thanks -- ...!decvax!hanauma!stew or na.levin@su-score.arpa
ndd@duke.UUCP (Ned Danieley) (03/16/87)
In article <110@hanauma.UUCP> stew@hanauma.UUCP (Stewart Levin) writes: >---- >OS: Sun 4.2 Unix Release 3.2 > >We've tried recently to bring up our imagen spooling software on our >new Sun workstations. Our problem is that the line printer demon /etc/lpd >gets fired up, chews up a lot of CPU, and never successfully execs any of >the imagen filters. I've seen a similar problem here: if there are any jobs in any of the printer queues when lpd is restarted, they never get printed. lpd keeps forking new versions of itself which die when the filter exits. I haven't had a chance to call imagen about it: has anyone else seen this problem? this is version 2.2 rev A0 of the host software. Ned Danieley ndd@duke
mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) (03/16/87)
In article <110@hanauma.UUCP> stew@hanauma.UUCP (Stewart Levin) writes: >---- >OS: Sun 4.2 Unix Release 3.2 > >We've tried recently to bring up our imagen spooling software on our >new Sun workstations. Our problem is that the line printer demon /etc/lpd >gets fired up, chews up a lot of CPU, and never successfully execs any of >the imagen filters. When compiled without the initial sequence that We had the same problem. The fix supplied by Sun tech. support (it worked for us) is that because the imagen filters are invoked by lpd, which is a suid root program, you have to add a "-b" flag to the filter; i.e., at the top of the imfilter shell script, change "#!/bin/csh -f" to "#!/bin/csh -fb". BTW, we are running Sun OS 3.2, Imagen release 2.2 and ethernetted Imagen 24/300s. Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa voice: 415/424-0500 USnail: Teknowledge, Inc., 1850 Embarcadero Rd., POB 10119, Palo Alto, CA 94303
guy%gorodish@Sun.COM (Guy Harris) (03/17/87)
>...because the imagen filters are invoked by lpd, which is a suid root >program, you have to add a "-b" flag to the filter; i.e., at the top of >the imfilter shell script, change "#!/bin/csh -f" to "#!/bin/csh -fb". Note that the requirement for a "-b" flag comes from the 4.3BSD "csh", so other systems with that version of "csh" will experience the same symptoms.
ted@braggvax.arpa (03/18/87)
>From: Stewart Levin <stew@hanauma.uucp> > >.......................Our problem is that the line printer demon /etc/lpd >gets fired up, chews up a lot of CPU, and never successfully execs any of >the imagen filters........ > > Thanks -- ...!decvax!hanauma!stew or na.levin@su-score.arpa What I found was that sun 3.2 does you a real "favor" with its new csh. If you look at the imagen filters, you find that they are really one csh script with 33 hardlinks (different names to it). /usr/lib/lpd is an suid program and the new csh will not let you exec a csh script from an suid program without your giving the -b flag when you crank it up. We found this out the hard way (although it is documented on the csh man page). This "favor" will probably break other things too. Here is the fix. Change the top line of the shell script from #!/bin/csh -f to #!/bin/csh -bf Worked for us, Ted Nolan ted@braggvax.arpa
guy%gorodish@Sun.COM (Guy Harris) (03/19/87)
>What I found was that sun 3.2 does you a real "favor" with its new csh.
And so, I'm sure, do other systems that use the 4.3BSD C shell. It's
not 3.2's new C shell, it's 4.3BSD's new C shell; send brickbats and
bouquets to Berkeley, not to Sun.rbj@icst-cmr.arpa (03/24/87)
From: Guy Harris <guy%gorodish@Sun.COM>
>What I found was that sun 3.2 does you a real "favor" with its new csh.
And so, I'm sure, do other systems that use the 4.3BSD C shell. It's
not 3.2's new C shell, it's 4.3BSD's new C shell; send brickbats and
bouquets to Berkeley, not to Sun.
No dice. Berkeley expressly provides software on an `as is' basis. SUN
is a *real company*, supposedly with some degree of professionalism
and presumption of support. If SUN passed on a Berkeley bug it becomes
SUN's bug, because they were the last to muck with it.
I am not saying that csh should not have this feature or that the
problem was major, or that SUN (or Guy) in general is unprofessional.
I am just calling him on this one.
(Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa>
Was my SOY LOAF left out in th'RAIN? It tastes REAL GOOD!!mlandau@Diamond.UUCP (03/24/87)
In comp.unix.wizards (<5483@brl-adm.ARPA>), rbj@icst-cmr.arpa (Root Boy Jim) writes: > > From: Guy Harris <guy%gorodish@Sun.COM> > >What I found was that sun 3.2 does you a real "favor" with its new csh. > > And so, I'm sure, do other systems that use the 4.3BSD C shell. > ...send brickbats and bouquets to Berkeley, not to Sun. > > If SUN passed on a Berkeley bug it becomes >SUN's bug, because they were the last to muck with it. Except that it's NOT A BUG. It's a FEATURE. It's SUPPOSED to work that way. Since Sun 3.2 csh claims to be compatible with 4.3 csh, it would have been a bug NOT to change the behavior. SunOS certainly has its share of bugs, but let's be fair about finger pointing. -- Matt Landau BBN Laboratories, Inc. mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238 ...seismo!diamond.bbn.com!mlandau (617) 497-2429
guy@gorodish.UUCP (03/25/87)
>No dice. Berkeley expressly provides software on an `as is' basis. SUN >is a *real company*, supposedly with some degree of professionalism >and presumption of support. If SUN passed on a Berkeley bug it becomes >SUN's bug, because they were the last to muck with it. > >I am not saying that csh should not have this feature... Make up your mind - is it a bug or a feature? If the latter (which I contend it is - it may be a good feature, or a bad feature, but since it was *intended* to behave that way, it's a feature), then Sun didn't "pass on a Berkeley bug", since it's not a bug.
rbj@icst-cmr.arpa (03/28/87)
From: Guy Harris <guy%gorodish@Sun.COM> responds to me: >No dice. Berkeley expressly provides software on an `as is' basis. SUN >is a *real company*, supposedly with some degree of professionalism >and presumption of support. If SUN passed on a Berkeley bug it becomes >SUN's bug, because they were the last to muck with it. > >I am not saying that csh should not have this feature... Make up your mind - is it a bug or a feature? If the latter (which I contend it is - it may be a good feature, or a bad feature, but since it was *intended* to behave that way, it's a feature), then Sun didn't "pass on a Berkeley bug", since it's not a bug. Oops, perhaps I didn't make myself clear. The original poster asked about a lpd script. The response said that `SUN did you a favor by changing the csh'. To which Guy responded correctly by saying that the -b option was put in by Berkeley. Up to this point we agree. This change broke lots of scripts, including the lpd one SUN `inherited'. Where we differ is that I feel that even tho SUN inherited the bug, it is still their responsibility to fix it. I would even hazard a guess that given some time to reflect on this, Guy would also agree. Note that I am *not* saying that the bug is in csh. I am saying that the change in the csh forces a change in some csh scripts. Berkeley *should* have changed the appropriate scripts. They did not. Nobody seems much surprised by this. I am saying that SUN is still on the hook for changing them and making them right. After all, they put their name on it. At least it's a shell script. (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> I feel better about world problems now!
guy@gorodish.UUCP (03/28/87)
> This change broke lots of scripts, including the lpd one SUN `inherited'. The "lpd" script Sun "inherited"? Where did we inherit it from? (Not from 4.3BSD; there ain't no scripts under "/usr/src/usr.lib/lpr" - they do offer some filters, but they're all C programs.) And, if we inherited it, where did we put it? (It ain't in our source hierarchy either.) Go back and read the original article, please. The guy clearly states that the scripts were part of a non-Sun package for driving an Imagen printer: We've tried recently to bring up our imagen spooling software on our new Sun workstations. > Where we differ is that I feel that even tho SUN inherited the bug, it > is still their responsibility to fix it. I would even hazard a guess > that given some time to reflect on this, Guy would also agree. I would agree, without having to reflect on it that if we inherit a bug it is our responsibility to fix it. However, I can also say, without having to reflect on it, that we didn't inherit any bug here.