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

Question

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:            


        

Answer 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.

Answer 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

Answer 3

Looks like your shebang is not correct, instead of #!/bin/bash it should be #! /bin/sh

See: https://unix.stackexchange.com/questions/124566/how-to-debug-init-d-script-that-isnt-being-run

Answer 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

Answer 5

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.