Bug#741469: cups-daemon: postinst fails to generate working cupsd-systemd-listen.conf when only using unix socket
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
Reply to: