Page MenuHomePhabricator

service::uwsgi should mask uwsgi.service
Open, MediumPublic

Description

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:

  • uwsgi-striker.service
  • uwsgi-ores.service
  • uwsgi-netbox.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?