Issue 3542 - daemon: select failed (22): invalid argument
Summary: daemon: select failed (22): invalid argument
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-15 21:14 UTC by robert.roll@utah.edu
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description robert.roll@utah.edu 2005-02-15 21:14:41 UTC
Full_Name: Robert Roll
Version: openldap 2.2.23
OS: solaris 9 (on sparc)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (155.101.224.85)


        I am encountering the following:

                daemon: select failed (22): Invalid argument

        This only seemed to crop up when I was attempting a syncrepl.
However, after seeing where its occurring, it's not clear to me that it
might not be able to occur at other times. 

Config:
        Sparc Solaris 9
        openldap 2.2.23
        db 4.3.27

        Below is some output demonstrating the problem. Note, I did add
some debug print statements to ../servers/slapd/daemon.c . I have
annotated them below. It appears that a large negative seconds is passed
in the time structure to select. That is what is causing the invalid
argument. 

        I managed to "fix" this for now, by changing an equals
comparison to a less than or equals. I didn't explore the logic real
close, so I am not sure if this is the best thing to do or not.

        I have also included a diff, showing my debug print statements,
along with the comparison change I made to get around my immediate
problem.

BTW -- 

         I have also encountered a number of what seem to be already
reported bugs about the syncrepl provider server terminating after an
improper termination of the client machine.

        Maybe, it is documented somewhere and I missed it. It made all
the difference in the world to index entryUUID. If this isn't
documented, it really should be. 
         
        I think this syncrepl stuff is pretty cool and I really hope
those working on it can get the bugs worked out. I really appreciate
their efforts ! :)


                                                        Thanks,

                                                        Robert


Robert Roll
University of Utah
OIT (Office of Information Technology)
Robert.Roll@Utah.Edu
(801) 581-7655



ldap_chkResponseList for msgid=-1, all=0
ldap_chkResponseList returns NULL
ldap_int_select
connection_get(11): got connid=0
daemon: added 11r

***DEBUG PRINT***
diff 1, tdelta 1, cat->tv_sec 1108397241, now 1108397240 now/1000 
 1108397

daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptors

***DEBUG PRINT***
diff -1108397241, tdelta 1, cat->tv_sec 0, now 1108397241 now/1000
1108397


daemon: select: listen=7 active_threads=0 tvp=zero
daemon: select: listen=8 active_threads=0 tvp=zero

*** DEBUG PRINT ***
nfds: 12 tv.tv_sec -1108397241, tv.tv_usec 0 tvp->tv_sec -1108397241,
tvp->tv_usec 0

daemon: select failed (22): Invalid argument
daemon: abnormal condition, shutdown initiated.
daemon: closing 7
daemon: closing 8
slapd shutdown: waiting for 1 threads to terminate
=>do_syncrepl
connection_get(11): got connid=0
daemon: removing 11r
ldap_unbind
ldap_free_request (origid 2, msgid 2)
ldap_free_connection
ldap_send_unbind
ber_flush: 7 bytes to sd 11
ldap_free_connection: actually freed
slapd shutdown: initiated
====> bdb_cache_release_all
slapd shutdown: freeing system resources.
slapd stopped.


######## Diff #############3

> diff daemon.c.bak daemon.c
1388c1388,1389
<                       if ( diff == 0 )
---
>                       printf("diff %d, tdelta %d, cat->tv_sec %d, now
%d now/1000 %d\n", diff, tdelta, cat->tv_sec, now, now/1000);
>                       if ( diff <= 0 )
1437a1439,1440
> 
>                                 printf("nfds: %d tv.tv_sec %d,
tv.tv_usec %d tvp->tv_sec %d, tvp->tv_usec %d\n", nfds, tv.tv_sec,
tv.tv_usec,  tvp->tv_sec, tvp->tv_usec);
> 




  

Comment 1 Howard Chu 2005-03-17 03:44:47 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 2 Howard Chu 2005-03-17 04:02:06 UTC
Thanks for the bug report. An alternate fix is now in CVS HEAD, please test.

Robert.Roll@utah.edu wrote:

>BTW -- 
>
>         I have also encountered a number of what seem to be already
>reported bugs about the syncrepl provider server terminating after an
>improper termination of the client machine.
>
>        Maybe, it is documented somewhere and I missed it. It made all
>the difference in the world to index entryUUID. If this isn't
>documented, it really should be. 
>  
>
It is documented in the latest revision of the Admin Guide, but I don't 
believe that has been published anywhere yet. You can of course retrieve 
it from CVS.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

Comment 3 Kurt Zeilenga 2005-03-18 21:51:40 UTC
changed state Test to Closed
Comment 4 James Lick 2005-05-03 13:49:58 UTC
I encountered this problem also, and also on a Solaris 9 system.  I 
applied the fix in CVS daemon.c *1.326* 
<http://www.openldap.org/devel/cvsweb.cgi/%7Echeckout%7E/servers/slapd/daemon.c?rev=1.326&hideattic=1&sortbydate=0> 
against openldap 2.2.26 and it fixed the problem.  Will this fix be 
committed to the 2.2 branch or just 2.3?

-- 
James Lick -- 黎建溥 -- jlick@jameslick.com -- http://jameslick.com/

Comment 5 Howard Chu 2005-05-03 23:33:52 UTC
changed notes
changed state Closed to Release
Comment 6 Howard Chu 2005-05-03 23:35:08 UTC
jlick@drivel.com wrote:

>I encountered this problem also, and also on a Solaris 9 system.  I 
>applied the fix in CVS daemon.c *1.326* 
><http://www.openldap.org/devel/cvsweb.cgi/%7Echeckout%7E/servers/slapd/daemon.c?rev=1.326&hideattic=1&sortbydate=0> 
>against openldap 2.2.26 and it fixed the problem.  Will this fix be 
>committed to the 2.2 branch or just 2.3?
>
Seems like the bug was closed prematurely, so the fix was skipped. It's 
now in CVS for 2.2.27.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

Comment 7 Kurt Zeilenga 2005-06-13 17:04:44 UTC
changed state Release to Closed
Comment 8 Howard Chu 2009-02-17 05:10:12 UTC
moved from Software Bugs to Archive.Software Bugs
Comment 9 OpenLDAP project 2014-08-01 21:06:35 UTC
fixed in HEAD,RE22