1

I run a python application on FreeBSD that uses PostgreSQL, Nginx, and UWSGI. UWSGI I manage with SupervisorD. My /etc/rc.conf looks like this:

...
postgresql_enable="YES"
nginx_enable="YES"
supervisord_enable="YES"

SupervisorD starts a couple different UWSGI processes, but their config files all pretty much look like this:

[program:uwsgi]
command=/usr/local/bin/uwsgi --ini /opt/site/uwsgi/site.ini
autostart=True
autorestart=True
user=example
stopsignal=INT
redirect_stderr=True
stdout_logfile=/opt/site/log/uwsgi.log
stdout_logfile_maxbyte=5MB
stdout_logfile_backups=10
priority=300

Everything starts properly. However, I ran into a problem where when the server reboots, SupervisorD started UWSGI before PostgreSQL was finished starting up, which caused an error.

Is there a way I can make sure that my UWSGI processes do not start until PostgreSQL is brought up fully?

If it is easier to ignore UWSGI and somehow tell FreeBSD to not even start SupervisorD until PostgreSQL is ready, I'm fine with that. Or should I somehow start managing PostgreSQL with SupervisorD, and handle everything within that?

Daywalker
  • 485
  • 5
  • 25
rainsurf
  • 11
  • 1
  • PostgreeSQL became ready with some delay after start so order of daemons start SupervisorD and PostgreeSQL doesn't matter in this case. If WAL is applied after crash this delay can be very big (minutes or even hours). – citrin Aug 20 '16 at 18:18

2 Answers2

2

Take a look at:

# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*

This will show you the order in which the scripts are run. As i Understood, all scripts are started in parallel. juist theyr dependencies are started in advance.

The keyword that starts a Service prior to another one (for example in the rc script of inetd) is

# PROVIDE: inetd
# REQUIRE: DAEMON LOGIN FILESYSTEMS

(or in rc script of samba)

# PROVIDE: samba_server
# REQUIRE: NETWORKING SERVERS DAEMON ldconfig resolv ntpd
# BEFORE: LOGIN

Just put in all necessary rc scripts that need to be started before your service.

From the Handbook:

Keep in mind that putting a service name in the REQUIRE: line does not guarantee that the service will actually be running by the time our script starts. The required service may fail to start or just be disabled in rc.conf(5). Obviously, rcorder(8) cannot track such details, and rc(8) will not do that either. Consequently, the application started by our script should be able to cope with any required services being unavailable. In certain cases, we can help it as discussed below.

Finlay the link to the FreeBSD handbooks chapter on that topic: https://www.freebsd.org/doc/en/articles/rc-scripting/rcng-hookup.html

Daywalker
  • 485
  • 5
  • 25
0

As mentioned by Daywalker you have to add some special rc.d script:

# PROVIDE: MYORDER001
# REQUIRE: postgresql
# BEFORE: nginx supervisord exim dovecot ...

When rc start the system, all rc scripts are analysed to build the non-conflicting sequence of launch. You can list that sequence by

# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*

Keep in mind that this isn't an ultimate sequence but just first non-conflicting one been found. When you add MYORDER001, rcorder can build another appropriate sequence that ensure that postgresql will be started before MYORDER001 and listed as BEFORE - after it.

You can add as many ordering scripts as you wish, for example you can force dovecot to be started before exim if you have used dovecot-auth from the exim:

# PROVIDE: MYORDER002
# REQUIRE: dovecot
# BEFORE: exim 

Then you can be sure that postgresql precede both dovecot and exim, and dovecot precede exim.

The only requirement is to run

# rcorder /etc/rc.d/* /usr/local/etc/rc.d/*

each time you have modified your rc scripts to ensure that there is no conflicts in the precedence and rcorder can build the proper sequence.

P.S. Please accept Daywalker's solution not mine.

Kondybas
  • 6,864
  • 2
  • 19
  • 24
  • Why do you want my answer to be accepted and not yours, as yours seems to be more complete (and not written in the middle of the night with only one eye open and a lot of spelling mistakes) :) But thank you for that ;) – Daywalker Aug 23 '16 at 20:35
  • Your answer was first and it is correct. I've just added some details. – Kondybas Aug 24 '16 at 10:05