Bug 430368

Summary: Running setup-ds.pl on Fedora 8 fails: Server failed to start !!! / Failed to open stats file
Product: [Retired] 389 Reporter: Kevin Goeser <kevin>
Component: Install/UninstallAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: high    
Version: 1.1.2CC: benl, gbarros, jgalipea, rmeggins, tom
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:02:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Attachments:
Description Flags
CVS Diffs none

Description Kevin Goeser 2008-01-26 23:41:35 UTC
Description of problem:
Running setup-ds.pl fails on a fresh Fedora 8 setup.

Steps to Reproduce:
1. Install F8 from DVD (keept the set-up quite minimal, server, no X etc.)
2. "yum update", add the directory server repositories, run "yum install 
fedora-ds"
3. run setup-ds.pl (tried express and standard mode)
4. After entering the Directory Manager password:
Directory Manager DN [cn=Directory Manager]:
Password:
Password (confirm):
Server failed to start !!! Please check errors log for problems

[root@dc ~]# tail /var/log/dirsrv/slapd-dc/errors
[24/Jan/2008:22:42:09 +0100] - line 91: collation sr "" "" 1 3  
2.16.840.1.113730.3.3.2.45.1    sr
[24/Jan/2008:22:42:09 +0100] - line 92: collation sv "" "" 1 3  
2.16.840.1.113730.3.3.2.46.1    sv
[24/Jan/2008:22:42:09 +0100] - line 93: collation tr "" "" 1 3  
2.16.840.1.113730.3.3.2.47.1    tr
[24/Jan/2008:22:42:09 +0100] - line 94: collation uk "" "" 1 3  
2.16.840.1.113730.3.3.2.48.1    uk
[24/Jan/2008:22:42:09 +0100] - line 95: collation zh "" "" 1 3  
2.16.840.1.113730.3.3.2.49.1    zh
[24/Jan/2008:22:42:09 +0100] - line 96: collation zh TW "" 1 3  
2.16.840.1.113730.3.3.2.50.1    zh-TW
[24/Jan/2008:22:42:09 +0100] - line 98: collation "" "" "" 3 3  
2.16.840.1.113730.3.3.2.0.3
[24/Jan/2008:22:42:09 +0100] - line 99: collation en "" "" 3 3  
2.16.840.1.113730.3.3.2.11.3
[24/Jan/2008:22:42:09 +0100] - h_name == dc.aristaflow.de
[24/Jan/2008:22:42:09 +0100] - Fedora-Directory/1.1.0 B2008.03.27 starting up
[root@dc ~]#


Trying to manually start the ns-slapd executable:
[root@dc dirsrv]# ns-slapd -D /etc/dirsrv/slapd-dc -d 64
.....
[24/Jan/2008:22:42:09 +0100] - line 98: collation "" "" "" 3 3  
2.16.840.1.113730.3.3.2.0.3
[24/Jan/2008:22:42:09 +0100] - line 99: collation en "" "" 3 3  
2.16.840.1.113730.3.3.2.11.3
[24/Jan/2008:22:42:09 +0100] - h_name == dc.aristaflow.de
[24/Jan/2008:22:42:09 +0100] - Fedora-Directory/1.1.0 B2008.03.27 starting up
Failed to open stats file (/var/run/dirsrv/slapd-dc.stats) (error 1).
[root@dc dirsrv]# 

The abovementioned file does not exist. However, creating the file manually 
(even with -rw-rw-rw-) leads to the same error message.

Comment 1 Kevin Goeser 2008-01-27 11:27:38 UTC
I did a fresh fedora install with the default options (installing things like 
X, Gnome, etc.) - and everything works like a charm.

There seems to be a missing dependency (does the directory server need X?!).

Comment 2 Rich Megginson 2008-02-28 04:11:12 UTC
I thought we moved the stats file from rundir?  We removed rundir from the spec
file, so it's not created during install.  The code still uses rundir:
int snmp_collator_start()
{

  int err;
  char *statspath = config_get_rundir();
...
  PR_snprintf(szStatsFile, sizeof(szStatsFile), "%s/%s%s",
              statspath, instname, AGT_STATS_EXTENSION);

And rundir by default is /var/run/dirsrv

It should work if you make sure /var/run/dirsrv exists before you install.

Comment 5 Guil Barros 2008-09-18 15:32:35 UTC
Quick update, permissions should be:
770, root:nobody

so this should fix it:
install -m 770 -g nobody -o root -d /var/run/dirsrv

Comment 7 Thomas Loran 2008-09-20 16:54:01 UTC
Confirmed that this still occurs in Fedora 9 x86_64 fresh fully patched  install  with X but stripped all "desktop"  packages.

fedora-ds-1.1.2-1.fc9.x86_64

when running setup-ds-admin.pl  I got

Are you ready to set up your servers? [yes]: 
Creating directory server . . .
Server failed to start !!! Please check errors log for problems

There was nothing in the any error log.  (/tmp/setupxxxxor or /var/log/dirsrv/xxxx)

I worked around the problem by "chown nobody /var/run/dirsrv/"

Then installation work perfectly.

Comment 8 Nathan Kinder 2008-12-13 16:45:49 UTC
Created attachment 326832 [details]
CVS Diffs

This patch adds a check at startup to see if the user ns-slapd is running as has read and write permissions on nsslapd-rundir.  A detailed error message is output if there is an access problem, which instructs the administrator how to fix it.

Comment 9 Nathan Kinder 2008-12-15 17:43:00 UTC
Checked into ldapserver (HEAD).  Thanks to Rich for his review!

Checking in ldap/servers/slapd/main.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/main.c,v  <--  main.c
new revision: 1.29; previous revision: 1.28
done

Comment 10 Jenny Severance 2009-03-17 14:40:24 UTC
Nathan isn't this a duplicate of 
https://bugzilla.redhat.com/show_bug.cgi?id=432135

Comment 11 Rich Megginson 2009-03-17 15:10:00 UTC
(In reply to comment #10)
> Nathan isn't this a duplicate of 
> https://bugzilla.redhat.com/show_bug.cgi?id=432135  

Not exactly.  430368 is because the RPM did not create /var/run/dirsrv with the correct permissions.

Comment 12 Jenny Severance 2009-03-17 18:58:08 UTC
fix verfied RHEL 5 and RHEL 4 DS 8.1

No error message setting up servers (Server failed to start !!! Please check errors log for problems)

permissions on /var/run/dirsrv/

drwxrwx---  2 nobody  nobody   4096 Mar 17 14:38 dirsrv

Comment 13 Chandrasekar Kannan 2009-04-29 23:02:14 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html