Bug 32183
| Summary: | [MFC] lpd problem. | ||
|---|---|---|---|
| Product: | Base System | Reporter: | yuu-w <yuu-w> |
| Component: | bin | Assignee: | Garance A Drosehn <gad> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->gad Garance's problem ;-) WATANABE Yuichi (yuu-w) writes: > if > 1) lpd received printing-job request from remote-client > and > 2) target-printer is busy > then > some messages are in /var/log/messages, /var/log/lpd-errs > > lpd[nnnn]: Error receiving job from hostname.com: > lpd[nnnn]: prt01: ctl_renametf invalid filename: tfB521hostname.com This error message comes from the routine ctl_renametf, which is in common_source/ctlinfo.c . The reason it's complaining is that the temporary control file should start with 'tfA', not 'tfB'. Now to find out why it might be 'tfB'... The temporary filename is created (in recvjob.c) by: strlcpy(tfname, cp, sizeof(tfname)); tfname[sizeof (tfname) - 1] = '\0'; tfname[0] = 't'; This implies that the sending-host wants to send a control-file which starts with 'cfB'. I have never seen that happen. I am pretty sure there are a number of places in lpr/lpd which assume a control file is always going to start with 'cfA', so if someone is sending 'cfB' then I will need to keep that in mind as I check through the source. Could you tell me what operating system is sending the job to your freebsd box? Could you check the queue for prt01 on that box, and see if it really does have a 'cfB*' file in it? Are there any other files which start with 'cf*' but do not start with 'cfA*' or 'cfB*'? I am not sure why it would matter if the 'target-printer is busy'. How busy is it? Is there a large backlog of jobs? If control files can have a third letter of other than 'A', I can change the processing in ctlinfo.c to allow that. Note that right now ctlinfo works by creating another temp file starting with 'tfB', so which is why I had that check in there. I can fix that, of course, but first I want to figure out why this is happening. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu State Changed From-To: open->suspended I wrote a patch for this problem and sent it to the user. The user has tried it, and it did fix the problem they were seeing. A version of this fix has been committed to -current, and will be MFC'ed to -stable within a few weeks (hopefully in 10 days...). State Changed From-To: suspended->closed The fix for this reported problem has now been committed to 4.4-stable. |
if 1) lpd received printing-job request from remote-cliant and 2) target-printe is busy then some messages are in /var/log/messages, /var/log/lpd-errs lpd[nnnn]: Error receiving job from hostname.com: lpd[nnnn]: prt01: ctl_renametf invalid filename: tfB521hostname.com I made comparison source program of 4.4R with 3.4R. /usr/src/usr.sbin/lpr/lpd/recvjob.c readjob(pp) @ case '\2': /* read cf file */ In the 3.4R, ----- if (link(tfname, cp) < 0) frecverr("%s: %m", tfname); (void) unlink(tfname); tfname[0] = '\0'; ----- In the 4.4R ----- tfname[0] = '\0'; if (errmsg != NULL) { frecverr("%s: %s", pp->printer, errmsg); /*NOTREACHED*/ /* (void) unlink(tfname); */ /* need !? */ } -----