Luca identified a segfault in uwsgi and when deploying the fixed package, this resulted in a failed dpkg state:
The uwsgi package ships a postinst which does
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then if [ -x "/etc/init.d/uwsgi" ]; then update-rc.d uwsgi defaults >/dev/null invoke-rc.d uwsgi start || exit $? fi fi
As the package also ships a sysvinit file, that sysvinit script is translated to a systemd unit by the systemd-sysv-generator:
[Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/uwsgi Description=LSB: Start/stop uWSGI server instance(s) After=remote-fs.target After=network-online.target Wants=network-online.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6 ExecStart=/etc/init.d/uwsgi start ExecStop=/etc/init.d/uwsgi stop ExecReload=/etc/init.d/uwsgi reload
As such, the next time uwsgi is upgraded after the initial installation (as it will e.g. happen for the next security update or when Luca's fix gets backported to the Debian 9.10 point release, the postinst started by dpkg attempts to start a dysfunctional service and we're running into a failed dpkg state and a failed service for uwsgi.service.
The fix is to mask the default uwsgi.service. We actually have deployed this fix seperately before for Striker and ORES. I had a systematic look at all of our uses of uwsgi:
These services currently have an exec in their puppet code to mask uwsgi.service:
These are using uwsgi and will fail the same way the next time uwsgi is updated:
I can't think of a use case where service::uwsgi is used, but the core uwsgi.service is still relevant, so unless I'm missing something we should simply mask uwsgi.service in service::uwsgi and fix this for good?