| Summary: | deltacloud fails to start via aeolus on rhel6.1 | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> |
| Component: | aeolus-configure | Assignee: | Mike Orazi <morazi> |
| Status: | CLOSED ERRATA | QA Contact: | wes hayutin <whayutin> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.0.0 | CC: | akarol, clalance, dajohnso, deltacloud-maint, dgao, mfojtik, ssachdev |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-15 20:39:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
wes hayutin
2011-10-04 12:36:23 UTC
The 'no acceptor' error means that the port you want to run Deltacloud API on is already occupied by something else (another DC instance?). The '/usr/lib/ruby/gems/1.8/gems/thin-1.2.5/lib/thin/runner.rb:163:in `chdir': Permission denied - /root (Errno::EACCES)' is more weird, since it try to cd into the /root directory. My 50cents that you're trying to run DC as the 'root' user, which obviously is not correct. Sure.. running as root is a bad thing.. but as a user we're not setting this up. aeolus-configure is. aeolus-configure is just running the service via init. It appears to try to run as $DELTACLOUD_USER or nobody in there. #!/bin/sh
#
# deltacloud-core Deltacloud API Core
# chkconfig: 345 90 60
# description: deltacloud-core is primary server process for the \
# Deltacloud Core component.
### BEGIN INIT INFO
# Provides: deltacloud-core
# Required-Start:
# Required-Stop:
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Short-Description: Deltacloud Core API deamon
# Description: Deltacloud Core API provides access to different cloud providers \
# using single REST API
### END INIT INFO
. /etc/rc.d/init.d/functions
[ -r /etc/sysconfig/deltacloud-core ] && . /etc/sysconfig/deltacloud-core
exec="/usr/bin/deltacloudd"
prog="deltacloud-core"
[ ! -d /var/log/$prog ] && mkdir -p /var/log/$prog
# You can overide these variables using /etc/sysconfig/deltacloud-core
API_ENV="${API_ENV:-production}"
DRIVER="${DRIVER:-mock}"
PORT="${PORT:-3002}"
HOST="${HOST:-localhost}"
DELTACLOUD_USER="${DELTACLOUD_USER:-nobody}"
LOGFILE="${LOGFILE:-/var/log/$prog/$DRIVER.log}"
LOCKFILE="${LOCKFILE:-/var/lock/subsys/$prog}"
[ -r $LOGFILE ] && chown nobody $LOGFILE
[ -r $LOCKFILE ] && chown nobody $LOCKFILE
start() {
[ -x $exec ] || exit 5
echo -n $"Starting $prog: "
daemon --user "$DELTACLOUD_USER" "$exec -i $DRIVER -e $API_ENV --port $PORT -r $HOST >> $LOGFILE 2>&1 &"
retval=$?
if [ $retval -eq 0 ] && touch $LOCKFILE ; then
echo_success
echo
else
echo_failure
echo
fi
return $retval
}
stop() {
echo -n $"Shutting down $prog: "
killproc deltacloudd
retval=$?
if [ $retval -eq 0 ] && rm -f $LOCKFILE ; then
echo_success
echo
else
echo_failure
echo
fi
return $retval
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
reload)
;;
force-reload)
restart
;;
status)
status -p $PIDFILE $prog
retval=$?
;;
*)
echo "Usage: $prog {start|stop|restart|status}"
exit 1
;;
esac
exit $retval
[root@hp-dl2x170g6-02 ~]#
OK, so the next possible reason for this is just old thin. The version 1.2.5 which is shipped in EPEL sounds pretty old (1.2.11 in Fedora now). I'll try to update the gem tomorrow. Meanwhile please could you try to manually install 'thin' gem (gem install thin) just to test if this helps? Actually I think we figured this one out. By default, thin tries to start in Dir.pwd. If you launch the initscript as root, then this is typically /root. However, prior to launching thin we also transition to nobody:nobody. So what this means is that a process as nobody:nobody tries to cd to /root, and it fails. This works in the systemd case because systemd starts the process with a clean environment, in /, by default. I fixed it by adding an explicit cd / in the initscript, which fixes the issue. verified in 0.4.0 build taking off tracker 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. http://rhn.redhat.com/errata/RHEA-2012-0586.html |