reopen 736258 severity 736258 grave retitle 736258 invoke-rc.d: stop action fails to disable socket activation reassign 736258 systemd thanks
Bug severity raised and reassignment to systemd done in response to Michael Biebl's analysis of the bug. If this is incorrect, I apologise. On Sat, 26 Jul 2014, Michael Biebl wrote: > invoke-rc.d stop <foo> will only stop the underlying systemd .service, > not the socket. This is Broken, and it can be really dangerous, as in "opens a temporary security hole or causes data corruption/loss". System scripts/maintainer scripts that call invoke-rc.d can, and do expect that once stopped, the service *remains* stopped until explicitly restarted/started, either by invoke-rc.d, or by the local admin. So, when socket activation restarts a service that invoke-rc.d stopped, you risk all sort of very nasty problems during package upgrades/downgrades/ removal/purge. Please feel free to file a bug on whatever package is carrying the invoke-rc.d manpages to add that as a major warning, I believe we never documented it explicitly :-( > Up until now, we do not generate explicit maintainer scripts code to > stop the socket during upgrades. The underlying idea was, that keeping > the socket open would allow to not lose any incoming message. This is, unfortunately, exactly the wrong thing to do in many cases. > Unfortunately, triggering a service start mid way through the upgrade is > not a good idea. We'd need a facility in systemd to defer/block incoming > requests until the service is ready. Indeed. > Since we don't have that, we concluded that dh-systemd should generate > maintainer scripts code to stop the socket as well as the service. See [1]. That won't cut it, unless you can do the same to systemd's invoke-rc.d. invoke-rc.d is used not just by the service's package maintainer scripts, it is used also by system scripts (such as cronjobs) *AND* often by other loosely-related package's maintainer scripts. And this is _NOT_ misuse of invoke-rc.d. It is one of its main usecases! Changing that would be *really* painful, and require that we audit a very large number of packages. It is also going to fail the "least suprise" principle, so it is not a good idea. If there is no better way to fix this issue right now, I suggest an emergency stopgap measure using systemctl enable/disable. The proper medium-term fix is likely going to require enhancing systemd with a new systemctl command that also blocks socket activation for stopped services, and changing systemd's invoke-rc.d to use that new command to implement "invoke-rc.d stop". -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
