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
5 matches
Mail list logo