Managing external daemons/services

uWSGI can easily monitor external processes, allowing you to increasereliability and usability of your multi-tier apps. For example you can manageservices like Memcached, Redis, Celery, Ruby delayed_job or even dedicatedPostgreSQL instances.

Kinds of services

Currently uWSGI supports 3 categories of processes:

  • —attach-daemon – directly attached non daemonized processes
  • —smart-attach-daemon – pidfile governed (both foreground and daemonized)
  • —smart-attach-daemon2 – pidfile governed with daemonization management

The first category allows you to directly attach processes to the uWSGI master.When the master dies or is reloaded these processes are destroyed. This is thebest choice for services that must be flushed whenever the app is restarted.

Pidfile governed processes can survive death or reload of the master so long astheir pidfiles are available and the pid contained therein matches a runningpid. This is the best choice for processes requiring longer persistence, andfor which a brutal kill could mean loss of data such as a database.

The last category is a superset of the second one. If your process does notsupport daemonization or writing to pidfile, you can let the master do themanagement. Very few daemons/applications require this feature, but it couldbe useful for tiny prototype applications or simply poorly designed ones.

Since uWSGI 2.0 a fourth option, —attach-daemon2 has been added for advanced configurations (see below).

Examples

Managing a memcached instance in ‘dumb’ mode. Whenever uWSGI is stopped or reloaded, memcached is destroyed.

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. attach-daemon = memcached -p 11311 -u roberto

Managing a memcached instance in ‘smart’ mode. Memcached survives uWSGI stop and reload.

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. smart-attach-daemon = /tmp/memcached.pid memcached -p 11311 -d -P /tmp/memcached.pid -u roberto

Managing 2 mongodb instances in smart mode:

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. smart-attach-daemon = /tmp/mongo1.pid mongod --pidfilepath /tmp/mongo1.pid --dbpath foo1 --port 50001
  5. smart-attach-daemon = /tmp/mongo2.pid mongod --pidfilepath /tmp/mongo2.pid --dbpath foo2 --port 50002

Managing PostgreSQL dedicated-instance (cluster in /db/foobar1):

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. smart-attach-daemon = /db/foobar1/postmaster.pid /usr/lib/postgresql/9.1/bin/postgres -D /db/foobar1

Managing celery:

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. smart-attach-daemon = /tmp/celery.pid celery -A tasks worker --pidfile=/tmp/celery.pid

Managing delayed_job:

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. env = RAILS_ENV=production
  5. rbrequire = bundler/setup
  6. rack = config.ru
  7. chdir = /var/apps/foobar
  8. smart-attach-daemon = %(chdir)/tmp/pids/delayed_job.pid %(chdir)/script/delayed_job start

Managing dropbear:

  1. [uwsgi]
  2. namespace = /ns/001/:testns
  3. namespace-keep-mount = /dev/pts
  4. socket = :3031
  5. exec-as-root = chown -R www-data /etc/dropbear
  6. attach-daemon = /usr/sbin/dropbear -j -k -p 1022 -E -F -I 300

When using the namespace option you can attach a dropbear daemon to allow directaccess to the system inside the specified namespace. This requires the/dev/pts filesystem to be mounted inside the namespace, and the user yourworkers will be running as have access to the /etc/dropbear directory insidethe namespace.

Legion support

Starting with uWSGI 1.9.9 it’s possible to use the The uWSGI Legion subsystem subsystem fordaemon management. Legion daemons will be executed only on the legionlord node, so there will always be a single daemon instance running in eachlegion. Once the lord dies a daemon will be spawned on another node. To add alegion daemon use –legion-attach-daemon, –legion-smart-attach-daemon and–legion-smart-attach-daemon2 options, they have the same syntax as normaldaemon options. The difference is the need to add legion name as firstargument.

Example:

Managing celery beat:

  1. [uwsgi]
  2. master = true
  3. socket = :3031
  4. legion-mcast = mylegion 225.1.1.1:9191 90 bf-cbc:mysecret
  5. legion-smart-attach-daemon = mylegion /tmp/celery-beat.pid celery beat --pidfile=/tmp/celery-beat.pid

—attach-daemon2

This option has been added in uWSGI 2.0 and allows advanced configurations. It is a keyval option, and it accepts the following keys:

  • command/cmd/exec: the command line to execute
  • freq: maximum attempts before considering a daemon “broken”
  • pidfile: the pidfile to check (enable smart mode)
  • control: if set, the daemon becomes a ‘control’ one: if it dies the whole uWSGI instance dies
  • daemonize/daemon: daemonize the process (enable smart2 mode)
  • touch semicolon separated list of files to check: whenever they are ‘touched’, the daemon is restarted
  • stopsignal/stop_signal: the signal number to send to the daemon when uWSGI is stopped
  • reloadsignal/reload_signal: the signal to send to the daemon when uWSGI is reloaded
  • stdin: if set the file descriptor zero is not remapped to /dev/null
  • uid: drop privileges to the specified uid (requires master running as root)
  • gid: drop privileges to the specified gid (requires master running as root)
  • ns_pid: spawn the process in a new pid namespace (requires master running as root, Linux only)
  • chdir: chdir() to the specified directory before running the command (added in uWSGI 2.0.6)

Example:

  1. [uwsgi]
  2. attach-daemon2 = cmd=my_daemon.sh,pidfile=/tmp/my.pid,uid=33,gid=33,stopsignal=3