silbar@mpx2.lampf.lanl.gov (SILBAR, RICHARD R.) (11/27/90)
The following is the text of a letter I sent today to ask_next@
next.com. I've raised some of these questions here in this news-
group before, without getting much response. I would AT LEAST
like to get some indication of who all is having similar problems;
it is amazing to me that this could only be happening to me and
maybe one or two others.
-------------------------------------------------------------------
Starting about a month ago I suddenly could no longer "lpr" a file. (There
was/is no trouble printing from an Application menu.) The command "lpq" said
that I have "no daemon present". However, unlike what seemed to work when I
had some trouble like this last February, executing /usr/lib/lpd does NOT clear
things up. In fact, "ps -aux" shows there is no such process named "lpd",
either before or after executing "lpd".
Joe Kleczka, a NeXT jocky here at LANL, suggested it was the daemon
"npd" that was missing. However, "ps" showed it there. Becoming
root, removing it, and restarting "npd" did not solve the missing
daemon problem. (The npd being used is the new one that avoids a
security hole, as cited by the CERT memo.)
Nor did removing lpd.lock (in /usr/spool = /private/spool) and
rebooting. Nor, for that matter, removing the lock files in /usr/
spool/lp and /usr/spool/np.
By now I was getting pretty frustrated. I next looked at what /etc/
rc does regarding lpd and I concluded that I couldn't conclude
anything:
if [ -f /usr/lib/lpd ]; then
rm -f /dev/printer
/usr/lib/lpd && (echo -n ' printer') >/dev/console
fi
When I did a little test, the predicate seemed to be true, and that
jibes with the fact there IS no /dev/printer file afterward. But the
echo does NOT appear on the console. Does this mean /etc/rc is NOT
being executed on bootup? Or simply that the "/usr/lib/lpd" before
the "&&" simply failed?
I also played numerous games with nidump, niload, niutil, and
NetInfoManager, all to no success. My printcap file (as seen by
"nidump printcap .", not that in /etc/printcap) had TWO entries named
"np" and "NextLaser". Could this be a cause of my problem? But why
only beginning last month? (Cleaning up the printcap file in
NetInfoManager may or may not have helped in the first resolution of
the problem, but in any case there is no such duplication in my
present version.)
Incidently, I seemed unable to remove anything from the printcap
using the -d option in niload. Nor did, to my memory, "niutil -
destroy . printers" seem to remove anything.
After about a week, Joe Kleczka generously donated one-and-a-half
hours of his time on November 2 to help break the logjam. It wasn't
(and still isn't) obvious what was wrong. We did a LOT of thrashing
around that afternoon. In the end what MAY have cured the problem
was to delete my /usr/spool directory from the hard disk and re-load
it from the v.1.0 distribution disk.
Well, for about two weeks, lpr worked fine. The reason I put "may"
in caps is because, unfortunately, the problem of missing lp daemon
returned about ten days ago, around the 15th. It still seems like an
access problem or a lock, but I am now stymied (again).
At first I figured I'd just repeat the thing that worked (I thought)
that long Friday afternoon two weeks before: delete and reload the /
usr/spool directory. It didn't work this time.
By now I had discovered Appendix B in the System Reference Manual,
which appears to be very much to the point. However, even after
changing owner and group to daemon and rebooting, the new /usr/spool
directory did not allow the daemon to be restarted. It also appeared
that the Troubleshooting section of ApB WOULD hold the key, but
everything else I tried following those recipes also didn't cure
anything. Question: Does Appendix B really describe things as they
actually are on the NeXT, or is that just BSD 4.3 stuff?
I had also, by now, discovered a very interesting file: /private/adm/
lpd-errors. There are LOTS of error messages here, going back for
more than a year. Who writes these messages? some of them seem to
get written on reboot, others on invocation of lpd, and who knows
what else. A pretty complete sample of the ones that I am NOW
getting is:
Nov 13 13:20:11 whistler npd[340]: found mismatch on printer status,
0x00000000 != 0x00000001
Nov 16 09:05:13 whistler lpd[92]: /bootdisk/Administration/Private/
spool/np: No such file or directory
Nov 16 15:40:56 whistler npd[107]: daemonmsg, connect
Nov 19 15:58:29 whistler lpd: Name lpr Msg connect "/dev/printer" No
such file or directory
Nov 20 20:58:47 whistler lpd: Name lpc Msg connect "/dev/printer" No
such file or directory
(At those times on the 19th and 20th I was thrashing around again
with some of the above attempts to get lpd back.) What do these
messages mean, who writes them, and does it sort out what my problem
is?
From the comp.sys.next newsgroup, by the way, it appears that there
are at least two other NeXT users out there who have lost their lpd
daemon in a way which sounds very much like what I see.
Any help on this would be very much appreciated.
Dick Silbar (NeXT mail: silbar@whistler.lanl.gov)