On Fri, 15 Feb 2002, Garance A Drosihn wrote:
> At 3:16 PM +0100 2/15/02, Konrad Heuer wrote:
> >Unfortunately, some changes in the lpd code that happened last year
> >(as far as I remember) are very disadvantageous for the operation
> >of our (heavily loaded) printer server which is based on FreeBSD
> >for years now.
>
> Well, I'm willing to see what we can do to help you out.
Thank you very much for your reply and all your efforts. Please excuse my
delayed reply but I didn't read my mail yesterday and the day before.
> >Prior to the changes, we could observe the progress of print jobs
> >by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information
> >written by the filter programs to stderr gets catched by temporary
> >log files the names of which are created randomly. After a print
> >job has completed, the contents of the temporary file is appended
> >to the queue log file.
>
> Hmm. I suspect that any change there is more than a year old. We
> did change how the temporary-files were generated, but I think lpd
> has used temporary files for stderr for a long time.
I didn't look into earlier versions of the code, I've to admit.
Nevertheless, the "tail -f" did work. Hmm, sounds strange.
> >For our purposes, that's often too late. Why have these changes
> >been made? And can the old behaviour be restored?
>
> I think the reason it's done this way (with the temporary files) is
> so multiple queues could point to a single log file, and so all the
> lines for any one job would be added onto that log file in one shot.
>
> I think there's a number of other reasons too. A quick look at
> the history for lpd/printjob.c seems to indicate that it has
> always behaved this way (or at least, it was always the *intention*
> that it behave this way, perhaps there were some bugs fixed).
This may be. On the other hand, on a system with a large number of printer
queues (about 120 in our case) I'd never get the idea to use a single log
file ;-).
> >We really would like to see what happens during printing a job
> >(imagine a 300 mb postscript print job which may a lot of time
> >to execute completely).
>
> Well, here we see 1-gig postscript files going to our plotters, so
> it's pretty easy for me to imagine a 300-meg one... :-)
I see and I'm pleased you understand me!
> It's obvious that you just changed to a new version of lpr. Did
> you also change any of your scripts? In some of my scripts, what
> I do is:
>
> exec 2>>$LPD_LOG_dir/$pname/log
>
> This causes the *script* to redirect stderr to where I want it.
> Would that work in your situation?
I got this idea this morning in bathroom, too. I hope it will work in our
situation.
By the way, may I suggest some other modifications to the lpd code? I know
my suggestions might introduce problems with existing input filters, but I
apply these changes to printjob.c for years now and I'm very happy with
them:
*** /usr/src/usr.sbin/lpr/lpd/printjob.c Fri Feb 15 14:42:18 2002
--- /usr/src/usr.sbin/lpr/lpd/printjob.c.org Thu Dec 20 05:14:26 2001
***************
*** 600,606 ****
register char *prog;
int fi, fo;
FILE *fp;
! char *av[20], buf[BUFSIZ]; /* GWDG: size of av increased */
int pid, p[2], stopped;
union wait status;
struct stat stb;
--- 600,606 ----
register char *prog;
int fi, fo;
FILE *fp;
! char *av[15], buf[BUFSIZ];
int pid, p[2], stopped;
union wait status;
struct stat stb;
***************
*** 757,763 ****
pp->printer, format);
return(ERROR);
}
- prog = pp->filters[LPF_INPUT]; /* GWDG: quick & dirty: always use if */
if (prog == NULL) {
(void) close(fi);
syslog(LOG_ERR,
--- 757,762 ----
***************
*** 772,782 ****
av[n++] = "-n";
av[n++] = logname;
av[n++] = "-h";
! av[n++] = class; /* GWDG: use traditional class instead of origin_host */
! av[n++] = "-f";
! av[n++] = origin_host; /* GWDG: pass origin_host to filter additionally */
! av[n++] = "-j";
! av[n++] = jobname; /* GWDG: pass jobname to filter additionally */
av[n++] = pp->acct_file;
av[n] = 0;
fo = pfd;
--- 771,777 ----
av[n++] = "-n";
av[n++] = logname;
av[n++] = "-h";
! av[n++] = origin_host;
av[n++] = pp->acct_file;
av[n] = 0;
fo = pfd;
We need the traditional possibility for users to enter a class
specification by the `-C' flag of lpr which is then passed to the filter
script. But we need a reliable information about the origin of a print job
in the script, too. Furthermore, it's very nice to know the name of the
job within the filter script not only for logging, but also for PostScript
header page generation. The quick&dirty hack to force execution of the
input filter helps us since people tend to use lpr flags like `-d' or `-v'
accidently. Maybe one could turn this q&d hack into an lpd command line
flag which enforces input filter execution independent of what the control
file says?
Thank you very much for your reply again; and please let me know if can
help in any way.
Best regards
Konrad Heuer Personal Bookmarks:
Gesellschaft für wissenschaftliche
Datenverarbeitung mbH GÖttingen http://www.freebsd.org
Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org
Deutschland (Germany)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
