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 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 not in the Linux man page but it is in others (like Solaris). The 0
>> signal can be used to tell if the process is still valid (running).
>> I've used it a few times. I assumed it was pretty standard.
>
>If lpr is doing this then it is almost certainly broken. You see,
>pids are be reused, so that it's never safe to store a pid in a
>variable and then use it for something later unless you're the
>process's parent (in which case kill(,0) is redundant) or can do some
>other check to see that the process is the same as the one it used to
>be.
>
>This means that kill(,0) is almost always a mistake.
>
>Could you check to see whether lpr is failing to check this, and if so
>report it as a bug ?
It's lpd in the case of a remote printer, but it's certainly doing it.
I think the point is that it's going to remove the files, so it should
kill any process that has them open. How can it determine the pid's of
the processes?
Carlos
