[
https://issues.apache.org/jira/browse/DIRSERVER-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1990:
-----------------------------------------
Component/s: installer
> Lock file named incorrectly on CentOS (& possibly others?)
> ----------------------------------------------------------
>
> Key: DIRSERVER-1990
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1990
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: installer
> Affects Versions: 2.0.0-M16
> Environment: CentOS 6.5
> Reporter: Brad Trantham
> Priority: Minor
>
> I was having trouble configuring my ApacheDS installation to auto-start when
> the server boots. During boot it would log an error saying that the default
> instance was already running but there was no ApacheDS process running and I
> was unable to connect to the LDAP instance.
> ApacheDS would start/stop with no problem when I ran it manually but it
> seemed like it wouldn't shut down cleanly during server shutdown, it was
> leaving the pid file in place which was preventing it from retstarting upon
> boot.
> After digging into various searches online I uncovered a suggestion that
> CentOS would not kill a process if the lock file was named something other
> than what the shutdown script in rc6.d was named. This was the case for me,
> the rc6.d script was called K35apacheds-2.0.0_M16-default but the lock file
> under /var/lock/subsys was simply called default.
> I fixed this for my installation by changing line 144 of
> /opt/apacheds-2.0.0_M16/bin/apachds from:
> LOCKFILE="$LOCKDIR/$INSTANCE"
> to
> LOCKFILE="$LOCKDIR/apacheds-2.0.0_M16-default"
> Obviously the real fix should be a bit cleaner than that but it worked and
> now my ApacheDS installation shuts down cleanly when the server is restarted
> and reliably starts up upon boot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
