Runit is running as a process on the host, why?

I’ve just run through the set up for Discourse on a VM that runs another service (MediaWiki) via Apache (a standards thing) on CentOS (another standards thing). After the successful run I end up with Nginx installed, which I expected but I also get runit:

# ps -ef|grep runsv
root     22910 22859  0 14:38 pts/0    00:00:00 /usr/bin/runsvdir -P /etc/service
root     22911 22910  0 14:38 ?        00:00:00 runsv cron
root     22912 22910  0 14:38 ?        00:00:00 runsv rsyslog
root     22913 22910  0 14:38 ?        00:00:00 runsv nginx
root     22914 22910  0 14:38 ?        00:00:00 runsv postgres
root     22915 22910  0 14:38 ?        00:00:00 runsv redis
root     22916 22910  0 14:38 ?        00:00:00 runsv unicorn

which is not installed on the host.

Is it possible to stop it? Or is it a feature of Docker?


1 Like

All process inside the Docker container appear to the outside host. It isn’t a VM.

Our image contains: runit, nginx, unicorn, sidekiq, postgresql, and a lot of stuff.


For the second time, as soon as I posted I found the answer. The confusing thing for me was because of the last I looked at this. It looked as though we couldn’t get nginx started via systemctl because it ^looked^ as though runit was restarting nginx before systemctl. I would kill it on the host and it would start again. Now, I know that I was killing nginx in the container and runit it was starting it, in the container, again.

The reason we couldn’t run systemctl successfully was because while nginx was configured correctly there was a stale socket in the shared directory.

It’s nice to understand this now. And, to boot, I have my two services running with Apache with Docker using one IP via TLS/SNI.

CivicCRM on Monday…

How do I mark this [understood] instead of [solved]? :slight_smile: