#583 dirsrv fails to start on reboot due to /var/run/dirsrv permissions
Closed: wontfix None Opened 11 years ago by rmeggins.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 857939

Description of problem:

/var/log/dirsrv/slapd-myhost/errors  contains:

[17/Sep/2012:05:09:24 -0400] - Unable to access nsslapd-rundir: Permission
denied
[17/Sep/2012:05:09:24 -0400] - Ensure that user "dirsrv" has read and write
permissions on /var/run/dirsrv
[17/Sep/2012:05:09:24 -0400] - Shutting down.


This dirsrv is running as dirsrv:dirsrv , but I was getting the same problem
with the default nobody:nobody.

I can't change permissions on /var/run/dirsrv because something (what?) during
the boot process always resets the ownershio to root:root 770



Version-Release number of selected component (if applicable):
389-ds-1.2.2-2.fc17.noarch


How reproducible:
100%

Steps to Reproduce:
1. reboot
2.
3.

Actual results:
fails to start due to permissions...

Expected results:
dirsrv shoudl start without intervention after reboot.

Additional info:

git merge ticket583
Updating 5a5ff26..febd0db
Fast-forward
ldap/admin/src/scripts/DSCreate.pm.in | 80 +++++++++++++++++----------------
1 files changed, 41 insertions(+), 39 deletions(-)

git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 1.23 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
5a5ff26..febd0db master -> master

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/583

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

4 years ago

Log in to comment on this ticket.

Metadata