lml@cbnews.ATT.COM (L. Mark Larsen) (05/13/89)
There is a small bug in lpsched (SVR2 up to at least SVR3.1) that causes
a spurious error message when a print request fails. If you set up
your interface script right, this can be gotten around. For those with
source, the problem is in lpsched.c in postprint(). Here is the problem
section:
else { /* printer interface exited */
resetstatus(1, 1); /* dequeue request */
if(excode != 0) {
sprintf(errmsg,
"error code %d in request %s-%d on printer %s",
excode, dst, seqno, pr);
wrtmail(logname, errmsg);
}
else { /* no errors detected by interface pgm */
fclose(rfile);
unlink(rname);
The real problem here is that resetstatus() tries to remove the rfile
(and corresponding dfile(s), if any) without having first closed it.
Of course, the files are removed when this incarnation of lpsched exits
but not before causing the main scheduler to believe that the request
is still valid! So, if the printer were automatically disabled by the
interface script upon failure, the next time it is enabled, lpsched tries
to print a non-existant request which causes preprint() to send a second
mail message to the puzzled user.
For those who like to debate these issues, I wonder if it is a good idea
to remove the print request upon failure or to leave it to the interface
script to decide. The latter choice seemed to have been taken in SVR0
(since we never had the observed troubles when running that version)
so I decided to do the same:
else { /* printer interface exited */
fclose(rfile);
if(excode != 0) {
resetstatus(0, 1); /* don't dequeue request */
sprintf(errmsg,
"error code %d in request %s-%d on printer %s",
excode, dst, seqno, pr);
wrtmail(logname, errmsg);
}
else { /* no errors detected by interface pgm */
resetstatus(1, 1); /* dequeue request */
cheers,
-lml