Bug 1357682

Need info to update customer. 

As per the recent work-flow we should not send any template response on the case without contacting Engineering team for exact status and update. 

Can someone let me know any recent update on this bugzilla ? When this case will be assigned ? Any ETA ?

I am getting this error -
==========================

Directory Manager DN [cn=Directory Manager]: 
Password: 
Password (confirm): 
/usr/bin/pwdhash-bin: error while loading shared libraries: libslapd.so.0: cannot open shared object file: No such file or directory
Could not import LDIF file '/tmp/ldifaC9BGA.ldif'.  Error: 32512.  Output: importing data ...
/usr/sbin/ns-slapd: error while loading shared libraries: libnunc-stans.so.0: cannot open shared object file: No such file or directory

Error: Could not create directory server instance 'test'.
Exiting . . .
Log file is '/tmp/setupOY4Gh7.log'

NOTE - this is only on one test machine that I hit this error and I tried re-installing 389 RPMs but error does not go away. I have the test machine, if that is needed.

[05/May/2017:10:34:57.620062305 +0200] - EMERG - snmp_collator_create_semaphore - Failed to delete old semaphore for stats file (/slapd-rhel7ds.stats). Error 13 (Permission denied).

Path is still wrong, marking as ASSIGNED.

It looks like there are two issues here.

The first is the incorrect libraries that Amita is seeing. Can you give us access to the machine? I think that there is something odd going on here. If it's repeatable, mreynolds may know more as he did the packaging lately. 

The second is the error that Viktor is seeing. I'm a bit confused about this, so let me have another look at the code.

okay, here is the code:

###
    /* First just try to create the semaphore.  This should usually just work. */
    if ((stats_sem = sem_open(stats_sem_name, O_CREAT | O_EXCL, SLAPD_DEFAULT_FILE_MODE, 1)) == SEM_FAILED) {
        if (errno == EEXIST) {
            /* It appears that we didn't exit cleanly last time and left the semaphore
             * around.  Recreate it since we don't know what state it is in. */
            if (sem_unlink(stats_sem_name) != 0) {
                slapi_log_err(SLAPI_LOG_EMERG, "snmp_collator_create_semaphore",
                        "Failed to delete old semaphore for stats file (%s). "
                        "Error %d (%s).\n", stats_sem_name, errno, slapd_system_strerror(errno) );
                exit(1);
            }

###

So perhaps I made a mistake here. sem_open takes a semaphore *name*, not a path. Looking at the man page it says:

       Named semaphores
              A named semaphore is identified by a name of the form /somename; that is, a null-terminated string of up to NAME_MAX-4 (i.e., 251) characters consisting of an initial slash, followed  by  one
              or more characters, none of which are slashes.  Two processes can operate on the same named semaphore by passing the same name to sem_open(3).

AND

   Accessing named semaphores via the file system
       On  Linux,  named  semaphores  are  created  in  a virtual file system, normally mounted under /dev/shm, with names of the form sem.somename.  (This is the reason that semaphore names are limited to
       NAME_MAX-4 rather than NAME_MAX characters.)

So the error message is now indeed wrong as I made a mistake in the reading of the api. 

I'll reopen https://pagure.io/389-ds-base/issue/48538 and fix this.

Created attachment 1278051 [details]
patch for issue.

Pagure is exploding right now, so here is the patch to review.

Now the error message points to
/dev/shm/slapd-master_1.stats

while the actual file name is (note the "sem." prefix):
/dev/shm/sem.slapd-master_1.stats

[root@qeos-37 upstream]# rpm -qa | grep 389
389-ds-base-libs-1.3.6.1-15.el7.x86_64
389-ds-base-1.3.6.1-15.el7.x86_64
389-ds-base-snmp-1.3.6.1-15.el7.x86_64
389-ds-base-debuginfo-1.3.6.1-15.el7.x86_64


[root@qeos-37 upstream]# systemctl stop dirsrv@qeos-37
[root@qeos-37 upstream]# touch /dev/shm/sem.slapd-qeos-37.stats
[root@qeos-37 upstream]# systemctl start dirsrv@qeos-37
Job for dirsrv failed because the control process exited with error code. See "systemctl status dirsrv" and "journalctl -xe" for details.

Logs -
[30/May/2017:05:36:30.789082275 -0400] - INFO - main - slapd stopped.
[30/May/2017:05:37:22.820057668 -0400] - INFO - main - 389-Directory/1.3.6.1 B2017.143.155 starting up
[30/May/2017:05:37:22.821701509 -0400] - EMERG - snmp_collator_create_semaphore - Failed to delete old semaphore for stats file (/dev/shm/sem.slapd-qeos-37.stats). Error 13 (Permission denied).
[30/May/2017:05:38:37.519273936 -0400] - INFO - main - 389-Directory/1.3.6.1 B2017.143.155 starting up
[30/May/2017:05:38:37.520886181 -0400] - EMERG - snmp_collator_create_semaphore - Failed to delete old semaphore for stats file (/dev/shm/sem.slapd-qeos-37.stats). Error 13 (Permission denied).

[root@qeos-37 upstream]# rm -rf /dev/shm/sem.slapd-qeos-37.stats
[root@qeos-37 upstream]# /usr/lib64/dirsrv/slapd-qeos-37/start-slapd 
[root@qeos-37 upstream]#

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2086