Control: severity -1 normal Control: retitle -1 cups-daemon: New systemd Listen stanzas have no ListenDatagram anymore, making such overrides fail the cups.socket reload
Hi all, Le jeudi, 13 mars 2014, 08.24:16 Yves-Alexis Perez a écrit : > On Wed, Mar 12, 2014 at 11:44:48PM +0100, Michael Biebl wrote: > > If (as in your case) "Listen localhost:631" is commented out, > > cups-daemon.postinst will generate a file > > /etc/cups/cupsd-systemd-listen.conf: > > > > [Socket] > > (…) > > > > That is perfectly ok. Remember that /lib/systemd/system/cups.socket > > by default has > > > > [Socket] > > ListenStream=/var/run/cups/cups.sock > > BindIPv6Only=ipv6-only Ah. Thanks for the information, I initially pointed the empty [Socket] section as potential culprit, which it isn't. > > I fail to see a grave bug here. Can you elaborate? > > I reported the bug (at that severity) at the request of Didier Raboud, > who did the initial debug with me on IRC. Yeah, thanks for it. > Note that I forgot to precise here (since the bug was asked by Didier > who had the elements) that I was using a local override to not bind to > inet at all, which had: > > [Socket] > ListenStream= > ListenStream=/var/run/cups/cups.sock > ListenDatagram= > > (because previous package version had both a ListenStream and a > ListenDatagram directive). It seems that there's now only a > LicenseStream and it might be my ListenDatagram= directive which > causes issues at upgrade, since it tries to remove something > non-existent (I'm not fluent enough in systemd to be completely sure) Yeah, that ListenDatagram which isn't overriding anything anymore is the problem that makes the cups.socket fail to reload; I've lowered the severity and retitled accordingly. > Removing my local override and keeping an empty > /etc/cups/cupsd-systemd-listen.conf seems to do the right thing, so I > guess the severity can indeed be lowered (especially since it's a > transient situation, I'm not even sure the previous version went to > jessie). It did. :/ > I still think it's not a perfect situation (to not handle correctly a > previously working situation), but in that case I'm not sure there's > much you can do at the cups-daemon level, since it seems that it's > systemd complaining about the directive. Yeah, I tend to agree and would think that these types of issues should be handled by a systemd component (dh-systemd?) that would verify that configurations altered by the administrator are still valid across upgrades. Michael: opinions here? Le mercredi, 12 mars 2014, 21.28:49 Yves-Alexis Perez a écrit : > Also, I'm unsure if the generated file should be in /etc/ or /var. Other CUPS-generated files are also in /etc/cups/, this one doesn't make the situation any worse. As for the symlink in /etc/systemd/system/cups.socket.d , I think it's rightfully in /etc to allow the administrator to remove it as a configuration action. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
