Carlos Carvalho writes ("Re: Bug#3038: SOLVED: can't remove print jobs"):
> Ian Jackson ([EMAIL PROTECTED]) wrote on 17 May 1996 14:24:
...
> >This means that kill(,0) is almost always a mistake.
> >
> >Could you check to see whether lpr is failing to chec
Package: lpr
Version: 5.9-11
Ian Jackson ([EMAIL PROTECTED]) wrote on 17 May 1996 14:24:
>Rick Macdonald writes ("Bug#3038: SOLVED: can't remove print jobs"):
>> On Thu, 16 May 1996, Carlos Carvalho wrote:
>>
>> > I also found that lo
Rick Macdonald writes ("Bug#3038: SOLVED: can't remove print jobs"):
> On Thu, 16 May 1996, Carlos Carvalho wrote:
>
> > I also found that lockchk in line 156 of rmjob.c is doing a
> >
> > if (kill(cur_daemon, 0) < 0) {
> >
> > I don&
On Thu, 16 May 1996, Carlos Carvalho wrote:
> I also found that lockchk in line 156 of rmjob.c is doing a
>
> if (kill(cur_daemon, 0) < 0) {
>
> I don't think it's right to send a signal number 0, at least it's not
> documented. Also it has no effect at all, though it returns 0.
It's no
Package: lpr
Version: 5.9-11
After quite a long dive in the lpr sources I found the reason that we
can't remove jobs in a remote queue. First, our /etc/hosts was like
this:
1.2.3.4 fully.qualified.domain.name hostname
Inverting the columns to be like this
1.2.3.4 hostname fully.qualifie
We have a print server just upgraded to 1.1. When we submit jobs from
another machine it prints is fine. However, if we try to lprm
from the machine where we issued the lpr, we get
print_server: : permission denied
(one more line with permission denied)
Even root cannot remove the job. If the sa
6 matches
Mail list logo
