Sorry, missed your build instructions, only saw them just now. I've just
kicked off that build and I'll check it tomorrow once I'm back in.

One note, it appears it's ./autogen.sh not ./autogen.pl ...

On Thu, May 17, 2018 at 6:16 PM, Jonathan Vaughn <jonat...@creatuity.com>
wrote:

> Welp, I'm still getting the -fPIC error ... so I may need to figure out
> how to do it with COPR or something.
>
> On Thu, May 17, 2018 at 4:16 PM, Jonathan Vaughn <jonat...@creatuity.com>
> wrote:
>
>> I've never used COPR. I've dabbled with RPMs in the past but that was...
>> CentOS 6 I think, and I wasn't making source code changes so much as just
>> copying and pasting SRPMs from another RPM platform to build for CentOS,
>> using the regular rpmbuild stuff.
>>
>> I did actually try just copying the configure line (manually expanding
>> the various vars) from the SRPM and just doing an old fashioned make, but
>> the first try bailed shy of an hour at linking with some error about not
>> having -fPIC specified, so I restarted it with -fPIC to see if it would at
>> least build. So if I should still try the code changes, if that build
>> finishes I can try it (I was planning to just copy the respective binaries
>> on top of the installed ones), but if it turned out the suggested code
>> changes were pointless then there's no point waiting for it to finish
>> building.
>>
>> On Thu, May 17, 2018 at 4:11 PM, Rob Crittenden <rcrit...@redhat.com>
>> wrote:
>>
>>> Jonathan Vaughn via FreeIPA-users wrote:
>>> > Oops, hit reply instead of reply-all
>>> >
>>> > NSPR RPMs
>>> >
>>> > # yum list installed nspr*
>>> > Installed Packages
>>> > nspr.armv7hl
>>> >           4.19.0-1.fc27
>>>
>>> >          @updates
>>> > nspr-debuginfo.armv7hl
>>> >           4.19.0-1.fc27
>>>
>>> >          @updates-debuginfo
>>> > nspr-debugsource.armv7hl
>>> >           4.19.0-1.fc27
>>>
>>> >          @updates-debuginfo
>>> > nspr-devel.armv7hl
>>> >           4.19.0-1.fc27
>>>
>>> >          @updates
>>> >
>>> > As for building it with the changes you proposed previously - should I
>>> > not bother? I realized last night that the last and only time I built
>>> > anything *on* a Pi was a Pi Zero and that's why it was so terribly
>>> slow.
>>> > This Pi 3 ain't fast but it's fast enough to build stuff in far less
>>> > than half a day (unlike the Zero)...
>>>
>>> If you are handy with rpms you could build it in copr.
>>>
>>> rob
>>>
>>> >
>>> >
>>> > On Thu, May 17, 2018 at 5:07 AM, thierry bordaz <tbor...@redhat.com
>>> > <mailto:tbor...@redhat.com>> wrote:
>>> >
>>> >
>>> >
>>> >     On 05/16/2018 10:03 PM, Jonathan Vaughn wrote:
>>> >>     I've been just using the packages from Fedora. I can build it
>>> >>     potentially but I don't have a cross build environment set up at
>>> >>     the moment. From experience I'd want to do that first because
>>> >>     building anything on the Pi usually takes ages.
>>> >>
>>> >>     I'd been "redacting" the hostnames but I'll stop bothering since
>>> >>     it looks like we're getting far enough into the weeds now that the
>>> >>     difference in string lengths after "redacting" might actually be a
>>> >>     red herring.
>>> >>
>>> >>     (gdb) p *agmt
>>> >>     $1 = {hostname = 0x1ef9be0 "ipa-12.creatuity.internal", port =
>>> >>     389, transport_flags = 0, binddn = 0x1e8f650 "", creds =
>>> >>     0x1e8f7a0, bindmethod = 3, replarea = 0x1ef9480,
>>> >>       frac_attrs = 0x1ef99c0, frac_attrs_total = 0x1ef9a40,
>>> >>     frac_attr_total_defined = 1, schedule = 0x1a7f0c0, auto_initialize
>>> >>     = 502, dn = 0x1ef8d00, rdn = 0x1ef8c20,
>>> >>       long_name = 0x1a7f100 "agmt=\"cn=meToipa-12.creatuit
>>> y.internal\"
>>> >>     (ipa-12:5)", protocol = 0x19c2930, changecounters = 0x186d180,
>>> >>     num_changecounters = 0,
>>> >>       max_changecounters = 256, last_update_start_time = 1526500697,
>>> >>     last_update_end_time = 1526500697,
>>> >>       last_update_status = "Error (0) Replica acquired successfully:
>>> >>     Incremental update succeeded", '\000' <repeats 954 times>,
>>> >>     update_in_progress = 0, is_enabled = 1,
>>> >>       last_init_start_time = 0, last_init_end_time = 0,
>>> >>     last_init_status = '\000' <repeats 1023 times>, lock = 0x1ee3740,
>>> >>     consumerRUV = 0x1f14e50,
>>> >>       consumerSchemaCSN = 0x317c520, consumerRID = 4, tmpConsumerRID =
>>> >>     0, timeout = 120, stop_in_progress = 0, busywaittime = 0,
>>> >>     pausetime = 0, priv = 0x0,
>>> >>       attrs_to_strip = 0x1ef9ba0, agreement_type = 0, protocol_timeout
>>> >>     = 0x1e8f5f0, maxcsn = 0x0, flowControlWindow = 1000,
>>> >>     flowControlPause = 2000, ignoreMissingChange = 0,
>>> >>       attr_lock = 0x1ef9c20, WaitForAsyncResults = 100}
>>> >>     (gdb) p *agmt->replarea
>>> >>     $2 = {flag = 15 '\017', udn = 0x1efce80
>>> >>     "dc=creatuity,dc=internal", dn = 0x1ef9460
>>> >>     "dc=creatuity,dc=internal", ndn = 0x1ef8ec0
>>> >>     "dc=creatuity,dc=internal", ndn_len = 24}
>>> >>     (gdb) p *agmt->rdn
>>> >>     $3 = {flag = 0 '\000', rdn = 0x19c2840
>>> >>     "cn=meToipa-12.creatuity.internal", rdns = 0x0, butcheredupto =
>>> >>     -1, nrdn = 0x0, all_rdns = 0x0, all_nrdns = 0x0}
>>> >>
>>> >>     [root@ipa-11 ~]# grep -r PRId64 /usr/include/*
>>> >>     /usr/include/inttypes.h:# define PRId64         __PRI64_PREFIX "d"
>>> >>     [root@ipa-11 ~]# grep -r PRIu16 /usr/include/*
>>> >>     /usr/include/inttypes.h:# define PRIu16         "u"
>>> >>
>>> >>
>>> >>
>>> >>     On Wed, May 16, 2018 at 2:55 PM, Mark Reynolds
>>> >>     <mreyno...@redhat.com <mailto:mreyno...@redhat.com>> wrote:
>>> >>
>>> >>
>>> >>
>>> >>         On 05/16/2018 03:43 PM, Jonathan Vaughn wrote:
>>> >>>         The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl,
>>> >>>         which appears to be the latest available version.
>>> >>
>>> >>         Perhaps something is off with the inttypes on Raspberry.  Are
>>> >>         you building this yourself on Raspberry?  Can we make code
>>> >>         changes and compile/install them?
>>> >>
>>> >>         Before we do that though, in gdb can you run these commands in
>>> >>         the same gdb frame:
>>> >>
>>> >>         (gdb) p *agmt->replarea
>>> >>         (gdb) p *agmt->rdn
>>> >>
>>> >>
>>> >>         Then do:
>>> >>
>>> >>         # grep -r PRId64 /usr/include/*
>>> >>         # grep -r PRIu16 /usr/include/*
>>> >>
>>> >>
>>> >>         So if you can compile the source, then change this line in
>>> >>         ldap/servers/plugins/replication/repl5_agmt.c:3036, but don't
>>> >>         do this yet until you get me the info I just requested.
>>> >>
>>> >>         From:
>>> >>
>>> >>                         agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%"
>>> >>         PRId64 ";%" PRIu16 ";%s", slapi_sdn_get_dn(agmt->replarea),
>>> >>
>>> >>         slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)),
>>> >>         agmt->hostname,
>>> >>                                                          agmt->port,
>>> >>         agmt->consumerRID, maxcsn);
>>> >>
>>> >>         To:
>>> >>
>>> >>                         agmt->maxcsn =
>>> >>         slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
>>> >>         slapi_sdn_get_dn(agmt->replarea),
>>> >>
>>> >>         slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)),
>>> >>         agmt->hostname,
>>> >>
>>> >>         (long)agmt->port, (int)agmt->consumerRID, maxcsn);
>>> >>
>>> >>
>>> >>         Thanks,
>>> >>         Mark
>>> >>
>>> >>>
>>> >>>         On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn
>>> >>>         <jonat...@creatuity.com <mailto:jonat...@creatuity.com>>
>>> wrote:
>>> >>
>>> >
>>> >     The agreement structure looks valid to me. it should not lead to a
>>> >     crash.
>>> >
>>> >     What looks weird to me is the order of the arguments of cvt_s.
>>> >     It is called: rv = cvt_s(ss, u.s, width, prec, flags);
>>> >     But the crashing thread shows the opposite order: flags,
>>> prec,width,
>>> >     str, ss
>>> >
>>> >     The others frame do not show this change of order.
>>> >     Also 'str=4' that would be a meaningful value for 'prec=4'.
>>> >
>>> >     From debug perspective I only imagine disassemble the two last
>>> >     frames to confirm parameters.
>>> >     What are the nspr rpms ?
>>> >
>>> >
>>> >
>>> >
>>> >>>             (gdb) up
>>> >>>             #1  0xb6926b40 in cvt_s (flags=0, prec=<optimized out>,
>>> >>>             width=0, str=0x4 <error: Cannot access memory at address
>>> >>>             0x4>, ss=<optimized out>)
>>> >>>                 at ../../.././nspr/pr/src/io/prprf.c:374
>>> >>>             374             slen = strlen(str);
>>> >>>             (gdb) up
>>> >>>             #2  dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2
>>> "",
>>> >>>             fmt@entry=0xb34da770 <agmt_set> "\360\317p\002", ap=...)
>>> >>>             at ../../.././nspr/pr/src/io/prprf.c:1018
>>> >>>             1018                rv = cvt_s(ss, u.s, width, prec,
>>> flags);
>>> >>>             (gdb) up
>>> >>>             #3  0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770
>>> >>>             <agmt_set> "\360\317p\002", ap=..., ap@entry=...) at
>>> >>>             ../../.././nspr/pr/src/io/prprf.c:1184
>>> >>>             1184        rv = dosprintf(&ss, fmt, ap);
>>> >>>             (gdb) up
>>> >>>             #4  0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0
>>> >>>             "%s;%s;%s;%ld;%d;%s") at ldap/servers/slapd/ch_malloc.c
>>> :331
>>> >>>             331         p = PR_vsmprintf(fmt, ap);
>>> >>>             (gdb) up
>>> >>>             #5  0xb34625a4 in agmt_update_maxcsn
>>> >>>             (r=r@entry=0x2737810, sdn=0x38d9a40, sdn@entry=0x10,
>>> >>>             op=<optimized out>, mods=0x10, mods@entry=0x27d0100,
>>> >>>             csn=csn@entry=0x38de350)
>>> >>>                 at ldap/servers/plugins/replicati
>>> on/repl5_agmt.c:3036
>>> >>>             3036                    agmt->maxcsn =
>>> >>>             slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
>>> >>>             slapi_sdn_get_dn(agmt->replarea),
>>> >>>             (gdb) p *agmt
>>> >>>             $1 = {hostname = 0x2757be0 "ipa-12.company.internal",
>>> >>>             port = 389, transport_flags = 0, binddn = 0x26ed650 "",
>>> >>>             creds = 0x26ed7a0, bindmethod = 3, replarea = 0x2757480,
>>> >>>               frac_attrs = 0x27579c0, frac_attrs_total = 0x2757a40,
>>> >>>             frac_attr_total_defined = 1, schedule = 0x22dd0c0,
>>> >>>             auto_initialize = 502, dn = 0x2756d00, rdn = 0x2756c20,
>>> >>>               long_name = 0x22dd100
>>> >>>             "agmt=\"cn=meToipa-12.company.internal\" (ipa-12:5)",
>>> >>>             protocol = 0x2220930, changecounters = 0x20cb180,
>>> >>>             num_changecounters = 0,
>>> >>>               max_changecounters = 256, last_update_start_time =
>>> >>>             1526499214, last_update_end_time = 1526499214,
>>> >>>               last_update_status = "Error (0) Replica acquired
>>> >>>             successfully: Incremental update succeeded", '\000'
>>> >>>             <repeats 954 times>, update_in_progress = 0, is_enabled
>>> = 1,
>>> >>>               last_init_start_time = 0, last_init_end_time = 0,
>>> >>>             last_init_status = '\000' <repeats 1023 times>, lock =
>>> >>>             0x2741740, consumerRUV = 0x2772e50,
>>> >>>               consumerSchemaCSN = 0x39da520, consumerRID = 4,
>>> >>>             tmpConsumerRID = 0, timeout = 120, stop_in_progress = 0,
>>> >>>             busywaittime = 0, pausetime = 0, priv = 0x0,
>>> >>>               attrs_to_strip = 0x2757ba0, agreement_type = 0,
>>> >>>             protocol_timeout = 0x26ed5f0, maxcsn = 0x0,
>>> >>>             flowControlWindow = 1000, flowControlPause = 2000,
>>> >>>             ignoreMissingChange = 0,
>>> >>>               attr_lock = 0x2757c20, WaitForAsyncResults = 100}
>>> >>>
>>> >>>
>>> >>>             On Tue, May 15, 2018 at 5:36 PM, Mark Reynolds
>>> >>>             <mreyno...@redhat.com <mailto:mreyno...@redhat.com>>
>>> wrote:
>>> >>>
>>> >>>                 This looks really familiar and I thought it was
>>> >>>                 fixed.  It should have been fixed in 1.3.7.10-1
>>> >>>                 (https://pagure.io/389-ds-base/issue/49618
>>> >>>                 <https://pagure.io/389-ds-base/issue/49618>).   In
>>> >>>                 your debug session go "up" into agmt_maxcsn_update()
>>> >>>                 and do:
>>> >>>
>>> >>>                 (gdb) p *agmt
>>> >>>
>>> >>>                 Then send us that output please.
>>> >>>
>>> >>>                 Thanks,
>>> >>>                 Mark
>>> >>>
>>> >>>
>>> >>>                 On 05/15/2018 05:29 PM, Jonathan Vaughn via
>>> >>>                 FreeIPA-users wrote:
>>> >>>>                 Here is a backtrace from live gdb after the
>>> >>>>                 segfault. Looks like things went wrong somewhere
>>> >>>>                 during in the replication code ?
>>> >>>>
>>> >>>>                 Thread 36 "ns-slapd" received signal SIGSEGV,
>>> >>>>                 Segmentation fault.
>>> >>>>                 [Switching to Thread 0x9e0bc280 (LWP 4662)]
>>> >>>>                 strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
>>> >>>>                 142             ldrd    data1a, data1b, [src]
>>> >>>>                 (gdb) bt
>>> >>>>                 #0  0xb6728f2e in strlen () at
>>> >>>>                 ../sysdeps/arm/armv6t2/strlen.S:142
>>> >>>>                 #1  0xb6973b40 in cvt_s (flags=0, prec=<optimized
>>> >>>>                 out>, width=0, str=0x4 <error: Cannot access memory
>>> >>>>                 at address 0x4>, ss=<optimized out>)
>>> >>>>                     at ../../.././nspr/pr/src/io/prprf.c:374
>>> >>>>                 #2  0xb6973b40 in dosprintf (ss=ss@entry
>>> =0x9e0bb4bc,
>>> >>>>                 fmt=0xb34fddf2 "", fmt@entry=0xb3527770 <agmt_set>
>>> >>>>                 "\360\357\305\002", ap=...)
>>> >>>>                     at ../../.././nspr/pr/src/io/prprf.c:1018
>>> >>>>                 #3  0xb6973c8c in PR_vsmprintf
>>> >>>>                 (fmt=fmt@entry=0xb3527770 <agmt_set>
>>> >>>>                 "\360\357\305\002", ap=..., ap@entry=...) at
>>> >>>>                 ../../.././nspr/pr/src/io/prprf.c:1184
>>> >>>>                 #4  0xb6e36d18 in slapi_ch_smprintf (fmt=0xb34fdde0
>>> >>>>                 "%s;%s;%s;%ld;%d;%s") at
>>> >>>>                 ldap/servers/slapd/ch_malloc.c:331
>>> >>>>                 #5  0xb34af5a4 in agmt_update_maxcsn
>>> >>>>                 (r=r@entry=0x2c89810, sdn=0x3e2bac0, sdn@entry
>>> =0x10,
>>> >>>>                 op=<optimized out>, mods=0x10, mods@entry
>>> =0x3eec100,
>>> >>>>                 csn=csn@entry=0x3e30220)
>>> >>>>                     at
>>> >>>>                 ldap/servers/plugins/replication/repl5_agmt.c:3036
>>> >>>>                 #6  0xb34bd424 in write_changelog_and_ruv
>>> >>>>                 (pb=pb@entry=0x2cb54a0) at
>>> >>>>                 ldap/servers/plugins/replicat
>>> ion/repl5_plugins.c:1124
>>> >>>>                 #7  0xb34be7ec in multimaster_be_betxnpostop_add
>>> >>>>                 (pb=0x2cb54a0) at
>>> >>>>                 ldap/servers/plugins/replicat
>>> ion/repl5_plugins.c:855
>>> >>>>                 #8  0xb34be880 in multimaster_mmr_postop
>>> >>>>                 (pb=<optimized out>, flags=560) at
>>> >>>>                 ldap/servers/plugins/replicat
>>> ion/repl5_plugins.c:616
>>> >>>>                 #9  0xb6e8fcf0 in plugin_call_mmr_plugin_postop
>>> >>>>                 (pb=pb@entry=0x2cb54a0, e=e@entry=0x0,
>>> >>>>                 flags=flags@entry=560) at
>>> >>>>                 ldap/servers/slapd/plugin_mmr.c:65
>>> >>>>                 #10 0xb35ba870 in ldbm_back_add (pb=0x2cb54a0) at
>>> >>>>                 ldap/servers/slapd/back-ldbm/ldbm_add.c:1218
>>> >>>>                 #11 0xb6e2ce4c in op_shared_add
>>> >>>>                 (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/slapd/add.c:679
>>> >>>>                 #12 0xb6e2d35c in add_internal_pb
>>> >>>>                 (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/slapd/add.c:407
>>> >>>>                 #13 0xb6e2e0f8 in slapi_add_internal_pb
>>> >>>>                 (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/slapd/add.c:332
>>> >>>>                 #14 0xb368db50 in ipa_topo_util_segment_write
>>> >>>>                 (tconf=tconf@entry=0x2cb5860,
>>> >>>>                 tsegm=tsegm@entry=0x3f2d9a0) at
>>> topology_util.c:1251
>>> >>>>                 #15 0xb368e01c in ipa_topo_util_update_agmt_list
>>> >>>>                 (conf=0x2cb5860, repl_segments=<optimized out>) at
>>> >>>>                 topology_util.c:696
>>> >>>>                 #16 0xb368891c in ipa_topo_apply_shared_config () at
>>> >>>>                 topology_init.c:165
>>> >>>>                 #17 0xb6e4e65c in eq_call_all () at
>>> >>>>                 ldap/servers/slapd/eventq.c:278
>>> >>>>                 #18 0xb6e4e65c in eq_loop (arg=<optimized out>) at
>>> >>>>                 ldap/servers/slapd/eventq.c:323
>>> >>>>                 #19 0xb6982d68 in _pt_root (arg=0x2c8da40) at
>>> >>>>                 ../../.././nspr/pr/src/pthreads/ptthread.c:201
>>> >>>>                 #20 0xb6906ee8 in start_thread (arg=0x9e0bc280) at
>>> >>>>                 pthread_create.c:465
>>> >>>>                 #21 0xb6785da8 in None () at
>>> >>>>                 ../sysdeps/unix/sysv/linux/arm/clone.S:73
>>> >>>>
>>> >>>>
>>> >>>>                 On Tue, May 15, 2018 at 3:01 AM, thierry bordaz
>>> >>>>                 <tbor...@redhat.com <mailto:tbor...@redhat.com>>
>>> wrote:
>>> >>>>
>>> >>>>                     Hi Jonathan,
>>> >>>>
>>> >>>>                     This problem looks new to me and has something
>>> >>>>                     specific to your environment.
>>> >>>>                     I think the best approach is to continue to
>>> >>>>                     debug on your system if you have the possibility
>>> >>>>                     to do so.
>>> >>>>
>>> >>>>                     From strace we can see that DS started smoothly
>>> >>>>                     (created its pid file then notified systemd it
>>> >>>>                     was running fine). According to the pstack
>>> >>>>                     nunc-stans was running and was able to accept
>>> >>>>                     network events even if it appears it detected no
>>> >>>>                     incoming connection.
>>> >>>>                     So the server should be ready to serve for some
>>> >>>>                     seconds (more than a minute), then it crashed
>>> >>>>                     with one thread dereferencing likely a wrong
>>> >>>>                     pointer.
>>> >>>>
>>> >>>>                     Could you attach a debugger when the server is
>>> >>>>                     started and wait for the sigsegv to occur. Then
>>> >>>>                     confirm the crashing thread backstack.
>>> >>>>                     If it is confirmed, I am afraid this is a stack
>>> >>>>                     corruption and valgrind could help
>>> >>>>                     (http://www.port389.org/docs/
>>> 389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind
>>> >>>>                     <http://www.port389.org/docs/
>>> 389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind
>>> >).
>>> >>>>
>>> >>>>                     best regards
>>> >>>>                     thierry
>>> >>>>
>>> >>>>
>>> >>>>                     On 05/14/2018 10:20 PM, Jonathan Vaughn wrote:
>>> >>>>>                     Here's a strace from before it dies. Most of
>>> >>>>>                     the elapsed time is it waiting on some futex
>>> >>>>>                     call it looks like near the end, when it
>>> >>>>>                     finally "returns" (from lack of strace output
>>> >>>>>                     for duration of call I assume it didn't
>>> >>>>>                     actually return but SIGSEGV in that call) and
>>> >>>>>                     strace prints ' = ?' on the futex it then
>>> >>>>>                     immediately reports SIGSEGV after. So maybe the
>>> >>>>>                     problem is that futex call, which may mean the
>>> >>>>>                     problem is not directly in 389DS / FreeIPA
>>> itself?
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>                     15:13:31.626587 (+     0.000630) listen(8, 128)
>>> >>>>>                     = 0 <0.000068>
>>> >>>>>                     15:13:31.626857 (+     0.000235) listen(9, 128)
>>> >>>>>                     = 0 <0.000048>
>>> >>>>>                     15:13:31.627111 (+     0.000251)
>>> >>>>>                     clock_gettime(CLOCK_MONOTONIC,
>>> {tv_sec=1464932,
>>> >>>>>                     tv_nsec=41120614}) = 0 <0.000085>
>>> >>>>>                     15:13:31.627457 (+     0.000356)
>>> >>>>>                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>                     {tv_sec=1526328811, tv_nsec=627560772}) = 0
>>> >>>>>                     <0.000043>
>>> >>>>>                     15:13:31.631233 (+     0.003839)
>>> >>>>>                     clock_gettime(CLOCK_MONOTONIC,
>>> {tv_sec=1464932,
>>> >>>>>                     tv_nsec=45286796}) = 0 <0.000077>
>>> >>>>>                     15:13:31.631720 (+     0.000427)
>>> >>>>>                     clock_gettime(CLOCK_MONOTONIC,
>>> {tv_sec=1464932,
>>> >>>>>                     tv_nsec=45661430}) = 0 <0.000042>
>>> >>>>>                     15:13:31.631955 (+     0.000220)
>>> >>>>>                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>                     {tv_sec=1526328811, tv_nsec=632049036}) = 0
>>> >>>>>                     <0.000047>
>>> >>>>>                     15:13:31.635669 (+     0.003785)
>>> >>>>>                     clock_gettime(CLOCK_MONOTONIC,
>>> {tv_sec=1464932,
>>> >>>>>                     tv_nsec=49725840}) = 0 <0.000146>
>>> >>>>>                     15:13:31.636484 (+     0.000784) write(16, "a",
>>> >>>>>                     1) = 1 <0.000118>
>>> >>>>>                     15:13:31.636855 (+     0.000341) sched_yield()
>>> >>>>>                     = 0 <0.000252>
>>> >>>>>                     15:13:31.637322 (+     0.000470)
>>> >>>>>                     futex(0x1cb57a0, FUTEX_WAKE_PRIVATE, 1) = 1
>>> >>>>>                     <0.000088>
>>> >>>>>                     15:13:31.637897 (+     0.000610) write(16, "a",
>>> >>>>>                     1) = 1 <0.000221>
>>> >>>>>                     15:13:31.638394 (+     0.000467) sched_yield()
>>> >>>>>                     = 0 <0.000047>
>>> >>>>>                     15:13:31.638619 (+     0.000202)
>>> >>>>>                     futex(0x1cb5710, FUTEX_WAKE_PRIVATE, 1) = 1
>>> >>>>>                     <0.000065>
>>> >>>>>                     15:13:31.638908 (+     0.000298)
>>> >>>>>                     openat(AT_FDCWD,
>>> >>>>>                     "/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid",
>>> >>>>>                     O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33 <0.000831>
>>> >>>>>                     15:13:31.640260 (+     0.001387) getpid() =
>>> >>>>>                     32353 <0.000077>
>>> >>>>>                     15:13:31.640558 (+     0.000256) fstat64(33,
>>> >>>>>                     {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>> >>>>>                     <0.000119>
>>> >>>>>                     15:13:31.641106 (+     0.000556) write(33,
>>> >>>>>                     "32353\n", 6) = 6 <0.000127>
>>> >>>>>                     15:13:31.641472 (+     0.000362) close(33) = 0
>>> >>>>>                     <0.000519>
>>> >>>>>                     15:13:31.642216 (+     0.000758)
>>> >>>>>                     chmod("/var/run/dirsrv/slapd-
>>> COMPANY-INTERNAL.pid",
>>> >>>>>                     0644) = 0 <0.000152>
>>> >>>>>                     15:13:31.642900 (+     0.000679)
>>> >>>>>                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>                     {tv_sec=1526328811, tv_nsec=643020294}) = 0
>>> >>>>>                     <0.000056>
>>> >>>>>                     15:13:31.643495 (+     0.000590) write(2,
>>> >>>>>                     "[14/May/2018:15:13:31.643020294 "..., 134) =
>>> >>>>>                     134 <0.002697>
>>> >>>>>                     15:13:31.646515 (+     0.003052)
>>> >>>>>                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>                     {tv_sec=1526328811, tv_nsec=646694394}) = 0
>>> >>>>>                     <0.000075>
>>> >>>>>                     15:13:31.646892 (+     0.000337) write(4,
>>> >>>>>                     "[14/May/2018:15:13:31.646694394 "..., 134) =
>>> >>>>>                     134 <0.000522>
>>> >>>>>                     15:13:31.647841 (+     0.000973) fsync(4) = 0
>>> >>>>>                     <0.005967>
>>> >>>>>                     15:13:31.654425 (+     0.006617)
>>> >>>>>                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>                     {tv_sec=1526328811, tv_nsec=654598946}) = 0
>>> >>>>>                     <0.000253>
>>> >>>>>                     15:13:31.655137 (+     0.000717) write(2,
>>> >>>>>                     "[14/May/2018:15:13:31.654598946 "..., 136) =
>>> >>>>>                     136 <0.002427>
>>> >>>>>                     15:13:31.658312 (+     0.003165)
>>> >>>>>                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>                     {tv_sec=1526328811, tv_nsec=658486117}) = 0
>>> >>>>>                     <0.000251>
>>> >>>>>                     15:13:31.659032 (+     0.000682) write(4,
>>> >>>>>                     "[14/May/2018:15:13:31.658486117 "..., 136) =
>>> >>>>>                     136 <0.000346>
>>> >>>>>                     15:13:31.659623 (+     0.000595) fsync(4) = 0
>>> >>>>>                     <0.003311>
>>> >>>>>                     15:13:31.663230 (+     0.003642) getpid() =
>>> >>>>>                     32353 <0.000045>
>>> >>>>>                     15:13:31.663732 (+     0.000454)
>>> >>>>>                     socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) =
>>> >>>>>                     33 <0.000296>
>>> >>>>>                     15:13:31.664760 (+     0.001048) getsockopt(33,
>>> >>>>>                     SOL_SOCKET, SO_SNDBUF, [163840], [4]) = 0
>>> >>>>>                     <0.000108>
>>> >>>>>                     15:13:31.665141 (+     0.000386) setsockopt(33,
>>> >>>>>                     SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1
>>> >>>>>                     EPERM (Operation not permitted) <0.000051>
>>> >>>>>                     15:13:31.665500 (+     0.000334) setsockopt(33,
>>> >>>>>                     SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
>>> <0.000229>
>>> >>>>>                     15:13:31.665973 (+     0.000468) sendmsg(33,
>>> >>>>>                     {msg_name={sa_family=AF_UNIX,
>>> >>>>>                     sun_path="/run/systemd/notify"},
>>> >>>>>                     msg_namelen=21,
>>> >>>>>                     msg_iov=[{iov_base="READY=1\nSTATUS=slapd
>>> >>>>>                     started: Re"..., iov_len=69}], msg_iovlen=1,
>>> >>>>>                     msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) =
>>> >>>>>                     69 <0.000600>
>>> >>>>>                     15:13:31.667270 (+     0.001334) close(33) = 0
>>> >>>>>                     <0.003140>
>>> >>>>>                     15:13:31.677320 (+     0.010146)
>>> >>>>>                     futex(0xb31122e8, FUTEX_WAIT, 32357, NULL) = ?
>>> >>>>>                     15:14:27.661809 (+    55.984448) +++ killed by
>>> >>>>>                     SIGSEGV (core dumped) +++
>>> >>>>>
>>> >>>>>                     On Mon, May 14, 2018 at 10:27 AM, thierry
>>> >>>>>                     bordaz <tbor...@redhat.com
>>> >>>>>                     <mailto:tbor...@redhat.com>> wrote:
>>> >>>>>
>>> >>>>>                         Hi Jonathan,
>>> >>>>>
>>> >>>>>                         This is weird as the crashing thread stack
>>> >>>>>                         looks truncated (did you copy/paste all of
>>> >>>>>                         it ?)
>>> >>>>>
>>> >>>>>                         Thread 1 (Thread 0x9e13c280 (LWP 17245)):
>>> >>>>>                         #0  0xb67bbf2e in strlen () at
>>> /lib/libc.so.6
>>> >>>>>                         #1  0xb6a06b40 in dosprintf () at
>>> >>>>>                         /lib/libnspr4.so
>>> >>>>>                         #2  0x00000000 in None ()
>>> >>>>>
>>> >>>>>                         Did you install 389-ds-base-debuginfo ?
>>> >>>>>                         How did you get that backtrace ? from a
>>> >>>>>                         core dumped, pstack ? Can you attach a
>>> >>>>>                         debugger before the crash occurs ?
>>> >>>>>
>>> >>>>>                         It looks it crashed soon at startup, could
>>> >>>>>                         it be related to a broken dse.ldif. It
>>> >>>>>                         should exists a dse.ldif.OK, is it possibly
>>> >>>>>                         to try to start with it ?
>>> >>>>>
>>> >>>>>                         best regards
>>> >>>>>                         thierry
>>> >>>>>
>>> >>>>>                         On 05/12/2018 01:22 AM, Jonathan Vaughn via
>>> >>>>>                         FreeIPA-users wrote:
>>> >>>>>>                         Not sure if it makes a difference... I was
>>> >>>>>>                         looking into this again and realized I had
>>> >>>>>>                         a bunch of messages from gdb telling me to
>>> >>>>>>                         install more debuginfo. I've done that
>>> >>>>>>                         now, here it is again freshly run through
>>> >>>>>>                         gdb
>>> >>>>>>
>>> >>>>>>                         GNU gdb (GDB) Fedora 8.0.1-36.fc27
>>> >>>>>>                         Copyright (C) 2017 Free Software
>>> >>>>>>                         Foundation, Inc.
>>> >>>>>>                         License GPLv3+: GNU GPL version 3 or later
>>> >>>>>>                         <http://gnu.org/licenses/gpl.html
>>> >>>>>>                         <http://gnu.org/licenses/gpl.html>>
>>> >>>>>>                         This is free software: you are free to
>>> >>>>>>                         change and redistribute it.
>>> >>>>>>                         There is NO WARRANTY, to the extent
>>> >>>>>>                         permitted by law.  Type "show copying"
>>> >>>>>>                         and "show warranty" for details.
>>> >>>>>>                         This GDB was configured as
>>> >>>>>>                         "armv7hl-redhat-linux-gnueabi".
>>> >>>>>>                         Type "show configuration" for
>>> >>>>>>                         configuration details.
>>> >>>>>>                         For bug reporting instructions, please
>>> see:
>>> >>>>>>                         <http://www.gnu.org/software/gdb/bugs/
>>> >>>>>>                         <http://www.gnu.org/software/gdb/bugs/>>.
>>> >>>>>>                         Find the GDB manual and other
>>> >>>>>>                         documentation resources online at:
>>> >>>>>>                         <http://www.gnu.org/software/
>>> gdb/documentation/
>>> >>>>>>                         <http://www.gnu.org/software/
>>> gdb/documentation/>>.
>>> >>>>>>                         For help, type "help".
>>> >>>>>>                         Type "apropos word" to search for commands
>>> >>>>>>                         related to "word"...
>>> >>>>>>                         Reading symbols from
>>> >>>>>>                         /usr/sbin/ns-slapd...Reading symbols from
>>> >>>>>>                         /usr/lib/debug/usr/sbin/ns-sl
>>> apd-1.3.7.10-1.fc27.arm.debug...done.
>>> >>>>>>                         done.
>>> >>>>>>                         ...
>>> >>>>>>
>>> >>>>>>                         Thread 1 (Thread 0x9e13c280 (LWP 17245)):
>>> >>>>>>                         #0  0xb67bbf2e in strlen () at
>>> /lib/libc.so.6
>>> >>>>>>                         #1  0xb6a06b40 in dosprintf () at
>>> >>>>>>                         /lib/libnspr4.so
>>> >>>>>>                         #2  0x00000000 in None ()
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>                             On Tue, May 8, 2018 at 7:52 AM, Rob
>>> >>>>>>                             Crittenden <rcrit...@redhat.com
>>> >>>>>>                             <mailto:rcrit...@redhat.com>> wrote:
>>> >>>>>>
>>> >>>>>>                                 Jonathan Vaughn via FreeIPA-users
>>> >>>>>>                                 wrote:
>>> >>>>>>
>>> >>>>>>                                     Still trying to figure this
>>> >>>>>>                                     out. It looks like slapd is
>>> >>>>>>                                     dying, I thought it was still
>>> >>>>>>                                     running for some reason.
>>> >>>>>>
>>> >>>>>>                                     slapd is dying to segfault.
>>> >>>>>>                                     strace of it happening doesn't
>>> >>>>>>                                     seem to reveal much:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>                                 A stack trace would very much help
>>> >>>>>>                                 trying to track down the cause.
>>> >>>>>>
>>> >>>>>>                                 http://directory.fedoraprojec
>>> t.org/docs/389ds/FAQ/faq.html#debugging-crashes
>>> >>>>>>                                 <http://directory.fedoraproje
>>> ct.org/docs/389ds/FAQ/faq.html#debugging-crashes>
>>> >>>>>>
>>> >>>>>>                                 rob
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>                                     18:32:41.543717 (+
>>> >>>>>>                                      0.000801) openat(AT_FDCWD,
>>> >>>>>>                                     "/var/run/dirsrv/slapd-COMPAN
>>> Y-INTERNAL.pid",
>>> >>>>>>                                     O_WRONLY|O_CREAT|O_TRUNC,
>>> >>>>>>                                     0666) = 32
>>> >>>>>>                                     18:32:41.544907 (+
>>> >>>>>>                                      0.001195) getpid() = 16014
>>> >>>>>>                                     18:32:41.545269 (+
>>> >>>>>>                                      0.000329) fstat64(32,
>>> >>>>>>                                     {st_mode=S_IFREG|0644,
>>> >>>>>>                                     st_size=0, ...}) = 0
>>> >>>>>>                                     18:32:41.545799 (+
>>> >>>>>>                                      0.000536) write(32,
>>> >>>>>>                                     "16014\n", 6) = 6
>>> >>>>>>                                     18:32:41.546603 (+
>>> >>>>>>                                      0.000818) close(32) = 0
>>> >>>>>>                                     18:32:41.547061 (+
>>> >>>>>>                                      0.000448)
>>> >>>>>>                                     chmod("/var/run/dirsrv/slapd-
>>> COMPANY-INTERNAL.pid",
>>> >>>>>>                                     0644) = 0
>>> >>>>>>                                     18:32:41.547741 (+
>>> >>>>>>                                      0.000676)
>>> >>>>>>                                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>>                                     {tv_sec=1525735961,
>>> >>>>>>                                     tv_nsec=548030641}) = 0
>>> >>>>>>                                     18:32:41.548324 (+
>>> >>>>>>                                      0.000587) write(2,
>>> >>>>>>                                     "[07/May/2018:18:32:41.548030
>>> 641
>>> >>>>>>                                     "..., 134) = 134
>>> >>>>>>                                     18:32:41.551096 (+
>>> >>>>>>                                      0.002840)
>>> >>>>>>                                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>>                                     {tv_sec=1525735961,
>>> >>>>>>                                     tv_nsec=551287555}) = 0
>>> >>>>>>                                     18:32:41.551568 (+
>>> >>>>>>                                      0.000406) write(4,
>>> >>>>>>                                     "[07/May/2018:18:32:41.551287
>>> 555
>>> >>>>>>                                     "..., 134) = 134
>>> >>>>>>                                     18:32:41.552360 (+
>>> >>>>>>                                      0.000811) fsync(4) = 0
>>> >>>>>>                                     18:32:41.558499 (+
>>> >>>>>>                                      0.006170)
>>> >>>>>>                                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>>                                     {tv_sec=1525735961,
>>> >>>>>>                                     tv_nsec=558678099}) = 0
>>> >>>>>>                                     18:32:41.558901 (+
>>> >>>>>>                                      0.000350) write(2,
>>> >>>>>>                                     "[07/May/2018:18:32:41.558678
>>> 099
>>> >>>>>>                                     "..., 136) = 136
>>> >>>>>>                                     18:32:41.561537 (+
>>> >>>>>>                                      0.002680)
>>> >>>>>>                                     clock_gettime(CLOCK_REALTIME,
>>> >>>>>>                                     {tv_sec=1525735961,
>>> >>>>>>                                     tv_nsec=561718659}) = 0
>>> >>>>>>                                     18:32:41.562357 (+
>>> >>>>>>                                      0.000793) write(4,
>>> >>>>>>                                     "[07/May/2018:18:32:41.561718
>>> 659
>>> >>>>>>                                     "..., 136) = 136
>>> >>>>>>                                     18:32:41.563293 (+
>>> >>>>>>                                      0.001148) fsync(4) = 0
>>> >>>>>>                                     18:32:41.566928 (+
>>> >>>>>>                                      0.003452) getpid() = 16014
>>> >>>>>>                                     18:32:41.567712 (+
>>> >>>>>>                                      0.000752) socket(AF_UNIX,
>>> >>>>>>                                     SOCK_DGRAM|SOCK_CLOEXEC, 0) =
>>> 32
>>> >>>>>>                                     18:32:41.568628 (+
>>> >>>>>>                                      0.000912) getsockopt(32,
>>> >>>>>>                                     SOL_SOCKET, SO_SNDBUF,
>>> >>>>>>                                     [163840], [4]) = 0
>>> >>>>>>                                     18:32:41.568972 (+
>>> >>>>>>                                      0.000319) setsockopt(32,
>>> >>>>>>                                     SOL_SOCKET, SO_SNDBUFFORCE,
>>> >>>>>>                                     [8388608], 4) = -1 EPERM
>>> >>>>>>                                     (Operation not permitted)
>>> >>>>>>                                     18:32:41.569548 (+
>>> >>>>>>                                      0.000589) setsockopt(32,
>>> >>>>>>                                     SOL_SOCKET, SO_SNDBUF,
>>> >>>>>>                                     [8388608], 4) = 0
>>> >>>>>>                                     18:32:41.570064 (+
>>> >>>>>>                                      0.000513) sendmsg(32,
>>> >>>>>>                                     {msg_name={sa_family=AF_UNIX,
>>> >>>>>>                                     sun_path="/run/systemd/notify
>>> "},
>>> >>>>>>                                     msg_namelen=21,
>>> >>>>>>                                     msg_iov=[{iov_base="READY=1\n
>>> STATUS=slapd
>>> >>>>>>                                     started: Re"..., iov_len=69}],
>>> >>>>>>                                     msg_iovlen=1,
>>> >>>>>>                                     msg_controllen=0,
>>> >>>>>>                                     msg_flags=0}, MSG_NOSIGNAL) =
>>> 69
>>> >>>>>>                                     18:32:41.570845 (+
>>> >>>>>>                                      0.000789) close(32) = 0
>>> >>>>>>                                     18:32:41.576358 (+
>>> >>>>>>                                      0.005575) futex(0xb30ed2e8,
>>> >>>>>>                                     FUTEX_WAIT, 16016, NULL) = ?
>>> >>>>>>                                     18:33:01.730774 (+
>>> >>>>>>                                     20.154428) +++ killed by
>>> >>>>>>                                     SIGSEGV +++
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>                 _______________________________________________
>>> >>>>                 FreeIPA-users mailing list --
>>> freeipa-users@lists.fedorahosted.org
>>> >>>>                 <mailto:freeipa-users@lists.fedorahosted.org>
>>> >>>>                 To unsubscribe send an email to
>>> freeipa-users-le...@lists.fedorahosted.org
>>> >>>>                 <mailto:freeipa-users-le...@lists.fedorahosted.org>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> > To unsubscribe send an email to freeipa-users-le...@lists.fedo
>>> rahosted.org
>>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> > List Guidelines: https://fedoraproject.org/wiki
>>> /Mailing_list_guidelines
>>> > List Archives: https://lists.fedoraproject.or
>>> g/archives/list/freeipa-users@lists.fedorahosted.org/message
>>> /NNFFJQTAJ2MG52U23V6QYOOAFL722JJL/
>>> >
>>>
>>>
>>
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/KY3B7AWC6EEIDT42BN3NT75TFB6A6LWR/

Reply via email to