Docker.io init.d script not working on start container

问题

I've a container with odoo on it on the dir "/opt/odoo/".

A init script on "/etc/init.d/odoo-server"

#!/bin/bash
### BEGIN INIT INFO
# Provides:          odoo
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start openerp daemon at boot time
# Description:       Enable service provided by daemon.
# X-Interactive:     true
### END INIT INFO
## more info: http://wiki.debian.org/LSBInitScripts

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
DAEMON=/opt/odoo/openerp-server
NAME=odoo
DESC=odoo
CONFIG=/etc/odoo-server.conf
LOGFILE=/var/log/odoo/odoo-server.log
PIDFILE=/var/run/${NAME}.pid
USER=odoo
export LOGNAME=$USER

test -x $DAEMON || exit 0
set -e

function _start() {
    start-stop-daemon --start --quiet --pidfile $PIDFILE --chuid $USER:$USER --background --make-pidfile --exec $DAEMON -- --config $CONFIG --logfile $LOGFILE
}

function _stop() {
    start-stop-daemon --stop --quiet --pidfile $PIDFILE --oknodo --retry 3
    rm -f $PIDFILE
}

function _status() {
    start-stop-daemon --status --quiet --pidfile $PIDFILE
    return $?
}


case "$1" in
        start)
                echo -n "Starting $DESC: "
                _start
                echo "ok"
                ;;
        stop)
                echo -n "Stopping $DESC: "
                _stop
                echo "ok"
                ;;
        restart|force-reload)
                echo -n "Restarting $DESC: "
                _stop
                sleep 1
                _start
                echo "ok"
             ;;
        status)
                echo -n "Status of $DESC: "
                _status && echo "running" || echo "stopped"
                ;;
        *)
                N=/etc/init.d/$NAME
                echo "Usage: $N {start|stop|restart|force-reload|status}" >&2
                exit 1
                ;;
esac

exit 0

then I do

root@cca438c81a87:/# update-rc.d odoo-server defaults
 Adding system startup for /etc/init.d/odoo-server ...
   /etc/rc0.d/K20odoo-server -> ../init.d/odoo-server
   /etc/rc1.d/K20odoo-server -> ../init.d/odoo-server
   /etc/rc6.d/K20odoo-server -> ../init.d/odoo-server
   /etc/rc2.d/S20odoo-server -> ../init.d/odoo-server
   /etc/rc3.d/S20odoo-server -> ../init.d/odoo-server
   /etc/rc4.d/S20odoo-server -> ../init.d/odoo-server
   /etc/rc5.d/S20odoo-server -> ../init.d/odoo-server

When I start the docker with docker start the odoo-server doesn't start, when I run inside the docker /etc/init.d/odoo-server start it work ok...

what is happening?

回答1:

Docker containers typically do not have a functioning init system. If you are simply running a single service -- just start that.

If you need something more complex, look at supervisord or runit.

Containers are not virtual machines.

回答2:

If you're looking for a Docker image that behaves much like a full blown VM with init system, take a look at phusion baseimage

回答3:

Now I tracked down the bug in some hours of work.

The reason of the problem that start-stop-daemon, the main daemon starter/tester/stopper tool of the debian system, checks the existence of a daemon by examining the virtual soft link of the daemon process in /proc/<pid>/exe (it should point to the binary image of the process started).

Now the problem is, that in docker, this soft link simply won't work by default. It is because docker has to use strict security policies in the default install (it is used mainly to run unidentified software).

There are many workarounds for the task, some needs to change the privilege settings of a container, some doesn't. Two examples:

You change your init scripts to not use start-stop-daemon with both the --test and --exec flags
You start your docker containers by giving --cap-add=SYS_ADMIN option to the docker run command (don't worry, it doesn't give your docker container any sysadm privileges, it is probably only a precaution for productive usage)

Next to these, also systemd doesn't work in docker, although it is probably more a disadvantage of the systemd, as of the docker. Instead of the systemd, upstart is usable.

P.s.: docker developers/advocates often say, "containers are not VMs" and similar. But, the in the everyday experience, there is no so really strong distinction between the two, and for a productive docker usage of the software, at least a minimal support of a VPS-like function would be surely useful. Hopefully also the docker development will focus their efforts in this direction in the near future.

回答4:

I found that the service not starting is because of the /usr/sbin/policy-rc.d returns a 101 code:

See: http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

And docker set it to return 101 in a container.

So, change that script on build will work, you can make a build.sh to run in Dockerfile and runs the below script:

cat << EOF > /usr/sbin/policy-rc.d
#!/bin/sh

# For most Docker users, "apt-get install" only happens during "docker build",
# where starting services doesn't work and often fails in humorous ways. This
# prevents those failures by stopping the services from attempting to start.

# exit 101
exit 0
EOF