On Sat, Jul 28, 2012 at 11:45:16PM -0500, C Anthony Risinger wrote: > On Sat, Jul 28, 2012 at 7:21 PM, Jorge Gallegos <[email protected]> wrote: > > > > Hi, > > > > I am using the below unit file to manage uwsgi in fedora (I maintain the > > fedora package, and am working on the systemd integration for f18): > > [...] > > > And I am so far getting two issues: > > > > 1) stopping/restarting the service throws puts it in "failed state", > > like so: > > [...] > > > The process appears as "failed" even tho I only did a systemctl stop. At > > first > > I thought it was because of the way uwsgi reacts to TERM, and so that's > > why I am using the --stop and --reload calls in the systemd unit file, > > but that made no difference. Should I use die-on-term instead? am I > > missing something? > > the problem here i think is due your your using an outside process to > kill/reload the service, this is neither necessary or ideal. > > ... remove `ExecStop` and replace with: > > KillSignal=SIGINT >
This part worked, however it still enters "failed" state. After looking at uwsgi.h I found this: #define UWSGI_RELOAD_CODE 17 #define UWSGI_END_CODE 30 #define UWSGI_EXILE_CODE 26 #define UWSGI_FAILED_APP_CODE 22 #define UWSGI_DE_HIJACKED_CODE 173 #define UWSGI_EXCEPTION_CODE 5 #define UWSGI_QUIET_CODE 29 So uwsgi actually exits with code 30, which is causing systemd to consider it a failure (because it's != 0). I realized that after sending a reload command and in the logs I could see it exited with status 17 just like above. By reading http://0pointer.de/public/systemd-man/systemd.service.html it seems systemd can't really understand exit codes other than 0: "If the first token is prefixed with - an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is ignored and considered success" This means that either I: a) ignore whatever status it may throw, success or otherwise (prefix with -) b) I put a hack in the system file like uwsgi --ini /etc/uwsgi.ini; [ $? -eq 30 ] I am not entirely comfortable with either one and I am not even sure b) works. Thoughts? > ... replace `ExecReload` with: > > ExecReload=/bin/kill -HUP $MAINPID > This part worked too > ... you don't even need pidfiles :-) they have never been reliable anyways. > > > 2) /var/log/messages gets a ton of these log lines: > > > > Jul 28 17:12:07 localhost systemd[1]: uwsgi.service: Got notification > > message from PID 4678, but reception only permitted for PID 4677 > > > > I assume is because the emperor is polling the location of the configs > > (in this case /etc/uwsgi.d) for new config files, but the way it is > > interacting with systemd doesn not quite match. I will probably change > > this to /var/log/uwsgi.log but wanted to know why this is happening. > > this one is possibly related to my comments above -- i'm not 100% sure > offhand -- might be a bug too, or some other misconfiguration. > > ... either way, if need be, it can likely be worked around by adding > > NotifyAccess=all > Adding this stopped the flood of messages in syslog > ... to the `uwsgi.service` file. > > -- > > C Anthony > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi -- ~kad - Mutt 1.5.21 (2010-09-15)
pgpF2B2QqqzaO.pgp
Description: PGP signature
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
