Last dbus upgrade issues

[Tomasz Kłoczko]

After last dbus upgrade gdm found that is not able to start.
NM basen network configuration as well is broker because it needs dbus as
well which is not starting.
So many dependencies on dubs looks really terrible/strange/dangerous IMO.

So far found that /ust/lib/tmpfiles.d/dbus.conf does not point to /run/dbus.

Can someomeon tell what needs to be done to bring system to usable state?

Level of the verbosity messages written to system logs about what and by
what failed is close to nothing.

BTW when gdm fails console is completely blocked. Only thing which is
possible to do is reboot, go to single mode and after disable gdm service
and reboot is possible to continue troubleshoot system issues.

kloczek

-- 
-- 
Tomasz Kłoczko | Tel: [phone] | LinkedIn: *http://lnkd.in/FXPWxH
<http://lnkd.in/FXPWxH>*

[Zbigniew Jędrzejewski-Szmek]

On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>  After last dbus upgrade gdm found that is not able to start. 
What Fedora version? Ideally provide specific rpm versions.
dbus-in-F29 != dbus-in-F30 now.

Zbyszek

> NM basen network configuration as well is broker because it needs dbus as
> well which is not starting.
> So many dependencies on dubs looks really terrible/strange/dangerous IMO.
> 
> So far found that /ust/lib/tmpfiles.d/dbus.conf does not point to /run/dbus.
> 
> Can someomeon tell what needs to be done to bring system to usable state?
> 
> Level of the verbosity messages written to system logs about what and by
> what failed is close to nothing.
> 
> BTW when gdm fails console is completely blocked. Only thing which is
> possible to do is reboot, go to single mode and after disable gdm service
> and reboot is possible to continue troubleshoot system issues.
> 
> kloczek

[Tomasz Kłoczko]

On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt;
wrote:

>  On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>  > After last dbus upgrade gdm found that is not able to start.
>
>  What Fedora version? Ideally provide specific rpm versions.
>  dbus-in-F29 != dbus-in-F30 now.
>  
I’m talking about F30 recent change in which has been implemented switch to
dubs-broker.
Ps. If this change has been propagated to F29 (hopefully not) more things
will be screwed.

kloczek
-- 
-- 
Tomasz Kłoczko | Tel: [phone] | LinkedIn: *http://lnkd.in/FXPWxH
<http://lnkd.in/FXPWxH>*

[Tomasz Kłoczko]

On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
[..]
>  I’m talking about F30 recent change in which has been implemented
> switch to dubs-broker.
>  Ps. If this change has been propagated to F29 (hopefully not) more things will be
> screwed. 
Seems I found what caused the issue.
I've been doing upgrade (only) dbus packages using rpm and for some
reason after all old dbus-daemon has been killed and deactivated and
at the same time dbus-broker has not been started.
Instant effect was very strange. For example I was unable to unpack
any archives with files owned by group/user not present in my system
because NSS seems now depends on dbus as well. After next few minutes
Gnome GUI crashed,

if [ $1 -eq 1 ] ; then
        systemctl --no-reload disable dbus-daemon.service
        systemctl --no-reload --global disable dbus-daemon.service
        systemctl --no-reload enable dbus-broker.service
        systemctl --no-reload --global enable dbus-broker.service
fi

This dbus-broker %post scriplet seems is only swapping started
services but does not stops dbus-daemon and starts dbus-broker if
dbus-daemon is already runimg.
At the same time because in spec file is missing uninstall dbus-daemon
by missing "Obsoletes: dbus-daemon" below

%triggerpostun -- dbus-daemon
systemctl --no-reload preset dbus-broker.service
systemctl --no-reload --global preset dbus-broker.service

has not been activated as well. IMO implementing whole transition with
leaving both old and new packages installed seems is wrong.

Solution: login after all in single mode and execute "systemctl enable
dbus-broker" than reboot.
Other problem is that dnf and rpm are executing batch of packages
scriplets not the same order with other operations. Breaking rpm
semantics by dnf is kind of asking for troubles.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[David Herrmann]

Hi

On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com&gt; wrote:
>  On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
>  [..]
>  > I’m talking about F30 recent change in which has been implemented switch to
> dubs-broker.
>  > Ps. If this change has been propagated to F29 (hopefully not) more things will be
> screwed.
>
>  Seems I found what caused the issue.
>  I've been doing upgrade (only) dbus packages using rpm and for some
>  reason after all old dbus-daemon has been killed and deactivated and
>  at the same time dbus-broker has not been started.
>  Instant effect was very strange. For example I was unable to unpack
>  any archives with files owned by group/user not present in my system
>  because NSS seems now depends on dbus as well. After next few minutes
>  Gnome GUI crashed,
>
>  if [ $1 -eq 1 ] ; then
>          systemctl --no-reload disable dbus-daemon.service
>          systemctl --no-reload --global disable dbus-daemon.service
>          systemctl --no-reload enable dbus-broker.service
>          systemctl --no-reload --global enable dbus-broker.service
>  fi
>
>  This dbus-broker %post scriplet seems is only swapping started
>  services but does not stops dbus-daemon and starts dbus-broker if
>  dbus-daemon is already runimg. 
You cannot stop dbus-daemon on a running system. This would tear down
everything. The package upgrade needs a reboot.

>  At the same time because in spec file is missing uninstall
> dbus-daemon
>  by missing "Obsoletes: dbus-daemon" below 
Uninstalling dbus-daemon would break a running system, because it
would stop the system bus. Furthermore, other packages still depend on
tools provided by the old dbus-package. Can you elaborate why it is
harmful to keep dbus-daemon around? We made sure you can manually
remove it, unless other packages explicitly depend on the dbus-daemon
binary for private buses.

>  %triggerpostun -- dbus-daemon
>  systemctl --no-reload preset dbus-broker.service
>  systemctl --no-reload --global preset dbus-broker.service
>
>  has not been activated as well. IMO implementing whole transition with
>  leaving both old and new packages installed seems is wrong.
>
>  Solution: login after all in single mode and execute "systemctl enable
>  dbus-broker" than reboot. 
This surprises me. You are saying a simple reboot did not solve your
issues? The `enable` line is executed during upgrade, but you are
saying on your system dbus-broker was not enabled after the upgrade?

>  Other problem is that dnf and rpm are executing batch of packages
>  scriplets not the same order with other operations. Breaking rpm
>  semantics by dnf is kind of asking for troubles. 
Thanks a lot for the report. We tested this upgrade with several
different setups (both dbus-daemon and broker installed/not installed
before the upgrade, etc.), and we didn't see this behavior. We are
aware that this update needs a reboot to fully work, but we made sure
it somewhat works even if you don't reboot. For rawhide, there is
sadly no way to mark updates as "needs reboot".

Thanks
David

[Peter Robinson]

On Mon, Nov 26, 2018 at 5:57 AM David Herrmann <dh.herrmann(a)gmail.com&gt; wrote:
>  Hi
>
>  On Sun, Nov 25, 2018 at 10:53 PM Tomasz Kłoczko
>  <kloczko.tomasz(a)gmail.com&gt; wrote:
>  >
>  > On Sun, 25 Nov 2018 at 11:35, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt;
> wrote:
>  > [..]
>  > > I’m talking about F30 recent change in which has been implemented switch to
> dubs-broker.
>  > > Ps. If this change has been propagated to F29 (hopefully not) more things will
> be screwed.
>  >
>  > Seems I found what caused the issue.
>  > I've been doing upgrade (only) dbus packages using rpm and for some
>  > reason after all old dbus-daemon has been killed and deactivated and
>  > at the same time dbus-broker has not been started.
>  > Instant effect was very strange. For example I was unable to unpack
>  > any archives with files owned by group/user not present in my system
>  > because NSS seems now depends on dbus as well. After next few minutes
>  > Gnome GUI crashed,
>  >
>  > if [ $1 -eq 1 ] ; then
>  >         systemctl --no-reload disable dbus-daemon.service
>  >         systemctl --no-reload --global disable dbus-daemon.service
>  >         systemctl --no-reload enable dbus-broker.service
>  >         systemctl --no-reload --global enable dbus-broker.service
>  > fi
>  >
>  > This dbus-broker %post scriplet seems is only swapping started
>  > services but does not stops dbus-daemon and starts dbus-broker if
>  > dbus-daemon is already runimg.
>
>  You cannot stop dbus-daemon on a running system. This would tear down
>  everything. The package upgrade needs a reboot.
>
>  > At the same time because in spec file is missing uninstall dbus-daemon
>  > by missing "Obsoletes: dbus-daemon" below
>
>  Uninstalling dbus-daemon would break a running system, because it
>  would stop the system bus. Furthermore, other packages still depend on
>  tools provided by the old dbus-package. Can you elaborate why it is
>  harmful to keep dbus-daemon around? We made sure you can manually
>  remove it, unless other packages explicitly depend on the dbus-daemon
>  binary for private buses.
>
>  > %triggerpostun -- dbus-daemon
>  > systemctl --no-reload preset dbus-broker.service
>  > systemctl --no-reload --global preset dbus-broker.service
>  >
>  > has not been activated as well. IMO implementing whole transition with
>  > leaving both old and new packages installed seems is wrong.
>  >
>  > Solution: login after all in single mode and execute "systemctl enable
>  > dbus-broker" than reboot.
>
>  This surprises me. You are saying a simple reboot did not solve your
>  issues? The `enable` line is executed during upgrade, but you are
>  saying on your system dbus-broker was not enabled after the upgrade?
>
>  > Other problem is that dnf and rpm are executing batch of packages
>  > scriplets not the same order with other operations. Breaking rpm
>  > semantics by dnf is kind of asking for troubles.
>
>  Thanks a lot for the report. We tested this upgrade with several
>  different setups (both dbus-daemon and broker installed/not installed
>  before the upgrade, etc.), and we didn't see this behavior. We are
>  aware that this update needs a reboot to fully work, but we made sure
>  it somewhat works even if you don't reboot. For rawhide, there is
>  sadly no way to mark updates as "needs reboot". 
I have two arm systems running rawhide and they've both had problems
where I've ended up without dbus running so no network etc. I needed
to explicitly login locally and enable/disable services and reboot to
get things working again.

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 07:04, David Herrmann <dh.herrmann(a)gmail.com&gt; wrote:
[..]
>  > Other problem is that dnf and rpm are executing batch of
> packages
>  > scriplets not the same order with other operations. Breaking rpm
>  > semantics by dnf is kind of asking for troubles.
>
>  Thanks a lot for the report. We tested this upgrade with several
>  different setups (both dbus-daemon and broker installed/not installed
>  before the upgrade, etc.), and we didn't see this behavior. We are
>  aware that this update needs a reboot to fully work, but we made sure
>  it somewhat works even if you don't reboot. For rawhide, there is
>  sadly no way to mark updates as "needs reboot". 
1) Nothing from any implemented scriptlets printed out such
message/warning that system needs to be rebooted ASAP..

2) Even if some scriplets would be printing something like this dnf
will redirect stdout messages to /dev/null. rpm does not do this and
IMO good question is why dnf is doing this, So generally your 'there
is sadly no way to mark updates as "needs reboot"' is not real barrier
but barrier in dnf. Other thing is that many existing scriptlets which
may emit some workings or even errors are usually redirected by
packagers to /dev/null. For example now it is some number of packages
systemd files are still pointing to /var/run instead to /run. No one
is going to fix those issues because almost no one knows that it is
already reported by some systemd commands. IMO general policy about
scriptlets should be not redirect stdout/stderr to /dev/null because
it hides potential issues in scriplts, configuration files or other
resources.

3) If all dbus connections are not stateless which if it is true would
not allow restart dbus service on running system IMO it is big flaw in
dbus design. In case any dbus security issues this will cause that
Linux will be more like old time Windows (when application level fix
required OS reboot) than modern U*nix. Hopefully this is not truth and
dbus restart is possible.

4) Nevertheless my system ended up with *not enabled* dbus-broker.
If it was caused by upgrade over rpm it clear sign that dnf is not
fully compliant with upgrade semantics implemented in rpm. This will
cause more issues in the future (why dnf is not doing upgrade by use
rpm libs calls? why someone started duplicating this code? It must be
some reason but splitting the code is not a solution)

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Bruno Wolff III]

On Mon, Nov 26, 2018 at 12:57:34 +0100,
  Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
> 4) Nevertheless my system ended up with *not enabled* dbus-broker.
> If it was caused by upgrade over rpm it clear sign that dnf is not
> fully compliant with upgrade semantics implemented in rpm. This will
> cause more issues in the future (why dnf is not doing upgrade by use
> rpm libs calls? why someone started duplicating this code? It must be
> some reason but splitting the code is not a solution) 
I ended up with this (dbus broken because dbus-daemon wasn't enabled) as well. 
I eventually figured out to enable dbs-daemon, but I first tried downgrading 
dbus which was a pain, because the machine doesn't support ethernet and I'm 
not sure how to manaully wireless when NetworkManager can't be used.

Now I know to re-enable it on my other machines before rebooting.

[Nicolas Mailhot]

Hi,

Since I hit it too…

I agree it's a problem when subsystem maintainers assume reboot is cheap 
and controlled and they do not need to make in-place update work (those 
people need a few months baby-sitting headless systems where any mistake 
means unracking and rewiring in uncomfortable physical positions just to 
access hdmi or usb ports).

But… it’s even more a problem, that the people who assumed they could 
design a system around reboots, didn’t provide a reliable way for 
packages to declare the actions required to make the next boot work, 
somewhere where they are sure to be executed before the next boot 
attempt. Because the systems that rebooted on a state without network, 
with broken gdm, and no console login, did provide the OS with the 
required reboot window in the first place.

We had the same thing with grub fast boot recently. I don't care if boot 
is pretty or fast, if problem remediation, is not built in the boot 
process in the first place.

Regards,

-- 
Nicolas Mailhot

[Tom Gundersen]

Hi Tomasz,

On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt;
wrote:

>  On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>  zbyszek(a)in.waw.pl&gt; wrote:
>
> > On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
> > > After last dbus upgrade gdm found that is not able to start.
> >
> > What Fedora version? Ideally provide specific rpm versions.
> > dbus-in-F29 != dbus-in-F30 now.
> >
>
>  I’m talking about F30 recent change in which has been implemented switch
>  to dubs-broker.
>  
Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7
(should land in rawhide any minute).


>  Ps. If this change has been propagated to F29 (hopefully not) more
> things
>  will be screwed.
>  
It has not (and will not be).

Cheers,

Tom

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 15:19, Tom Gundersen <teg(a)jklm.no&gt; wrote:
[..]
> >> What Fedora version? Ideally provide specific rpm versions.
> >> dbus-in-F29 != dbus-in-F30 now.
> >
> > I’m talking about F30 recent change in which has been implemented switch to
> dubs-broker.
>
>  Thanks for the report, and sorry for the inconvenience. 
np .. when tree is chopped chops are flying around :)

>   There was indeed a bug in the dbus-broker spec file, which we now
> fixed with version 16-7 (should land in rawhide any minute). 
IMO it would be good to learn something out of that small fault
because few thing went really odd way.

1) if dbus service crashes/is not availaible temporary IMO it wold be
good to prepare whole desktop apps code to not crash but handle dbus
disconnection and maybe display centered message that it is not
possible to connect to dbus. Crashing everything looks really *bad*.

2) dbus and glibc NSS subsystem dependency. Still needs to reviewed. I
think that it is anchored in systemd and such dependency must be kind
of wrong design issue.

3) any other dependency on running dbus service should be IMO closely
investigated and if something is just crashing it should be
changed/redesigned to handle this to at least log that  to system logs
(nothing like this after all was possible to find in systemd journal
or rsyslogd logs).

4) not able to start gdm (because dbus was not running) blocks any
local login. Simple after such crash it is not possible to open or
switch to any local consoles!!!

5) review all scriptlets and delete redirections to /dev/null. If
during upgrade some programs are to much chatty it should be changed
to in the application started in sctriplets. IMO should be considered
replace redirection to /dev/null by logging to system logs. That would
be helpful on post mortem diagnose of any existing scriptlets issues.
However second thought .. to not depend on systemd (because dnf/rpm
are changing state of the systemd) probably it would be good to log or
tee scriptlets output to log file in /var/log.

kloczek

[Bruno Wolff III]

On Mon, Nov 26, 2018 at 15:57:25 +0100,
  Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
> 4) not able to start gdm (because dbus was not running) blocks any
> local login. Simple after such crash it is not possible to open or
> switch to any local consoles!!! 
I was able to login to a shell, so this one might be configuration specific.

[Nicolas Mailhot]

Le 2018-11-26 16:08, Bruno Wolff III a écrit :
>  On Mon, Nov 26, 2018 at 15:57:25 +0100,
>   Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
> > 
> > 4) not able to start gdm (because dbus was not running) blocks any
> > local login. Simple after such crash it is not possible to open or
> > switch to any local consoles!!!
>  
>  I was able to login to a shell, so this one might be configuration 
>  specific. 
I had it too, forcing boot in rescue mode is not the same thing as 
switching to a console (it requires access to the bootloader menu)

-- 
Nicolas Mailhot

[Tomasz Torcz]

On Mon, Nov 26, 2018 at 03:57:25PM +0100, Tomasz Kłoczko wrote:
>  On Mon, 26 Nov 2018 at 15:19, Tom Gundersen <teg(a)jklm.no&gt;
> wrote:
>  [..]
>  >>> What Fedora version? Ideally provide specific rpm versions.
>  >>> dbus-in-F29 != dbus-in-F30 now.
>  >>
>  >> I’m talking about F30 recent change in which has been implemented switch to
> dubs-broker.
>  >
>  > Thanks for the report, and sorry for the inconvenience.
>  
>  np .. when tree is chopped chops are flying around :)
>  
>  >  There was indeed a bug in the dbus-broker spec file, which we now fixed with
> version 16-7 (should land in rawhide any minute).
>  
>  IMO it would be good to learn something out of that small fault
>  because few thing went really odd way.
>  
>  1) if dbus service crashes/is not availaible temporary IMO it wold be
>  good to prepare whole desktop apps code to not crash but handle dbus
>  disconnection and maybe display centered message that it is not
>  possible to connect to dbus. Crashing everything looks really *bad*.
>  
>  3) any other dependency on running dbus service should be IMO closely
>  investigated and if something is just crashing it should be
>  changed/redesigned to handle this to at least log that  to system logs
>  (nothing like this after all was possible to find in systemd journal
>  or rsyslogd logs). 
  Feel free to provide patches.  There was 15 years to fix it.

  Alternatively, dbus-broker may store fds in systemd and serialize state
over restarts.

-- 
Tomasz Torcz                "Funeral in the morning, IDE hacking
xmpp: zdzichubg(a)chrome.pl    in the afternoon and evening." - Alan Cox

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 17:44, Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
[..]
>    Feel free to provide patches.  There was 15 years to fix it.
>
>    Alternatively, dbus-broker may store fds in systemd and serialize state
>  over restarts. 
So you want to say that in reality it is dbus communication protocol
issue? (protocol is not stateless like for example NFS).
Good to know. .. thx.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

[Owen Taylor]

On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt; wrote:
>  1) if dbus service crashes/is not availaible temporary IMO it wold
> be
>  good to prepare whole desktop apps code to not crash but handle dbus
>  disconnection and maybe display centered message that it is not
>  possible to connect to dbus. Crashing everything looks really *bad*. 
The design of D-Bus is that it is the central point of lifecycle
management for your desktop - when the session bus goes away,
everything on it should go away. Trying to make things survive bus
restart compromises that, and makes it more likely you'll get stray
processes after exit. Now with systemd user sessions, cgroups, etc, we
have other mechanisms for session cleanup, but removing the older
concept of exit-with-the-bus would require major rethinking.

Plus, when the connection to the bus is lost, all assumptions that the
app has about the state of the system are invalid. (Normally, with
D-Bus you reliably get messages, or you reliably get notification when
your communication partner goes away.) So the app state needs to be
reinitialized from scratch. There's significant code complexity there
which will be exercised in only very rare circumstance.

In general, I don't think being able to replace the bus implementation
on a running system is *that* interesting - sometimes the user will
have to reboot, and if that's too disruptive, we need to work on
making it less disruptive.

Owen

[Tomasz Kłoczko]

On Mon, 26 Nov 2018 at 20:04, Owen Taylor <otaylor(a)redhat.com&gt; wrote:
>  On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko
> <kloczko.tomasz(a)gmail.com&gt; wrote:
>  > 1) if dbus service crashes/is not availaible temporary IMO it wold be
>  > good to prepare whole desktop apps code to not crash but handle dbus
>  > disconnection and maybe display centered message that it is not
>  > possible to connect to dbus. Crashing everything looks really *bad*.
>
>  The design of D-Bus is that it is the central point of lifecycle
>  management for your desktop - when the session bus goes away,
>  everything on it should go away. Trying to make things survive bus
>  restart compromises that, and makes it more likely you'll get stray
>  processes after exit. Now with systemd user sessions, cgroups, etc, we
>  have other mechanisms for session cleanup, but removing the older
>  concept of exit-with-the-bus would require major rethinking. 
Cleaning the session is perfect example of what can be done with using
Solaris contracts which is kind of grouping attribute for some group
of processes which needs to be treated as the group. When session
needs to be closed all processes which are part of the contract needs
to be killed by contract id (which works like task id or pid).
Lack of contacts is IMO another cause current systemd complexity
(Solaris SMF for example kills all service processes by not looking
for all PIDs but simple by killing all processes with the same ctid).
Is it any other propose of the dbus communication? (my question is
more about original initial design than what is now)
I'm asking because I do not fully understand of the cause why dbus has
been designed and to solve current design issue original cause of
erecting/designing such communication needs to be well understood.

>  Plus, when the connection to the bus is lost, all assumptions that
> the
>  app has about the state of the system are invalid. (Normally, with
>  D-Bus you reliably get messages, or you reliably get notification when
>  your communication partner goes away.) So the app state needs to be
>  reinitialized from scratch. There's significant code complexity there
>  which will be exercised in only very rare circumstance. 
Looks like again contracts could solve such scenarios with sending
normal signal to PID 1 (like HUP) with masking to be received by all
processes with the same ctid. No new communication or protocols ..
just minute modifications of well known signal handlers.
https://docs.oracle.com/cd/E18752_01/html/816-5174/contract-4.html#REFMAN...
This idea already is used on live systems from more than decade.

kloczek

[Dominik 'Rathann' Mierzejewski]

On Monday, 26 November 2018 at 23:49, Tomasz Kłoczko wrote:
[...]
>  Cleaning the session is perfect example of what can be done with
> using
>  Solaris contracts which is kind of grouping attribute for some group
>  of processes which needs to be treated as the group. When session 
The Linux implementation is called control groups (cgroups) and systemd
makes heavy use of it. 

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Adam Williamson]

On Mon, 2018-11-26 at 15:12 +0100, Tom Gundersen wrote:
>  Hi Tomasz,
>  
>  On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt;
>  wrote:
>  
>  > On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>  > zbyszek(a)in.waw.pl&gt; wrote:
>  > 
>  > > On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>  > > > After last dbus upgrade gdm found that is not able to start.
>  > > 
>  > > What Fedora version? Ideally provide specific rpm versions.
>  > > dbus-in-F29 != dbus-in-F30 now.
>  > > 
>  > 
>  > I’m talking about F30 recent change in which has been implemented switch
>  > to dubs-broker.
>  > 
>  
>  Thanks for the report, and sorry for the inconvenience. There was indeed a
>  bug in the dbus-broker spec file, which we now fixed with version 16-7
>  (should land in rawhide any minute). 
Per https://bugzilla.redhat.com/show_bug.cgi?id=1653059#c25 I believe
this is still wrong, and - intentionally or otherwise - significantly
out of the scope of the Change.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Jan Pokorný]

Hello ,

On 26/11/18 15:12 +0100, Tom Gundersen wrote:
>  On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko
> <kloczko.tomasz(a)gmail.com&gt;
>  wrote:
>  
> > On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
> > zbyszek(a)in.waw.pl&gt; wrote:
> > 
> >> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
> >>> After last dbus upgrade gdm found that is not able to start. 
[...] 

>  Thanks for the report, and sorry for the inconvenience. There was
> indeed a
>  bug in the dbus-broker spec file, which we now fixed with version 16-7
>  (should land in rawhide any minute). 
Thanks for sparing others if not early adopters (nicely demonstrated
like even mere-text-mode-friendly available tooling is dependent on
this single central point these days, NetworkManager/nmtui, even
dhclient complained about DBus, luckily it worked regardless).

Anyway, I've hit another new incompatibility, preventing me to, e.g.,
run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
Workaround is to switch back to dbus-daemon.service.

-- 
Nazdar,
Jan (Poki)

[Jan Pokorný]

On 26/11/18 20:58 +0100, Jan Pokorný wrote:
>  On 26/11/18 15:12 +0100, Tom Gundersen wrote:
> > On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt;
> > wrote:
> > 
> >> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
> >> zbyszek(a)in.waw.pl&gt; wrote:
> >> 
> >>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
> >>>> After last dbus upgrade gdm found that is not able to start.
>  
>  [...] 
>  
> > Thanks for the report, and sorry for the inconvenience. There was indeed a
> > bug in the dbus-broker spec file, which we now fixed with version 16-7
> > (should land in rawhide any minute).
>  
>  Thanks for sparing others if not early adopters (nicely demonstrated
>  like even mere-text-mode-friendly available tooling is dependent on
>  this single central point these days, NetworkManager/nmtui, even
>  dhclient complained about DBus, luckily it worked regardless).
>  
>  Anyway, I've hit another new incompatibility, preventing me to, e.g.,
>  run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
>  Workaround is to switch back to dbus-daemon.service. 
This must have been something intermittent, perhaps a fallout from me
trying to deal with a "difficulties to do anything once rebooted after
installing -6 build" as detailed by others in this thread, bug closed.

-- 
Nazdar,
Jan (Poki)

[Igor Gnatenko]

So I've tried to do following update:
    Install  dbus-broker-16-7.fc30.x86_64        @rawhide
    Upgrade  dbus-1:1.12.10-9.fc30.x86_64        @rawhide
    Upgraded dbus-1:1.12.10-8.fc30.x86_64        @@System
    Upgrade  dbus-common-1:1.12.10-9.fc30.noarch @rawhide
    Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
    Upgrade  dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
    Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
    Upgrade  dbus-libs-1:1.12.10-9.fc30.x86_64   @rawhide
    Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64   @@System
    Upgrade  dbus-tools-1:1.12.10-9.fc30.x86_64  @rawhide
    Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64  @@System
    Upgrade  dbus-x11-1:1.12.10-9.fc30.x86_64    @rawhide
    Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64    @@System

I ended up with disabled both dbus-daemon and dbus-broker.
On Mon, Nov 26, 2018 at 3:19 PM Tom Gundersen <teg(a)jklm.no&gt; wrote:
>
> Hi Tomasz,
>
> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <kloczko.tomasz(a)gmail.com&gt;
wrote:
>>
>> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>>>
>>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>>> > After last dbus upgrade gdm found that is not able to start.
>>>
>>> What Fedora version? Ideally provide specific rpm versions.
>>> dbus-in-F29 != dbus-in-F30 now.
>>
>>
>> I’m talking about F30 recent change in which has been implemented switch to
dubs-broker.
>
>
> Thanks for the report, and sorry for the inconvenience. There was indeed a bug in the
dbus-broker spec file, which we now fixed with version 16-7 (should land in rawhide any
minute).
>
>>
>> Ps. If this change has been propagated to F29 (hopefully not) more things will be
screwed.
>
>
> It has not (and will not be).
>
> Cheers,
>
> Tom
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Tom Gundersen]

Hi Igor,

The upgrade path should hopefully be fixed with dbus-broker-16-8.

Cheers,

Tom

On Wed, Nov 28, 2018 at 10:33 AM Igor Gnatenko <
ignatenkobrain(a)fedoraproject.org&gt; wrote:

>  So I've tried to do following update:
>      Install  dbus-broker-16-7.fc30.x86_64        @rawhide
>      Upgrade  dbus-1:1.12.10-9.fc30.x86_64        @rawhide
>      Upgraded dbus-1:1.12.10-8.fc30.x86_64        @@System
>      Upgrade  dbus-common-1:1.12.10-9.fc30.noarch @rawhide
>      Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
>      Upgrade  dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
>      Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
>      Upgrade  dbus-libs-1:1.12.10-9.fc30.x86_64   @rawhide
>      Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64   @@System
>      Upgrade  dbus-tools-1:1.12.10-9.fc30.x86_64  @rawhide
>      Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64  @@System
>      Upgrade  dbus-x11-1:1.12.10-9.fc30.x86_64    @rawhide
>      Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64    @@System
>
>  I ended up with disabled both dbus-daemon and dbus-broker.
>  On Mon, Nov 26, 2018 at 3:19 PM Tom Gundersen <teg(a)jklm.no&gt; wrote:
>  >
>  > Hi Tomasz,
>  >
>  > On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko <
>  kloczko.tomasz(a)gmail.com&gt; wrote:
>  >>
>  >> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>  zbyszek(a)in.waw.pl&gt; wrote:
>  >>>
>  >>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>  >>> > After last dbus upgrade gdm found that is not able to start.
>  >>>
>  >>> What Fedora version? Ideally provide specific rpm versions.
>  >>> dbus-in-F29 != dbus-in-F30 now.
>  >>
>  >>
>  >> I’m talking about F30 recent change in which has been implemented
>  switch to dubs-broker.
>  >
>  >
>  > Thanks for the report, and sorry for the inconvenience. There was indeed
>  a bug in the dbus-broker spec file, which we now fixed with version 16-7
>  (should land in rawhide any minute).
>  >
>  >>
>  >> Ps. If this change has been propagated to F29 (hopefully not) more
>  things will be screwed.
>  >
>  >
>  > It has not (and will not be).
>  >
>  > Cheers,
>  >
>  > Tom
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Igor Gnatenko]

I don't have time to revert back and try updating again, but the fix looks good!

Thanks!
On Wed, Nov 28, 2018 at 1:19 PM Tom Gundersen <teg(a)jklm.no&gt; wrote:
>
> Hi Igor,
>
> The upgrade path should hopefully be fixed with dbus-broker-16-8.
>
> Cheers,
>
> Tom
>
> On Wed, Nov 28, 2018 at 10:33 AM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
>>
>> So I've tried to do following update:
>>     Install  dbus-broker-16-7.fc30.x86_64        @rawhide
>>     Upgrade  dbus-1:1.12.10-9.fc30.x86_64        @rawhide
>>     Upgraded dbus-1:1.12.10-8.fc30.x86_64        @@System
>>     Upgrade  dbus-common-1:1.12.10-9.fc30.noarch @rawhide
>>     Upgraded dbus-common-1:1.12.10-8.fc30.noarch @@System
>>     Upgrade  dbus-daemon-1:1.12.10-9.fc30.x86_64 @rawhide
>>     Upgraded dbus-daemon-1:1.12.10-8.fc30.x86_64 @@System
>>     Upgrade  dbus-libs-1:1.12.10-9.fc30.x86_64   @rawhide
>>     Upgraded dbus-libs-1:1.12.10-8.fc30.x86_64   @@System
>>     Upgrade  dbus-tools-1:1.12.10-9.fc30.x86_64  @rawhide
>>     Upgraded dbus-tools-1:1.12.10-8.fc30.x86_64  @@System
>>     Upgrade  dbus-x11-1:1.12.10-9.fc30.x86_64    @rawhide
>>     Upgraded dbus-x11-1:1.12.10-8.fc30.x86_64    @@System
>>
>> I ended up with disabled both dbus-daemon and dbus-broker.
>> On Mon, Nov 26, 2018 at 3:19 PM Tom Gundersen <teg(a)jklm.no&gt; wrote:
>> >
>> > Hi Tomasz,
>> >
>> > On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com&gt; wrote:
>> >>
>> >> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>> >>>
>> >>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>> >>> > After last dbus upgrade gdm found that is not able to start.
>> >>>
>> >>> What Fedora version? Ideally provide specific rpm versions.
>> >>> dbus-in-F29 != dbus-in-F30 now.
>> >>
>> >>
>> >> I’m talking about F30 recent change in which has been implemented switch
to dubs-broker.
>> >
>> >
>> > Thanks for the report, and sorry for the inconvenience. There was indeed a
bug in the dbus-broker spec file, which we now fixed with version 16-7 (should land in
rawhide any minute).
>> >
>> >>
>> >> Ps. If this change has been propagated to F29 (hopefully not) more
things will be screwed.
>> >
>> >
>> > It has not (and will not be).
>> >
>> > Cheers,
>> >
>> > Tom
>> > _______________________________________________
>> > devel mailing list -- devel(a)lists.fedoraproject.org
>> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Tomasz Kłoczko]

On Wed, 28 Nov 2018 at 13:44, Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  I don't have time to revert back and try updating again, but the fix looks good!
Whoever will be doing dbus upgrade just please do this using commands like below

# dnf upgrade -y --downloadonly dbus\*

than:

# rpm -Uvvvh /var/cache/dnf/rawhide-*/packages/dbus* 2>&1 | tee
~/dbus-upgrade.out

If anything will go wrong just please share ~/dbus-upgrade.out file.
I think that instead download and upgrade using rpm necessary
diagnostics could be done by add more -v to dnf like "dnf  upgrade
-yvvv dbus\*"

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH