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

AI-generated summary

The discussion revolves around a user, c3iq, finding the runit process running on their host after setting up Discourse on a VM with CentOS and Apache. Falco clarified that this is due to Docker, not a VM, and that all processes inside the container appear on the host.

c3iq later realized that runit was restarting nginx within the container, not on the host. The issue with systemctl not starting nginx successfully was due to a stale socket in the shared directory. With this understanding, c3iq was able to run their services with Apache using Docker and TLS/SNI.

Hello,
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?

Owen.

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:

Thanks.