Hi! I see your point about churn in uwsgi, and maybe it's not the right time right now, but I do think in the long run that Emperor watching a directory is actually a bit more friendly than the impressive init scripting since you can read up on how it works on the uwsgi page and tutorials on the web and since you get a single process to monitor (it will look after all the others).
Anyway, I'm running systemd, and since I wasn't sure how the init script in the .deb would fare with that, I disabled it and instead created a systemd unit file (the only tricky part was creating /run/uwsgi/): [Unit] Description=uWSGI Emperor After=syslog.target [Service] ExecStartPre=/bin/mkdir -p /run/uwsgi ExecStartPre=/bin/chown www-data:www-data /run/uwsgi ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi/emperor.ini Restart=always Type=notify StandardError=syslog NotifyAccess=main [Install] WantedBy=multi-user.target Then put the following in /etc/uwsgi/emperor.ini [uwsgi] emperor = /etc/uwsgi/vassals uid = www-data gid = www-data then added .ini files to /etc/uwsgi/vassals/. These can contain patterns so I simply did socket = /run/uwsgi/%n.sock logto = /var/log/uwsgi/%n.log For a package it's probably better to define these in an ini file and import them with vassals-inherit http://projects.unbit.it/uwsgi/wiki/CustomOptions In summary, it looks to me as if you can relatively easily set this up so it's really straightforward, no magic and easy to customize. The init script could for instance refer to /etc/uwsgi/uwsgi.ini that could be a symlink to emperor.ini so people can override that and configure a single instance if they so wish. Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
