Bug #2850
closed
/var/run/sem does not exist nor is writeable -- openldap unstartable
0%
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§ion=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/semPackages 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.
Updated by dillon about 9 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
Updated by Anonymous about 9 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
Updated by Anonymous over 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.
Updated by dillon over 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
Updated by swildner over 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