Project

General

Profile

Actions

Bug #2850

closed

/var/run/sem does not exist nor is writeable -- openldap unstartable

Added by Anonymous over 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Userland
Target version:
-
Start date:
11/08/2015
Due date:
% Done:

0%

Estimated time:

Description

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.

Actions #1

Updated by Anonymous over 8 years ago

  • Category set to Userland
Actions #2

Updated by dillon over 8 years ago

  • Assignee set to dillon

Ok, I went through and did some tests. The normal buildworld and installworld sequence for upgrading a system will create /var/run/sem and chmod it 1777 if it does not already exist. So it should have existed on your machine. I'm not sure why it didn't. It is possible that your last installworld was run before the change was made to the installworld target to properly create the directory.

-Matt

Actions #3

Updated by Anonymous over 8 years ago

This install was made several months ago from a USB boot image onto a a PCIE SSD, if that helps narrow down.

One thing that would have made this easier to debug would be if sem_open() had written a warning to the syslog that a vital path (/var/run/sem or whatever LIBTHREAD_SEM_PREFIX points to) doesn't exist.

I believe I can get the exact date for the install image I used if that would confirm the issue

Actions #4

Updated by Anonymous almost 8 years ago

benjolitz wrote:

This install was made several months ago from a USB boot image onto a a PCIE SSD, if that helps narrow down.

One thing that would have made this easier to debug would be if sem_open() had written a warning to the syslog that a vital path (/var/run/sem or whatever LIBTHREAD_SEM_PREFIX points to) doesn't exist.

I believe I can get the exact date for the install image I used if that would confirm the issue

Hi, I made a new install due to an mSSD failure.

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.

Upon a `make buildworld installworld`, the missing directory appeared.

Actions #5

Updated by dillon almost 8 years ago

  • Status changed from New to Closed

What I've done is adjust the 'make upgrade' target to make sure that this directory is created. People normally run make upgrade after doing a make installworld when upgrading an existing system in-place. So new installs are covered by the normal installworld, and updating an existing install will be covered by this change.

-Matt

Actions #6

Updated by swildner almost 8 years ago

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

Actions

Also available in: Atom PDF