[Pkg-systemd-maintainers] Bug#729566: Bug#729566: Bug#729566: systemd: new upstream release 208

[Alessandro Ghedini]

On Thu, Nov 28, 2013 at 02:18:53PM +0100, Michael Biebl wrote:
> Am 28.11.2013 13:53, schrieb Alessandro Ghedini:
> > On mer, nov 27, 2013 at 11:10:07 +0100, Michael Stapelberg wrote:
> >> Also, here is one more bug which I am neglecting currently due to lack
> >> of time:
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729134
> >> There is a related upstream discussion here:
> >> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/14228
> > 
> > Is the problem that logind/libpam-systemd somehow conflict with consolekit? If
> > so, can't libpam-systemd just "Breaks: consolekit packages"? I've never really
> > understood the whole ConsoleKit/PolicyKit/WhateverKit thing though.
> 
> ConsoleKit and libpam-systemd do not conflict.
> The problem is, that the newest lightdm upload no longer registers a
> ConsoleKit session if systemd-logind is active.
> Most components in unstable (including policykit) still rely on
> ConsoleKit to determine whether a session/user is active or not, though.
> As no active ConsoleKit session found in this case, certain actions are
> denied, like suspend, mounting external hard drives etc.
> The point is, that a switch to logind needs to be done in co-cordinated
> fashion. You need to switch the affected components in the correct order.

I see. I wonder how this is handled by e.g. gdm though, since they don't seem
to use consolekit at all. Doesn't that break stuff too?

> >> I pushed a number of commits to the repository today, I think we can
> >> upload 204-6 fairly soon. Ideally, with a commit addressing #729134.
> >> Afterwards, I’m happy to think about 208 and trying to package it.
> > 
> > What about #724796? Was my suggestion correct?
> 
> I don't see how "reenable" would fix this issue. Can you elaborate?

Correction, "reenable" only works (that is, rsyslog is reported in the correct
state) if after the rm you don't do "daemon-reload", while "enable" never works.
As to why it works, I don't know, but I imagine it may have something to do
with "reenable" doing "disable+enable" without the "daemon-reload" in between.

So basically the sequence would be:

 * rm -f /etc/systemd/system/syslog.service
 * systemctl status rsyslog.service syslog.service syslog.socket
 * systemctl reenable rsyslog.service
 * systemctl daemon-reload
 * systemctl status rsyslog.service syslog.service syslog.socket

The "daemon-reload" after reenable is not really needed though, since it is
implicit in "reenable" (as it is for "enable" and "disable").

This might be helpful for the wheezy->jessie upgrade path since the wheezy
version of rsyslog does not call daemon-reload in postrm (which is added by
dh_installinit in the jessie version).

There's still a bug lingering somewhere though, because doing (in sid)

 * systemctl disable rsyslog.service
 * systemctl enable rsyslog.service

leads to rsyslog.service being in status "inactive (dead)" while in fact it's
still running. This also only happens with rsyslog.service AFAICT, so the bug
may actually be caused by something rsyslog does, though I have no idea what it
might be.

I hope not to have missed something important though.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20131128/efa31ff7/attachment-0002.sig>