Am 13.03.2014 11:59, schrieb Didier 'OdyX' Raboud: > 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?
Apparently, "unsetting" ListenDatagram= makes systemd believe, that there is no valid Listen directive anymore for the socket, even though Corsac has specified ListenStream=/var/run/cups/cups.sock The error message I'm getting is Mär 13 19:08:18 pluto systemd[1]: cups.socket lacks Listen setting. Refusing. Sounds like a genuine bug in systemd. Lennart, I'd like your input on this issue. I don't think "unsetting" a not previously specified Listen* directive should have such an effect of making the socket fail completely, given that there is a valid Listen configuration. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
