Re: procmail and remote printing problem
Am Die, 21 Nov 2000 07:29:46 schrieb Martin Stenzel:
> I. error message when fetching mail:
> ------------------------------------
>
> When fetching mail I get the following error message:
>
> reading message 80 of 80 (5321 octets) .....procmail: Kernel-lock failed
> procmail: Kernel-unlock failed
>
>
> My '.fetchmailrc' looks like this:
(doesn't matter)
> The mail is being fetched and processed by procmail, despite of this error
> message. So should I worry?
Yes, you should ALWAYS worry :) It seems that locking is failing here.
The Hurd doesn't support full POSIX locking. It can only lock whole
files, not partial chunks. procmail sets locks at different offsets
in a file, that's why the Hurd flock returns an error, which procmail
ignores. As long as you don't run multiple procmails, or otherwise
have two concurrent accesses to the mailbox, you should be safe.
But it is something to worry about. Implementing full POSIX file locking
is an API change, and a server extension. It's not a simple task, but
probably not too hard either. Any takers?
> II. error message when trying to print remotely:
> ------------------------------------------------
> On my attached Linux box an lpd is running, however, when trying to
> print from the Hurd directly from a program (e.g. amaya, lyx [I verified
this
> with several programs]) I get the following error message:
Do amaya and lyx both work? Amazing.
> rlpr: error: connect to orangina:515: Connection refused
> rlpr: fatal error: client_open(): cannot connect to lpd
Mmh. You should probably try to find out more about what happens
inside the code here.
> 'orangina' is the hostname of the Linux box where the lpd runs.
> On the other hand invoking printing by issueing the command
> 'lpr whatever_postscript_file.ps' on the command line the Linux box lpd
> happily accepts the order from the Hurd box.
That's not too bad, isn't it?
> I do not know whether this problem comes from not porting (actually
> I did not change anything in the sources) 'rlpr' to the Hurd
> correctly or if there is another reason for it.
> Since printing from the command line works I assume the problem must exist
> between the applications (lyx, amaya) and the 'rlpr'.
That seems to be the case.
> Did anyone successfully port 'lpr' or 'lprng' to the Hurd?
I think I compiled one of those, but of course the parallel port
support in gnumach is broken (/dev/lpr).
Reply to: