lprng-devel Mailing List for LPRng

Brought to you by: grumpf_, papowell

lprng-devel — ML for discussions regarding the development of lprng

You can subscribe to this list here.

2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (5)	Dec (43)
2007	Jan (34)	Feb (58)	Mar (8)	Apr (23)	May (9)	Jun (23)	Jul	Aug (15)	Sep (7)	Oct (10)	Nov (2)	Dec (3)
2008	Jan (14)	Feb (12)	Mar (9)	Apr (6)	May (13)	Jun (2)	Jul (18)	Aug (5)	Sep	Oct	Nov	Dec
2009	Jan	Feb	Mar (9)	Apr (2)	May	Jun (1)	Jul	Aug (6)	Sep (1)	Oct (1)	Nov (2)	Dec (1)
2010	Jan	Feb (4)	Mar (3)	Apr (4)	May	Jun	Jul (2)	Aug	Sep (3)	Oct (1)	Nov (4)	Dec (1)
2011	Jan	Feb (14)	Mar (5)	Apr	May	Jun (2)	Jul (2)	Aug (2)	Sep	Oct (7)	Nov (2)	Dec
2012	Jan (2)	Feb	Mar	Apr (1)	May	Jun (6)	Jul	Aug (2)	Sep	Oct	Nov	Dec (1)
2013	Jan (1)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep (3)	Oct	Nov (8)	Dec
2014	Jan	Feb	Mar	Apr (2)	May	Jun	Jul	Aug	Sep (3)	Oct (6)	Nov	Dec
2016	Jan	Feb	Mar	Apr	May (1)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

1 2 3 .. 18 > >> (Page 1 of 18)

[Lprng-devel] New Version 3.9.0

From: Walter H. <wh...@bf...> - 2019-05-16 07:23:31

Hello List,
lprng is a mature project, so error reports are rare.

Today i merged a bugfix for lpr where a crash happened
when debug was enabled. I used it as excuse to bump the
revision number to 3.9. Please not that other bugfixes
where in git already.

[Lprng-devel] "Make_passthrough: pid XXXX, dup2(6, 0) failed" with LPRNG 3.8.C and Samba 4.3.8 on FreeBSD

From: Benedikt H. <tic...@gm...> - 2016-06-25 11:22:59

Hello List,

(FreeBSD 10.3-RELEASE-p4 i386, Lprng 3.8.C and Samba 4.3.8 installed via
pkg())

I have set up a PDF converter queue that converts PS input to PDF and puts
it on its website. Recently I had samba join the AD domain here, and ever
since my pdf converter fails.

Upon much trial, error and debugging I found out that when I start the
Lprng service BEFORE the Samba service, everything is working. However, the
default startup sequence is Samba first, then Lprng (due to dependencies).

More debugging revealed that the problem is the input filter spawning fails
(ie even a dummy filter that only touches "/tmp/hello" is not executed).

In the Log, I get entries like

2016-06-25-12:39:16.710 wagi-util [4827] (Server)  pdf: Trim_status_file: '
status.pr' max 10, min 0, size 6197
2016-06-25-12:39:16.710 wagi-util [4827] (Server)  pdf: Wait_for_subserver:
pid_to_wait_for -1, flags 1
*Make_passthrough: pid 4829, dup2(6,0) failed*2016-06-25-12:39:16.712
wagi-util [4828] (Worker - Print)  pdf: Wait_for_pid: returning 'JFAIL',
exit status 'exit status 32 (JFAIL)'
2016-06-25-12:39:16.712 wagi-util [4828] (Worker - Print)  pdf: setstatus:
msg 'IF filter 'pdflpd' filter exit status 'JFAIL''
2016-06-25-12:39:16.712 wagi-util [4828] (Worker - Print)  pdf: setstatus:
msg 'printing finished'

The spurious "Make_passthrough" statement looks as if it weren't written by
the normal logging routine but rather was spit out by some other routine.

I have a hunch that samba somehow sits on a file or a process that becomes
unavailable for Lprng, UNLESS Lprng is started before samba.

I disabled printing in samba, gave it a completely unrelated printcap file,
disabled spoolss etc, all to no avail.

Of course, setting up a vanilla FreeBSD in Virtualbox and just installing
Lprng and Samba worked fine in either start sequence, but then I haven't
joined it to a domain nor am I using a modified nsswitch.conf and other
settings that are used in a domain context.

I now have the workaround of stopping both services and starting them in
the correct sequence, but it still bugs me.

Any idea where to look next?

/etc/printcap:
.common:
   :sd=/var/spool/lpd/%P
   :lf=log
   :max_log_file_size=256
   :done_status=0
   :sh:mx=0:mc=0
pdf:tc=.common:lp=/dev/null:filter=/usr/local/libexec/filters/pdflpd:

/usr/local/etc/smb4.conf
[global]
   workgroup = MYDOMAIN
   netbios name = MYNAME
   security = ads
   realm = MYDOMAIN.MYCOMPANY.COM
   encrypt passwords = yes
   password server = 10.65.10.220
   wins server = 10.65.10.220
   client ldap sasl wrapping = plain
   idmap config * : backend = tdb
   idmap config * : range = 2000-9999
   idmap config DPRDOM : backend = rid
   idmap config DORDOM : range = 10000-29999
   winbind enum users = yes
   winbind enum groups = yes
   winbind nested groups = yes
   dos charset = CP850
   unix charset = UTF8
   restrict anonymous = 2
   server string = "Utility Server"
   load printers = No
   printing = bsd
   printcap name = /usr/local/etc/samba-printcap
   disable spoolss = Yes
   local master = no
   smb ports = 445
   map to guest = Bad User
   read raw = Yes
   write raw = Yes
   max xmit = 65535
   socket options = TCP_NODELAY IPTOS_LOWDELAY
   use sendfile = true
   vfs objects = acl_xattr
   map acl inherit = Yes
   store dos attributes = Yes
   oplocks = Yes


Stumped in Zurich

-- 
Ben

[Lprng-devel] [PATCH] fix: handle the child exit better

From: Ales N. <al...@su...> - 2016-05-25 10:27:27

The random-kill (of pid which previously belonged to some lprng
child) could still happen (when plp_waitpid() was called with -1).
This is a very obvious improvement of the previous patch.

Signed-off-by: Ales Novak <al...@su...>
---
 src/common/child.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/common/child.c b/src/common/child.c
index 103b1fa..7d594cf 100644
--- a/src/common/child.c
+++ b/src/common/child.c
@@ -84,7 +84,7 @@ pid_t plp_waitpid (pid_t pid, plp_status_t *statusPtr, int options)
 	report = waitpid(pid, statusPtr, options );
 	DEBUG2("plp_waitpid: returned %d, status %s", report,
 		Decode_status( statusPtr ) );
-	if (report > 0) forget_child(pid);
+	if (report > 0) forget_child(report);
 	return report;
 }
 
-- 
2.7.0

Re: [Lprng-devel] Problem with Kerberized lpr on OS X 10.10

From: Rick C. <rc...@co...> - 2014-10-30 15:04:11

Walter,

By then I may know more about whether it works or not!

Yours,
-Rick

On 10/30/14, 3:58 AM, walter harms wrote:
> many thx for the patch,
> i am still out of time, so a new release may take some time
> but i plan for next month.
>
> re,
>   wg
>
>
> Am 29.10.2014 17:44, schrieb Rick Cochran:
>> Walter,
>>
>> Early reports indicate that the first attached patch (to 3.8.C) solves
>> the "closing guarded file descriptor" problem.
>>
>> The second attached patch seems to be necessary to get 3.8.C to compile
>> under OS X (10.9), and also previous versions.
>>
>> I have not included any conditional compilation code.
>>
>> Yours,
>> -Rick
>>
>> On 10/25/14, 10:11 AM, Rick Cochran wrote:
>>> Broken by a software patent!  My joy is complete.
>>>
>>> On 10/25/14, 5:50 AM, walter harms wrote:
>>>>
>>>>
>>>> Am 24.10.2014 19:40, schrieb Rick Cochran:
>>>>> Walter,
>>>>>
>>>>> Thanks for the quick response!  Good to know you are still there.
>>>>>
>>>>> So the "not implemented" is a red herring?
>>>>>
>>>>> I get some interesting results by googling 'os x "guarded fd
>>>>> exception"'.  It looks like Apple is trying to "help" us again.
>>>>
>>>> it is hard to believe but ...
>>>> http://www.google.com/patents/US20130339313
>>>>>
>>>>
>>>> re,
>>>>     wh
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Lprng-devel mailing list
>>> Lpr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lprng-devel
>>>

Re: [Lprng-devel] Problem with Kerberized lpr on OS X 10.10

From: Rick C. <rc...@co...> - 2014-10-29 16:44:45

Attachments: LPRng-3.8.C.guarded_fd.patch LPRng-3.8.C.patch

Walter,

Early reports indicate that the first attached patch (to 3.8.C) solves 
the "closing guarded file descriptor" problem.

The second attached patch seems to be necessary to get 3.8.C to compile 
under OS X (10.9), and also previous versions.

I have not included any conditional compilation code.

Yours,
-Rick

On 10/25/14, 10:11 AM, Rick Cochran wrote:
> Broken by a software patent!  My joy is complete.
>
> On 10/25/14, 5:50 AM, walter harms wrote:
>>
>>
>> Am 24.10.2014 19:40, schrieb Rick Cochran:
>>> Walter,
>>>
>>> Thanks for the quick response!  Good to know you are still there.
>>>
>>> So the "not implemented" is a red herring?
>>>
>>> I get some interesting results by googling 'os x "guarded fd
>>> exception"'.  It looks like Apple is trying to "help" us again.
>>
>> it is hard to believe but ...
>> http://www.google.com/patents/US20130339313
>>>
>>
>> re,
>>    wh
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Lprng-devel mailing list
> Lpr...@li...
> https://lists.sourceforge.net/lists/listinfo/lprng-devel
>

Re: [Lprng-devel] Problem with Kerberized lpr on OS X 10.10

From: Rick C. <rc...@co...> - 2014-10-25 14:11:27

Broken by a software patent!  My joy is complete.

On 10/25/14, 5:50 AM, walter harms wrote:
>
>
> Am 24.10.2014 19:40, schrieb Rick Cochran:
>> Walter,
>>
>> Thanks for the quick response!  Good to know you are still there.
>>
>> So the "not implemented" is a red herring?
>>
>> I get some interesting results by googling 'os x "guarded fd
>> exception"'.  It looks like Apple is trying to "help" us again.
>
> it is hard to believe but ...
> http://www.google.com/patents/US20130339313
>>
>
> re,
>   wh
>

Re: [Lprng-devel] Problem with Kerberized lpr on OS X 10.10

From: Rick C. <rc...@co...> - 2014-10-25 14:10:40

Walter,

Thanks again for your helpful reply.

I am Cc'ing the list, so your responses will go out.

I wonder if the solution at this link will suffice:
https://gitorious.org/libreoffice/core/commit/73a508f574995f09559c003cb810e5d2ff2691c2

I intend to try it.

I suppose I could use NFS.  Dropbox might be easier if all you want to 
do is transfer files.

Yours,
-Rick

On 10/25/14, 5:20 AM, walter harms wrote:
>
>
> Am 24.10.2014 19:40, schrieb Rick Cochran:
>> Walter,
>>
>> Thanks for the quick response!  Good to know you are still there.
>
> I am still :) unfortunately i am also low on time, so my answer
> will take some time, more over my provider has sourceforge.net
> on its blacklist, so feel free to forward the mail to the list also.
>
>>
>> So the "not implemented" is a red herring?
>>
>> I get some interesting results by googling 'os x "guarded fd
>> exception"'.  It looks like Apple is trying to "help" us again.
>
> I am wondering also what apple is intending here. Fortunately there is
> a at lease an error message.
>
>> It is extremely difficult for me to debug this because it occurs only on
>> a particular student's laptop.  I cannot reproduce it elsewhere.
>>
>> Oops!  I just tried it again on my VM and it crashed nicely.  I have
>> appended Apple's crash dump.  As the google articles state, it died
>> closing an FD.
>
> Thx for you effort, i have no access to an apple system.
> I will try to replicate the solution that what proposed in the link i
> send you.
>
>
>> I have attached the Apple crash dump, which I had a heck of a time
>> getting from my Parallels VM to its host machine.
>
> Just for my curiosity, could you use nfs ?
>
> re,
>   wh
>
>>
>> Yours,
>> -Rick
>>
>> On 10/24/14, 11:56 AM, walter harms wrote:
>>>
>>> Hello Rich,
>>>
>>> Am 24.10.2014 17:21, schrieb Rick Cochran:
>>>> Hi,
>>>>
>>>> On one workstation running Yosemite, lpr crashes, producing these
>>>> entries in system.log:
>>>>
>>>> Oct 24 10:31:20 dhcp-hol-1591.redrover.cornell.edu lpr[1972]:
>>>> MITKerberosShim: function krb5_auth_con_initivector not implemented
>>> seems harmless:
>>> http://web.mit.edu/kerberos/krb5-devel/doc/appdev/refs/api/krb5_auth_con_initivector.html
>>>
>>>
>>>> Oct 24 10:31:21 dhcp-hol-1591 kernel[0]: lpr: guarded fd exception: fd 5
>>>> code 0x1 guard 0x982080c8
>>>
>>> according to this
>>> [https://gitorious.org/libreoffice/core/commit/73a508f574995f09559c003cb810e5d2ff2691c2]
>>>
>>> it seen 5 is a "guarded fd" (0,1,2 i can understand but why 5 ?) that
>>> can not be closed, it seems that OS X
>>> need some special safe guards.
>>>
>>> could you run gdb or strace to give a hint where that crash occurs ?
>>>
>>>
>>>> Oct 24 10:31:21 dhcp-hol-1591.redrover.cornell.edu ReportCrash[1970]:
>>>> Saved crash report for lpr[1972] version ??? to
>>>> /Library/Logs/DiagnosticReports/lpr_2014-10-24-103121_XXXXX-MacBook-Pro-2.crash
>>>>
>>>>
>>>>
>>>> On my own VM running Yosemite, lpr works just fine.
>>>>
>>>> I'm using LPRng-3.8.B.
>>>>
>>>
>>> re,
>>>    wh
>>>

Re: [Lprng-devel] Problem with Kerberized lpr on OS X 10.10

From: Rick C. <rc...@co...> - 2014-10-24 17:40:50

Attachments: lpr_2014-10-24-125343_Ricks-MacBook-Pro.crash

Walter,

Thanks for the quick response!  Good to know you are still there.

So the "not implemented" is a red herring?

I get some interesting results by googling 'os x "guarded fd 
exception"'.  It looks like Apple is trying to "help" us again.

It is extremely difficult for me to debug this because it occurs only on 
a particular student's laptop.  I cannot reproduce it elsewhere.

Oops!  I just tried it again on my VM and it crashed nicely.  I have 
appended Apple's crash dump.  As the google articles state, it died 
closing an FD.

I have attached the Apple crash dump, which I had a heck of a time 
getting from my Parallels VM to its host machine.

Yours,
-Rick

On 10/24/14, 11:56 AM, walter harms wrote:
>
> Hello Rich,
>
> Am 24.10.2014 17:21, schrieb Rick Cochran:
>> Hi,
>>
>> On one workstation running Yosemite, lpr crashes, producing these
>> entries in system.log:
>>
>> Oct 24 10:31:20 dhcp-hol-1591.redrover.cornell.edu lpr[1972]:
>> MITKerberosShim: function krb5_auth_con_initivector not implemented
> seems harmless: http://web.mit.edu/kerberos/krb5-devel/doc/appdev/refs/api/krb5_auth_con_initivector.html
>
>> Oct 24 10:31:21 dhcp-hol-1591 kernel[0]: lpr: guarded fd exception: fd 5
>> code 0x1 guard 0x982080c8
>
> according to this [https://gitorious.org/libreoffice/core/commit/73a508f574995f09559c003cb810e5d2ff2691c2]
> it seen 5 is a "guarded fd" (0,1,2 i can understand but why 5 ?) that can not be closed, it seems that OS X
> need some special safe guards.
>
> could you run gdb or strace to give a hint where that crash occurs ?
>
>
>> Oct 24 10:31:21 dhcp-hol-1591.redrover.cornell.edu ReportCrash[1970]:
>> Saved crash report for lpr[1972] version ??? to
>> /Library/Logs/DiagnosticReports/lpr_2014-10-24-103121_XXXXX-MacBook-Pro-2.crash
>>
>>
>> On my own VM running Yosemite, lpr works just fine.
>>
>> I'm using LPRng-3.8.B.
>>
>
> re,
>   wh
>

[Lprng-devel] Problem with Kerberized lpr on OS X 10.10

From: Rick C. <rc...@co...> - 2014-10-24 15:21:55

Hi,

On one workstation running Yosemite, lpr crashes, producing these 
entries in system.log:

Oct 24 10:31:20 dhcp-hol-1591.redrover.cornell.edu lpr[1972]: 
MITKerberosShim: function krb5_auth_con_initivector not implemented
Oct 24 10:31:21 dhcp-hol-1591 kernel[0]: lpr: guarded fd exception: fd 5 
code 0x1 guard 0x982080c8
Oct 24 10:31:21 dhcp-hol-1591.redrover.cornell.edu ReportCrash[1970]: 
Saved crash report for lpr[1972] version ??? to 
/Library/Logs/DiagnosticReports/lpr_2014-10-24-103121_XXXXX-MacBook-Pro-2.crash

On my own VM running Yosemite, lpr works just fine.

I'm using LPRng-3.8.B.

Any suggestions would be appreciated.

-Rick

Re: [Lprng-devel] [PATCH] Forget pid of child that have exited.

From: Tim M. <Tim...@nd...> - 2014-09-05 16:54:28

In regard to: Re: [Lprng-devel] [PATCH] Forget pid of child that have...:

> our customer reported an error: on LPRng exit some totally unrelated
> processes got killed. The only explanation for that I was able to find was
> the LPRng way of handling child processes. It seems to me, that though the
> children have been waited for, i.e. their pids are free to be reused, thir
> pids are still stored in Process_list. And if they are (and the LPRng
> daemon has the right to kill them), they will be killed at exit.

That perfectly describes a scenario we've seen many times in the last
few years.  When LPRng has been running a few weeks or months, doing an

 	sudo /etc/init.d/lpd stop

will often kill dozens of unrelated processes, including my shell, my
sshd, etc.

You've found, and hopefully fixed, a problem that has been an annoyance
for us for a long time.

Thanks!

Tim

> On 2014-9-5 10:26, walter harms wrote:
>
>> thx for the patch,
>> how did you notice that bug ?
>>
>> re,
>> wh
>>
>> Am 03.09.2014 10:51, schrieb Ales Novak:
>>> We need to forget about the child that had exited and had already
>>> been successfully waited for. Otherwise the LPRng will try to kill
>>> that pid on its exit - but the pid may be assigned to completely
>>> another process.
>>>
>>> The patch is adding the function forget_child(pid_t), which walks
>>> through the list of childs and tries to find the specified one
>>> and remove it. The function is called after successfull waitpid()
>>> call.
>>>
>>> Signed-off-by: Ales Novak <al...@su...>
>>> ---
>>>  src/common/child.c | 31 +++++++++++++++++++++++++++++++
>>>  1 file changed, 31 insertions(+)
>>>
>>> diff --git a/src/common/child.c b/src/common/child.c
>>> index 8c4ee3d..5476c75 100644
>>> --- a/src/common/child.c
>>> +++ b/src/common/child.c
>>> @@ -34,6 +34,36 @@
>>>  #  include <sys/ttold.h>
>>>  #endif
>>>
>>> +/*
>>> + * When the child was successfully waited on, it stayed in the
>>> + * Process_list and henceforth the lpd tried to kill it when
>>> + * cleaning up. But the pid may have been assigned to another
>>> + * process!
>>> + *
>>> + * So what is neccessary is to walk through the process list,
>>> + * and remove the pid which has just exited (or have successfully
>>> + * been waited for, to be precise).
>>> + *
>>> + * The removal is done by replacing the record by the last one in
>>> + * the list and decrementing the record count.
>>> + */
>>> +static void forget_child(pid_t pid)
>>> +{
>>> +	int i;
>>> +
>>> +	for( i = 0; i < Process_list.count; ++i ){
>>> +		if (pid == Cast_ptr_to_int(Process_list.list[i]))
>>> +			break;
>>> +	}
>>> +
>>> +	if (i < Process_list.count) {
>>> +		DEBUG2("forget_child: found the child with pid %d", pid);
>>> +		Process_list.list[i] = Process_list.list[Process_list.count-1];
>>> +		Process_list.count --;
>>> +	} else {
>>> +		DEBUG2("forget_child: child with pid %d not found", pid);
>>> +	}
>>> +}
>>>
>>>  /*
>>>   * Patrick Powell
>>> @@ -51,6 +81,7 @@ pid_t plp_waitpid (pid_t pid, plp_status_t *statusPtr, int options)
>>>  	report = waitpid(pid, statusPtr, options );
>>>  	DEBUG2("plp_waitpid: returned %d, status %s", report,
>>>  		Decode_status( statusPtr ) );
>>> +	if (report > 0) forget_child(pid);
>>>  	return report;
>>>  }
>>>
>>
>
>

-- 
Tim Mooney                                             Tim...@nd...
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

Re: [Lprng-devel] [PATCH] Forget pid of child that have exited.

From: Ales N. <al...@su...> - 2014-09-05 08:34:16

Hello,

our customer reported an error: on LPRng exit some totally unrelated 
processes got killed. The only explanation for that I was able to find was 
the LPRng way of handling child processes. It seems to me, that though the 
children have been waited for, i.e. their pids are free to be reused, thir 
pids are still stored in Process_list. And if they are (and the LPRng 
daemon has the right to kill them), they will be killed at exit.

On 2014-9-5 10:26, walter harms wrote:

> thx for the patch,
> how did you notice that bug ?
>
> re,
> wh
>
> Am 03.09.2014 10:51, schrieb Ales Novak:
>> We need to forget about the child that had exited and had already
>> been successfully waited for. Otherwise the LPRng will try to kill
>> that pid on its exit - but the pid may be assigned to completely
>> another process.
>>
>> The patch is adding the function forget_child(pid_t), which walks
>> through the list of childs and tries to find the specified one
>> and remove it. The function is called after successfull waitpid()
>> call.
>>
>> Signed-off-by: Ales Novak <al...@su...>
>> ---
>>  src/common/child.c | 31 +++++++++++++++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/src/common/child.c b/src/common/child.c
>> index 8c4ee3d..5476c75 100644
>> --- a/src/common/child.c
>> +++ b/src/common/child.c
>> @@ -34,6 +34,36 @@
>>  #  include <sys/ttold.h>
>>  #endif
>>
>> +/*
>> + * When the child was successfully waited on, it stayed in the
>> + * Process_list and henceforth the lpd tried to kill it when
>> + * cleaning up. But the pid may have been assigned to another
>> + * process!
>> + *
>> + * So what is neccessary is to walk through the process list,
>> + * and remove the pid which has just exited (or have successfully
>> + * been waited for, to be precise).
>> + *
>> + * The removal is done by replacing the record by the last one in
>> + * the list and decrementing the record count.
>> + */
>> +static void forget_child(pid_t pid)
>> +{
>> +	int i;
>> +
>> +	for( i = 0; i < Process_list.count; ++i ){
>> +		if (pid == Cast_ptr_to_int(Process_list.list[i]))
>> +			break;
>> +	}
>> +
>> +	if (i < Process_list.count) {
>> +		DEBUG2("forget_child: found the child with pid %d", pid);
>> +		Process_list.list[i] = Process_list.list[Process_list.count-1];
>> +		Process_list.count --;
>> +	} else {
>> +		DEBUG2("forget_child: child with pid %d not found", pid);
>> +	}
>> +}
>>
>>  /*
>>   * Patrick Powell
>> @@ -51,6 +81,7 @@ pid_t plp_waitpid (pid_t pid, plp_status_t *statusPtr, int options)
>>  	report = waitpid(pid, statusPtr, options );
>>  	DEBUG2("plp_waitpid: returned %d, status %s", report,
>>  		Decode_status( statusPtr ) );
>> +	if (report > 0) forget_child(pid);
>>  	return report;
>>  }
>>
>

-- 
Ales Novak

[Lprng-devel] [PATCH] Forget pid of child that have exited.

From: Ales N. <al...@su...> - 2014-09-03 08:51:55

We need to forget about the child that had exited and had already
been successfully waited for. Otherwise the LPRng will try to kill
that pid on its exit - but the pid may be assigned to completely
another process.

The patch is adding the function forget_child(pid_t), which walks
through the list of childs and tries to find the specified one
and remove it. The function is called after successfull waitpid()
call.

Signed-off-by: Ales Novak <al...@su...>
---
 src/common/child.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/src/common/child.c b/src/common/child.c
index 8c4ee3d..5476c75 100644
--- a/src/common/child.c
+++ b/src/common/child.c
@@ -34,6 +34,36 @@
 #  include <sys/ttold.h>
 #endif
 
+/*
+ * When the child was successfully waited on, it stayed in the
+ * Process_list and henceforth the lpd tried to kill it when
+ * cleaning up. But the pid may have been assigned to another
+ * process!
+ *
+ * So what is neccessary is to walk through the process list,
+ * and remove the pid which has just exited (or have successfully
+ * been waited for, to be precise).
+ *
+ * The removal is done by replacing the record by the last one in
+ * the list and decrementing the record count.
+ */
+static void forget_child(pid_t pid)
+{
+	int i;
+
+	for( i = 0; i < Process_list.count; ++i ){
+		if (pid == Cast_ptr_to_int(Process_list.list[i]))
+			break;
+	}
+
+	if (i < Process_list.count) {
+		DEBUG2("forget_child: found the child with pid %d", pid);
+		Process_list.list[i] = Process_list.list[Process_list.count-1];
+		Process_list.count --;
+	} else {
+		DEBUG2("forget_child: child with pid %d not found", pid);
+	}
+}
 
 /*
  * Patrick Powell
@@ -51,6 +81,7 @@ pid_t plp_waitpid (pid_t pid, plp_status_t *statusPtr, int options)
 	report = waitpid(pid, statusPtr, options );
 	DEBUG2("plp_waitpid: returned %d, status %s", report,
 		Decode_status( statusPtr ) );
+	if (report > 0) forget_child(pid);
 	return report;
 }
 
-- 
1.8.1.4