From owner-freebsd-hackers Mon Feb 18 0:43:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gwdu60.gwdg.de (gwdu60.gwdg.de [134.76.98.60]) by hub.freebsd.org (Postfix) with ESMTP id 5335837B404 for ; Mon, 18 Feb 2002 00:43:36 -0800 (PST) Received: from localhost (kheuer@localhost) by gwdu60.gwdg.de (8.11.6/8.11.6) with ESMTP id g1I8hRm49018; Mon, 18 Feb 2002 09:43:28 +0100 (CET) (envelope-from kheuer@gwdg.de) X-Authentication-Warning: gwdu60.gwdg.de: kheuer owned process doing -bs Date: Mon, 18 Feb 2002 09:43:27 +0100 (CET) From: Konrad Heuer To: Garance A Drosihn Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lpd & filter stderr & log files In-Reply-To: Message-ID: <20020218091439.M38497-100000@gwdu60.gwdg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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=09Fri Feb 15 14:42:18 2002 --- /usr/src/usr.sbin/lpr/lpd/printjob.c.org=09Thu Dec 20 05:14:26 2001 *************** *** 600,606 **** =09register char *prog; =09int fi, fo; =09FILE *fp; ! =09char *av[20], buf[BUFSIZ]; /* GWDG: size of av increased */ =09int pid, p[2], stopped; =09union wait status; =09struct stat stb; --- 600,606 ---- =09register char *prog; =09int fi, fo; =09FILE *fp; ! =09char *av[15], buf[BUFSIZ]; =09int pid, p[2], stopped; =09union wait status; =09struct stat stb; *************** *** 757,763 **** =09=09=09pp->printer, format); =09=09return(ERROR); =09} - =09prog =3D pp->filters[LPF_INPUT]; /* GWDG: quick & dirty: always use if= */ =09if (prog =3D=3D NULL) { =09=09(void) close(fi); =09=09syslog(LOG_ERR, --- 757,762 ---- *************** *** 772,782 **** =09av[n++] =3D "-n"; =09av[n++] =3D logname; =09av[n++] =3D "-h"; ! =09av[n++] =3D class; /* GWDG: use traditional class instead of origin_ho= st */ ! =09av[n++] =3D "-f"; ! =09av[n++] =3D origin_host; /* GWDG: pass origin_host to filter additiona= lly */ ! =09av[n++] =3D "-j"; ! =09av[n++] =3D jobname; /* GWDG: pass jobname to filter additionally */ =09av[n++] =3D pp->acct_file; =09av[n] =3D 0; =09fo =3D pfd; --- 771,777 ---- =09av[n++] =3D "-n"; =09av[n++] =3D logname; =09av[n++] =3D "-h"; ! =09av[n++] =3D origin_host; =09av[n++] =3D pp->acct_file; =09av[n] =3D 0; =09fo =3D 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=FCr wissenschaftliche Datenverarbeitung mbH G=D6ttingen http://www.freebsd.org Am Fa=DFberg, D-37077 G=D6ttingen http://www.daemonnews.o= rg Deutschland (Germany) kheuer@gwdg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message