[DragonFlyBSD - Bug #2850] /var/run/sem does not exist nor is writeable -- openldap unstartable

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #2850 has been updated by swildner.


Ben, this is weird.

You write:

"Upon install of the dfly-x86_64-4.4.2_REL, I checked if /var/run/sem was specified after defining HAMMER for the SSD. It was not."

That after installing a fresh 4.4.2-RELEASE, the directory was not there for you?

I tested and did am install of 4.4.2-RELEASE in a virtual machine and the /var/run/sem directory was right there.

What could this be?

Certainly not an mtree or make upgrade issue. The directory should exist after installing 4.4.2 (even though we're on 4.4.3 already).

Sascha


----------------------------------------
Bug #2850: /var/run/sem does not exist nor is writeable -- openldap unstartable
http://bugs.dragonflybsd.org/issues/2850#change-12873

* Author: benjolitz
* Status: Closed
* Priority: Normal
* Assignee: dillon
* Category: Userland
* Target version: 
----------------------------------------
I spent the better part of two hours trying to make OpenLDAP slapd start up using the mdb backend.

Slapd would complain:

    56404f69 mdb_db_open: database "dc=telemuse,dc=net": dbenv_open(/var/db/openldap-data).
    56404f69 mdb_db_open: database "dc=telemuse,dc=net" cannot be opened: Invalid argument (22). Restore from backup!
    56404f69 backend_startup_one (type=mdb, suffix="dc=telemuse,dc=net"): bi_db_open failed! (22)

Using ktrace/kdump I found this:
    141609 slapd    GIO   fd 2 wrote 88 bytes
           "56404f69 mdb_db_open: database "dc=telemuse,dc=net": dbenv_open("
    141609 slapd    RET   write 88/0x58
    141609 slapd    CALL  mmap(0,0x101000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0)
    141609 slapd    RET   mmap 77860864/0x4a41000
    141609 slapd    CALL  mmap(0,0x201000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0)
    141609 slapd    RET   mmap 79101952/0x4b70000
    141609 slapd    CALL  mmap(0,0x10000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0)
    141609 slapd    RET   mmap 81203200/0x4d71000
    141609 slapd    CALL  munmap(0x804d80000,0x1000)
    141609 slapd    RET   munmap 0
    141609 slapd    CALL  mmap(0,0x10000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0,0)
    141609 slapd    RET   mmap 81264640/0x4d80000
    141609 slapd    CALL  munmap(0x804d71000,0xf000)
    141609 slapd    RET   munmap 0
    141609 slapd    CALL  open(0x800896500,O_RDWR|O_CREAT|O_CLOEXEC,S_IRUSR|S_IWUSR)
    141609 slapd    NAMI  "/var/db/openldap-data/lock.mdb"
    141609 slapd    RET   open 8
    141609 slapd    CALL  fcntl(0x8,F_SETLK,0xfffffffffffff040)
    141609 slapd    RET   fcntl 0
    141609 slapd    CALL  lseek(0x8,0,0,SEEK_END)
    141609 slapd    RET   lseek 8192/0x2000
    141609 slapd    CALL  mmap(0,0x2000,PROT_READ|PROT_WRITE,MAP_SHARED,0x8,0,0)
    141609 slapd    RET   mmap 9932800/0x979000
    141609 slapd    CALL  fstat(0x8,0x7ffffffff090)
    141609 slapd    RET   fstat 0
    141609 slapd    CALL  unlink(0x7fffffffec60)
    141609 slapd    NAMI  "/var/run/sem/MDBrWwwoS_=F1x"
    141609 slapd    RET   unlink -1 errno 2 No such file or directory


Reading https://www.dragonflybsd.org/cgi/web-man?command=sem_open&section=3 indicated that this may be something broken with how sem_open is implemented (where else would /var/run/sem ever appear?)

When I set LIBTHREAD_SEM_PREFIX to /tmp, slapd worked.

Therefore, I deduced a possible solution to be:

    mkdir -p /var/run/sem
    chmod 1777 /var/run/sem

Packages affected by this "fun" error:

net/openldap24-server

... and anyone else who dares use or indirectly calls sem_open().

I would normally consider this a show-stopper bug, but I'll leave that to the experts.

It was not fun to diagnose.




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account