#264 upgrade needs better check for "server is running"
Closed: wontfix None Opened 10 years ago by rmeggins.

The upgrade scripts currently just look to see if the .pid file is present, and assume if that file is present the server is running. But under certain conditions, the .pid file is still there even when the server is down (old systemd implementation) - so the upgrade scripts need to test to see if the process id is still present.


To ssh://git.fedorahosted.org/git/389/ds.git
ba433f5..af1ef8e master -> master
commit changeset:af1ef8e/389-ds-base
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Jan 23 13:12:05 2012 -0700
Reviewed by: nhosoi (Thanks!)
Branch: master
Fix Description: The database upgrade tasks need the server to be offline,
and they need for the upgrade mode to be offline. These upgrade scripts
check for the presence of the .pid file. If the file is present, upgrade
assumes the server is running, and skips tasks that require the server to
be offline. However, under certain conditions (systemd) the .pid files
are left over even after the server is shutdown. This adds an explicit test
to see if the pid in the pidfile is running. Note that when pids are
recycled, we could still get a false positive - there could be another
process with the same pid. In this case, the user will have to manually
remove the .pid files and re-run setup-ds.pl -u.
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: no

reopening so that I can link this ticket to the existing bz

Added initial screened field value.

Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.2.10.a7

5 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/264

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)

2 years ago

Login to comment on this ticket.

Metadata